[
Lists Home |
Date Index |
Thread Index
]
> In general, I suspect that a query language that is integrated with the
> type system of XML Schema is a significant simplification for the user, not
> a complication, because it allows the XML to be processed directly, and
> does not require mapping to other type systems before processing can occur.
> The user does not have to figure out how dates should be sorted or how they
> map to a particular implementation's date type, the user simply does
> queries on dates, and they act like the user expects them to.
>
> Jonathan
Having a richer set of base types for dates etc is on the whole a good
thing, and given that it's a W3C spec it's inevitable that W3C schema
versions of those types will be used. But the association between
element names and types of their content could be in the
stylesheet/query language rather than the schema, You don't need to
assume a PSVI input to provide functions that can sort dates.
Xpath2 is dangerously tied to XML schema whereas it could be far more
neutral in its support of schema languages: dtd, w3c schema, relaxng,
...
In an Xpath/XSLT setting (if not XML Query) the support for schema
complex types vastly complicates the specification for very small
benefit and doesn't address any issue with Xpath/XSLT that has been
raised on any XSLT forum that I've seen over the last couple of years.
Lots of people have posed problems that would naturally require higher
order functions or dynamic evaluation of XPath for example (neither of
which feature is being added) but no one has ever asked to address
elements by specifying their content model (in either DTD or schema
syntax) rather than their name. If I want to find all elements called foo
with an X attribute it is far more natural in Xpath to ask for foo[@X]
rather than define that type in XML schema, tie myself to an XML parser
supporting XML schema and upgrade to an XSLT/XPath2 system and then
query the element via its schema type. Adding dates and regexp from
schema to Xpath is strengthening Xpath in areas where it is weak. Adding
a new method of describing element structure is just making the language
horribly complicated for little to no benefit. (The optimisation
arguments are far less convincing for XSLT than they are for Xquery, as
the usual model is that each document is parsed afresh each time rather
than working over some persistent set of data matching a fixed schema.
The idea that a query system can optimise away, or generate errors on,
queries like aaa/bbb if the schema specifies that aaa has no bbb children
is also very worrying. How could one write schematron in Xpath2 if it
needs to find exactly such cases and report errors? Xpath1 was designed
to work on documents that specified a DTD but were invalid, not only
well formed documents that did not specify a DTD. Is the same really
true of Xpath2 wrt schema?
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.
|
