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

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

Thanks everyone for your inputs.  Through our discussions I think that
we have honed in on the key issues.

Based on your comments, I made major changes to the second half
(indicated by a dashed line).  Do you suggest any changes?    

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

As is typically the case, "best practice" requires specification of a
particular scenario. So let's assume that we want the XPath to be
capable of being run in any context.  Then the answer is: 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.

----------------------------------------------------------------------
This example has shed light on several issues, which we now discuss:

DISCUSSION

1. Relative Versus Absolute XPath Expressions  

Version 2 illustrates the benefits of absolute XPath expressions for
automatic structure and value checking. However, it has a disadvantage
of tying the expression to a rigid input structure.  Sometimes you need
an XPath expression that is flexible in the face of varying input.  For
these situations, relative XPath expressions are better suited.

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.

Conversely, the later is rigidly tied to a particular input structure,
whereas the former can be applied to a variety of input structures.


2. XPath 1.0 Versus XPath 2.0

Version 2 can be executed by XPath 1.0 and XPath 2.0 processors.  For
use by client-side browsers, you can only use XPath 1.0.  On the other
hand, XPath 2.0 provides many new features that can make coding much
easier.   


3. Processing Versus Validation

XPath is sometimes used for expressing processing, as in the above
example where XPath is used to convert an altitude from feet to meters.
Sometimes XPath is used for expressing validation requirements, as is
the case with using XPath in Schematron.


4. Run Anywhere Versus Run Here

Sometimes you need XPath expressions that can be run anywhere without
any knowledge of the context; that is, situations where you want the
XPath expressions to run in a wide range of contexts and "degrade
gracefully".  Version 2 is well suited for this situation.
Alternatively, in many situations you know what that you are going to
schema-validate the input and you know you have a schema processor.
Version 1 may be quite suitable for this situation.

/Roger