[
Lists Home |
Date Index |
Thread Index
]
OK, let's be clear. There are some big companies who think that it's a
good idea to store XML in relational databases. This means shredding
your document, turning it into tuples, and then putting it back together
again on retrieval. If you do this, you are going to lose fidelity. If
you're using XML to represent simple tabular data, you probably don't
care. If you're storing documents such as legal contracts, then you
almost certainly do.
There are other companies (like mine) who think that shredding your
document is a lousy idea and that users will prefer to buy XML databases
that don't do it.
Yes. I'm not saying that doing the former is a bad thing, but I don't
understand why if you are querying the XML view of that database you
can't explictly do that rather than insist that you phrase it as querying
the original data, and so poluting the entire family of XML standards in
order to legitimise that statement?
If the spec gives options that reduce
interoperability, you can be pretty sure that's because the alternative
was to have no spec.
while I appreciate the work that's gone in to it, when looking at
Xpath 1 and Xpath 2, then it is not at all clear to me that no Xpath2
spec would be that bad an outcome. Some of the worst features have been
improved in more recent drafts (For which I'm prepared to believe you had
some influence:-) but still the price paid for the nice new features
(is, regexp, more general path expressions) is far too high.
The XSLT group could have done XSLT2+Xpath1 in 1/100 of the time and
with far greater level of acceptance in the existing XSLT user base.
David
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
|
