[
Lists Home |
Date Index |
Thread Index
]
... but at later points in the documentation, and in the
> conversation of many of the query people, there lurks this bizarre
> belief that type knowledge can only exist in the aftermath of an XML
> schema validation pass.
Yes. In XSLT 1.0 and XPath 1.0 you similarly find many places where the
text displays an assumption that the source data model will originate by
parsing source XML, even though the spec is explicit that this need not
be the case. This isn't actually bizarre, it's just symptomatic of the
fact that we all feel more comfortable in a concrete world than an
abstract one.
>
> I've invested some time in understanding the relationship between XSD
> and XQuery. My understanding is like this:
>
> - XQuery really needs some atomic-type semantics, so that you can do
> range queries on numbers and dates
Such semantics are convenient and aid performance, though many people
have pointed out that one could live without them by relying on dynamic
casting.
> - XQuery is semantically wired into the XSD basic type system, with
> the exception that the Duration type is underspecified so they use
> a custom restriction of it
Well, the functions and operators are wired into it, and there are
literals built in for four of the data types (decimal, integer, double,
and string). The functions are just a library, not really a core part of
the language. The operators probably could be abstracted away from the
data types if we really wanted to do so. As it is, most of the Schema
datatypes (e.g. the gRegorian family) have no intrinsic support in the
language: one could define a core set of types that is substantially
smaller than the set of Schema primitive types.
> - XQuery supports queries on type names (qnames) which however don't
> seem to carry any builtin knowledge of the associated semantics.
Certainly if we could find a way to get rid of the remnants of
structural typing this would be true. A type just becomes an opaque
object that can tell you whether an instance conforms to it or not (and
also, whether another type is a subtype or not).
> - XQuery has some casting and validation operators which assume that
> you'll apply schema machinery at runtime to figure out whether
> (a) your query can possibly work or (b) the constructed result is
> kosher.
> ...
> Beyond that, I see no architectural difficulty in making XQuery
> schema-language agnostic. -Tim
>
No architectural difficulty, just a hell of a lot of hard work and
another year on the schedules...
Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
|
