[
Lists Home |
Date Index |
Thread Index
]
At 06:56 PM 5/7/2002 +0100, David Carlisle wrote:
> > 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.
This is true.
Since, however, the schema already tells what types are involved, I don't
see what is to be gained by adding a way to declare this in the query
language too. And being able to declare it in both ways implies that it is
possible to declare it inconsistently.
>Xpath2 is dangerously tied to XML schema whereas it could be far more
>neutral in its support of schema languages: dtd, w3c schema, relaxng,
The current drafts are more closely tied to XML Schema than earlier drafts.
We found it difficult to be truly schema language neutral while being
consistent with any one schema language.
In practice, I think 80% of the use of types involves simple types, and 80%
of the RELAX-NG apps that are typed use the XML Schema types. I used to
believe that any schema language could be mapped to our Data Model equally
well, but I am no longer sure - I still think this is an avenue to explore.
>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.
Here's one such issue: I want to write a query or a transform whose output
is guaranteed to be XHTML. I don't want to validate my output each time to
see if it succeeded.
>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.
Nothing in our spec requires you to do this. Our Data Model will have a
mapping for DTDs. With XQuery, XPath 1.0, or XQuery 2.0, the query that
does what you are asking for is foo[@X], and you are not likely to write a
type-based query to achieve this effect.
>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.
I would find it very useful to know if a transform will always produce an
instance that will validate against some schema. Thats why we support
complex types. This story is currently more compelling for XQuery than for
XSLT, though, because the types for queries have been worked out in more
detail.
I do agree with you that the most common benefits will involve simple types
rather than complex types, though.
>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.
Indeed.
Whether or not that is an error is currently an open issue in XQuery. My
own view is that it should be neither a static nor a dynamic error, but
that it should evaluate to an empty sequence.
>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?
This question has not been answered, it is an open issue. My own view is
that if the validation fails, XPath 2.0 and XQuery 1.0 should have
undefined behavior.
Jonathan
|
