[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XPath 2.0 Best Practice Issue: Graceful Degradation
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
[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
|