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

[Tom Bradford <bradford@dbxmlgroup.com>]

Evan Lenz wrote:
> 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.

And I disagree.  There are times when extensions to a language in the
form of functions are completely inadequate to effectively provide a
given behavior.  This is why the syntax of languages evolve just as
their run-time libraries do.  XPath is already overly complex as a
querying language, without introducing more functions that beg the
uninitiated user to ask:

Which is correct?
   This: /customer[ext:like(name, "Mike")]
or This: /customer[name[ext:like(., "Mike")]]

Because depending on the function, the answer and the behavior varies. 
Adding extension operators (rather than functions) that clarify the
behavior in a way that is consistent with traditional comparative
operators is preferable, especially if we want to make this XML stuff
approachable by average users.  And so far, all of us, XML database
vendors, and XML standards producers, have done a piss poor job of that.

-- 
Tom Bradford
The dbXML Project
Open Source Native XML Database
http://www.dbxml.org