Re: XPath conformance? was RE: [xml-dev] storing XML files

[Evan Lenz <elenz@xyzfind.com>]

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.