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

["Costello, Roger L." <costello@mitre.org>]

Here's a summary of the current ideas: 

Which of these two XPath statements is best practice:

VERSION 1

    if (//airplane[@tailnum='C3H1'] instance of
schema-element(airplane)) then 
            //airplane[@tailnum='C3H1']/altitude * .3048  
    else 
        if (//airplane[@tailnum='C3H1']/altitude[@unit='feet'] castable
as xs:double) then 
            //airplane[@tailnum='C3H1']/altitude * .3048
        else
            'Error'

VERSION 2

    /FAA/airplane[@tailnum='C3H1']/altitude[@unit='feet'] * .3048

Answer: Version 2.

ADVANTAGES OF VERSION 2:

1. Both XPath 1 and XPath 2 processors can execute it.

2. Both schema-aware and non-schema-aware processors can execute it.

3. The checking that we want performed on the input document is
automatically accomplished:

3.1 By virtue of the semantics of path expressions, we automatically
get structural and value checking: the XPath processor will check that
<FAA> is the root element, it has a child <airplane> element, which has
a child <altitude> element; further, the processor will check that the
<airplane> element has a tailnum attribute, the <altitude> element has
a unit attribute; finally, the processor will check that tailnum='C3H1'
and unit='feet'. 

3.2 By virtue of the semantics of the multiplication operator, we
automatically get datatype checking: the XPath processor will check
that the value of the <altitude> element is compatible with multiplying
it by a decimal value.

4. If the input document is invalid, the result of the operation will
be NaN, which can be tested.

5. It is less complex, and easier to read and maintain.

6. It is focused: XPath developers can spend their time on data
processing rather than on data validation.

DISADVANTAGES OF VERSION 1:

1. Only schema-aware, XPath 2 processors can execute it.

2. It is more complex, and more difficult to read and maintain.

3. It is not focused: it muddies validation with processing.

Summary: Version 2 does everything Version 1 does, but more simply, and
can be processed by more XPath processors.

BEST PRACTICE

1. Avoid relative XPath expressions.  Using relative expressions
diminishes the benefits of the automatic structure and value checking
that we get from path expressions. (see 3.1 and 3.2 above)

Example: Compare these two XPath statements:

(a) //altitude * .3048

(b) /FAA/airplane[@tailnum='C3H1']/altitude[@unit='feet'] * .3048

The later is getting the XPath processor to perform a lot more
checking; any unexpected discrepancies in the input will be revealed.
The former is hiding a lot of potential problems; for example, the
<altitude> being operated on may not be the one for the airplane of
interest, and it may already be expressed in meters.

2. Whenever possible, stick with XPath 1.0 expressions; they can be
processed by XPath 1.0 and XPath 2.0 processors. 

3. Keep XPath statements focused on processing, rather than validation.

QUESTION

1. I now question the value of schema-element().  Should this function
ever be used?  Perhaps it should be avoided?

2. Do you agree with all the above?

/Roger