Re: XPath 2.0 Best Practice Issue: Graceful Degradation
Costello, Roger L. a écrit : > > There are three kinds of activities going on in the XPath statement: > > 1. There is data processing: the altitude value is converted from feet > to meters: > > //airplane[@tailnum='C3H1']/altitude * .3048 > > 2. There is an XPath check: check that there is an airplane element > with a tailnum attribute having the value 'C3H1', and it has a child > altitude element with a unit attribute having the value 'feet', and its > value can be interpreted as an xs:double value: > > if (//airplane[@tailnum='C3H1']/altitude[@unit='feet'] castable as > xs:double) then ... > > 3. There is a schema-validation check: check that the host language has > schema-validated the input data: > > if (//airplane[@tailnum='C3H1'] instance of > schema-element(airplane)) then ... > > The three activities are combined into one XPath statement. > > David asserts that best practice is to keep the three activities > separate. > > The advantage of keeping them separate is that the XPath will be easier > to read and maintain. > > Thus, when you want to compose an XPath statement to convert the > altitude value from feet to meters, you simply write this XPath: > > //airplane[@tailnum='C3H1']/altitude * .3048 Schema technologies were primarily designed to express constraints on XML document classes. Constraints on XML documents ensure that applications will process them without causing faults. Expressing constraints with schemata ensure that applications developpers will spend most of their time in designing data process and few of their time in controlling them. A valuable feature of schema technologies is the ability to augment the infoset of the document processed. By using this feature, applications developpers won't waste their time in casting raw datas to typed datas. Unfortunately, schema technologies are still trailing behind. (One of) the missing feature(s) is the support of semantics data types. What we might expect at an application level, is more simple than what you wrote : data(//airplane[@tailnum='C3H1']/altitude) ...whatever the unit used because the typed data would be converted at the level of the type definition, that is to say : -definition of the "altitude" type : if @unit='feet' bind the double value of the text content * .3048 else bind the double value of the text content -definition of the "altitude" element : its type is the "altitude" type I have a similar example in RefleX that you can run, but instead of having meters/feet, I have °C/°F When I have these datas : <town name="Paris" date="2005/09/07" temp="23°C"/> <town name="London" date="2005/09/08" temp="68°F"/> ...I can get the temperature with XPath : //town/@temp the result is 23 for Paris, and *20* for London (not *68*), because I have a smartest schema technology that was used for validating the datas. Have a look here, you'll see how to design simply a semantic data type : http://reflex.gforge.inria.fr/tutorial-schemas.html#psvi Really, we can do much more with schema technologies... > Here's a summary of David's proposal: > > When designing an XPath statement, do not combine data processing, > XPath checks, and schema-validation checks. Instead, keep the three > activities separate. > > Do you agree with this? I'm not sure if we have to keep the three activities separate ; what I'm sure is that at an application level, we have to write less amount of code, so the XPath expression you propose is too heavy : let other components do the dirty job before. -- Cordialement, /// (. .) --------ooO--(_)--Ooo-------- | Philippe Poulard | ----------------------------- http://reflex.gforge.inria.fr/ Have the RefleX !
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format