[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPath conformance? was RE: storing XML files
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 [expletive deleted] poor job of that. -- Tom Bradford The dbXML Project Open Source Native XML Database http://www.dbxml.org
|
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
|