[
Lists Home |
Date Index |
Thread Index
]
At 10:50 AM 5/13/2002 -0400, Mike Champion wrote:
>5/13/2002 9:45:14 AM, Jonathan Robie
><jonathan.robie@datadirect-technologies.com> wrote:
>
>
> >For XQuery, some people have suggested the following conformance levels:
> >
> >1. Some implementations use only built-in types, and can not import a
> schema.
>
>Are we talking about the XPath built-in types or the W3C XSD "primitive"
>types? My sense of the 80/20 point for typing is strings, date-time,
>integers, floating points ... maybe 1-2 more. The 30 or so
>"primitive" types that make controversial distinctions between
>short and long integers, dates and times, etc. etc. do not seem like
>a sensible starting point for a minimial conformance level.
I can understand the desire for fewer types. But if you support any data
types in documents, its hard to justify not supporting those data types
found in the documents that are being queried, which may belong to any
built-in type.
One niggle: the primitive types do not include short and long integers,
etc., these are found in built-in derived types. It would be possible to
support only primitive types and not derived types. I'm not sure that would
be much of a simplification. Bottom line: I wish there were fewer primitive
types in XML Schema. XML Schema was a featurist WG. Here's one place where
using RELAX-NG does not help, because most RELAX-NG implementations that
use types use the XML Schema types.
> >2. Some implementations may not be able to do static type checking.
> >
> >Do those seem like reasonable conformance levels?
>
>What about the functions and operators? That seems at first glance
>like something that could be pared down significantly for a
>minimal implementation. I guess a lot of them would be
>irrelevant if only the built in types are supported....
You got that right. Or if we had a general framework for data accessors
that did not require a new function every time you want to get one field
out of a simple type like a date.
>Anyway, I'd say that the minimalconformance level should
>roughly correspond to the types and operations
>supported by XPath 1.0 -- net the refactoring and cleanup that has
>been necessary. I think that would leave us with what non-specialists who are
>enthusiastic about XQuery think that it is: XPath + SQL-like
>subexpressions to do joins, etc. + simple output reformatting.
If you mean structural reformatting, I agree that this is what a lot of
people will be using it for.
>INSERT/UPDATE/DELETE is another matter ... I can't see a use case for
>XQuery (as opposed to XPath 2) that doesn't include them, but that
>subject has been beaten to death. It's going to be either a way
>for implementations to differentiate themselves at the expense of
>compatibility, or yet another area where real interop is coordinated
>outside the W3C.
I still think the W3C should confront this one. There's some bubbling going
on under the surface, but nothing concrete that I can discuss at this point.
Jonathan
|
