[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
> For my money, XQuery is a heroic effort by a bunch of incredibly smart
> people which is crippled - we don't know how seriously - by its
> insistence on cohabiting with XSD. -Tim
>
Take a programming language point-of-view, somebody said "a type system
without a programming language is unable to survive alone". IMHO a type
system is always a bit more than what a validation language like XSD or
Relax can give you (there is computation involved).
I would not take XQuery seriously if it relied on a type system that
stands in no relation with any validation language. How do you see it?
If one does not need statically typed languages, things get very easy
for the designer, quite awful for large developer teams. Once you
sacrifice static typing, IMHO that is what you get, and there is no escape.
Anyway, if one is willing to accept static typing, here's something for
assessing "how seriously": The closed-world assumption, which inhibits
separate compilation.
You cannot precompile an XQuery function 'foo' that takes an A, than
augment the schema with a substition group that uses by
derivation-by-extension B extending A, and be sure that calling 'foo'
works. Why? Because derivation-by-extension changes the structure of the
children. Existing code must be type-checked again, that means
recompiled with all other parts of the system again, because
type-checking assumes that one knows all extensions of a type.
The same goes for XSLT (if one actually compiled it separately). Basically nothing that is based on XML Schema can be compiled separately - or one changes the semantics of XPath, turning instances of B into instances of A, cutting away the children added at the end by type B. Voila an idea for a type system and a programming language http://lamp.epfl.ch/~buraq/iron/index.html (expect more soon, or just ignore the proposal for yet another language)
Since XQuery is not yet a recommendation, they can still free themselves from the closed-world assumption. Something like "type-directed XPath semantics" would help: if the type of a variable $x is A, and A declares three children of type T1,T2,T3 then the children of $x will be a three children sequence T1,T2,T3. That means, if somebody called this function with some instance of type B, where B extends type A with T4, T5, the additional children will be hidden. This affects the runtime representation of XML data, and the type system, and is a subtle change to the way XPath is viewed. But it would be a forwards-compatible change.
Now, I guess separate compilation (or "pre-compilation") can be important in databases, and something like "no extensions to the schema after pre-compilation" is hard to enforce.
If you did not use typing at all, but validate against XSD it would be much worse: instances that validate against B will now just break your code (assuming that one has to generate something that validates against some schema), and in a large project you will have a hard time in finding out why, and how to fix it. Untyped systems, that is what I call a crippled design, because one does not let the machine use the information it has.
BTW, there is also not a single data binding framework in the world that can allow XPath navigation over the objects and handle such a situation.
cheers,
Burak
http://lamp.epfl.ch/~buraq
|
