[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

  • From: David Carlisle <davidc@n...>
  • To: costello@m...
  • Date: Tue, 29 Jan 2008 22:23:40 GMT

Re:  XPath 2.0 Best Practice Issue: Graceful Degradation

> 1. Avoid relative XPath expressions.
both of your expressions started with / so were not relative.
but comparing
> (a) //altitude * .3048
> (b) /FAA/airplane[@tailnum='C3H1']/altitude[@unit='feet'] * .3048
sometimes you want to ties an expression to a rigid input structure (b)
and sometimes you want to be fleaxible in the face of varying input, (a)
or more commonly something like <xsl:template match="altituse" Its
impossible to give a general rule that one way is good and the other bad.

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

There are contexts (eg client side browser use) where sticking with
xpath 1 for nw makes sense, but if you've yused xpath2 for a while
sticking with xpath 1 is fairly painful, it's not realistic to expect
people to make code work on both systems. If you need to run on an xpath
1 processor, use xpath 1, if you don't commit to xpath 2 and use its
features as appropriate.


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

unless you are just using path to express validation constraints eg
schematron.


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

Yes of course, in many situations you know what that you are going to
schema validate the input and you know you have a schema processor.
Sayiing that you should only write xpaths that can be run anywhere
without any knowledge of the context is making massive assumptios
about the usage. However there are situations where you want expressions
to run in a wide range of contexts and "degrade gracefully" in the
terminology of the thread, and in that situation (only) it makes sense
to avoid cconstructs that will make static compile time errors on some
systems.

> 2. Do you agree with all the above?
Not really:-)

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________


[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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.