Lists Home |
Date Index |
On Tue, 2002-05-14 at 06:00, Jonathan Robie wrote:
> First question - are you aware that XQuery does not rely directly on the
> PSVI, but on the much simpler XML Query 1.0 and XPath 2.0 data model?
> Here's a pointer to that document:
> Much of this document is about the mapping from an XML Schema into the
> simpler data model. The mappings for DTDs and well-formed XML have not yet
> been completed - this is marked as an open issue in the document. The
> result of the mapping is, IMHO, a rather simple and useful model. (This
> mapping would have been a lot easier if the PSVI were designed at a
> different level of abstraction, but we didn't have a lot of control over that).
> So your first wish is granted. We get rid of the PSVI by mapping it into a
> simpler model at a more useful level of abstraction. This model does have
Yes, I'm quite aware of this document. A mere 30 pages to describe the
data model, more or less trimming down the PSVI to something that may or
may not be manageable. That is, of course, ignoring the 27 pages of
issues, about half of which appear to be resolved.
Looking back into the mists of time, XPath 1.0 in all its glory is about
31 pages. The data model is approximately four pages.
I'm well-aware that counting pages is much like counting lines of code,
and that James Clark is at times too concise. However... I don't think
this is that much of an improvement over the PSVI, at least from the
perspective of markup. (Compared to W3C XML Schema, sure it's an
improvement, and I plan to use the query model for a series of non-XML
> >Repeat, with "strong typing" as the noun.
> I know what you mean by this, and I think I also know how XML is used in a
> loosely typed scenario, since I have thrown around my fair share of XML 1.0
> untyped data too.
> We have already had significant discussion of the usefulness of strong
> typing for optimization and for catching errors. I think strong typing is
> important for meeting goals like these:
> - Suitability for combining data
> - Optimizability for both physical XML and XML views of non-XML data
> - Type safety and type-based optimizability
And I remain convinced that you're driving screws with a hammer. A
pneumatic hammer, to be sure, but that's not much better.
> So this is the crux of our disagreement. You feel that a typed data model
> (not the PSVI, but something much simpler) is not appropriate for XML, and
> that strong typing is a bad idea. I disagree. Also, I think that XQuery has
> done quite a bit to simplify the way the user interacts with the typed data
> model, and don't think that global statements about XML Schema really say
> that much about XQuery.
No, but I think XQuery demonstrates the same mindset that XML Schema
had, largely to its detriment. Rather than asking "here is markup, what
is it good at", this mindset asks "here are my tasks, how do I force
markup to deal with it." The use cases receive more consideration than
the nature of the underlying technology, and we end up with enormous
specifications which solve problems in ways that make little sense for
markup, however much they may address the use case.
> I don't think either of us can simply demand that the other adopt our
> position, since neither of us really has the right personality to be
> bullied into submission. And I don't think these are axioms that must be
> adopted by all specs that are based on XML. I think that both typed access
> and untyped access are important for XMl.
And I disagree firmly. You're shoving strong typing into a system which
copes with it poorly, and the results show. I suspect that in the long
run the query model may well survive, but it will be working on
foundations other than marked-up text.
> So I really do think that we need to find some way to construct more
> detailed scenarios or arguments that will shed light on the virtues of our
> two positions. This is going to take some time.
I'll keep writing all along, here and elsewhere, code and prose.
> Perhaps I can construct some use cases for typing - I probably will not get
> around to it right away. Right now, I'm largely gone for the next five
> weeks, but I may find time to start on some typing use cases.
I don't believe that use cases for typing are useful, unless you can
demonstrate that the typing is better applied in particular to a markup
format than to another data representation. That seems unlikely at
best, except in the "everybody's doing it category".
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!