[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPath conformance? was RE: storing XML files
Tom Bradford wrote: > > Evan Lenz wrote: > > For example, the following is not in compliance with the XPath spec: > > > > /customer[name ~= "Mike"] > > > > whereas this alternative expression would be perfectly fine: > > > > /customer[ext:like(name, "Mike")] > > Though the first example is not part of the specification itself, the > second example is an extension function that most implementations will > not support. In the case of common behavior in the context of XML > databases, neither is 'right'. One won't even be parsable by a > generalized XPath processor, and the other will only be resolvable in a > single implementation, so nobody is wrong or right. The goal, which I > spoke about before, should not be who is more compliant, because > compliancy with what the W3C produces doesn't address the larger and > more common problems that we face as vendors/users of XML databases. Sorry, but there is a qualitative distinction here that has practical implications. If you don't want to support XPath at all, fine. But if you are going to implement it, then you should use the extension mechanisms provided. As you point out, the first example won't even parse. It is an important property of the second that it complies with XPath syntax, so that generalized parsers indeed are able to parse it. Moreover, extensions provide a single breeding ground for new functionality that hasn't yet reached the standard. The work of EXSLT.org is a prime example of this. In that case, you have XPath extension functions that are indeed extensions but that are in fact implemented by multiple vendors. Some of these have a real chance at making it into XSLT 2.0 by virtue of this judicious use of extensions. Finally, in the context of XSLT, there are fallback mechanisms and well-defined behaviors for when an extension function is not available. There is even a function-available() function for testing the availability of particular extensions. In the end, we are much better off with a single, standardized extension mechanism that provides some level of fallback and portability, than with a multitude of syntactic innovations that are guaranteed not to work in any other implementation, let alone parse. Evan Lenz XYZFind Corp.
|
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
|