Re: [xml-dev] XPath 2.0 Best Practice Issue: Graceful Degradation

[Philippe Poulard <philippe.poulard@sophia.inria.fr>]

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 !