[
Lists Home |
Date Index |
Thread Index
]
At 05:34 PM 7/3/2002 -0400, Mike Champion wrote:
>First, I like specs that are either a) well grounded in actual practice or b)
>grounded in well-understood theory. The actual practice with WXSDL's type
>systems
>for non-trivial schemas seems spotty at best; this list is full of rather
>disturbing
>discussions that do not give me a warm feeling that people who understand
>this
>better than I do have the situation under control.
There are many reasons that we needed our own data model and our own
formalisms. These give us a layer of insulation from the details of XML Schema.
>XDuce may not be "well-
>understood theory", but a lot more work has gone into it than the current
>XQuery
>type system, no? What can anyone say to assure me that this is not "computer
>science by committee?"
Actually, I suspect that our own type system represents significantly
*more* work, and has received much wider review. I am not claiming it is
perfect, but we aren't finished yet.
Do you have specific problems in mind?
>Second, Jonathan's example seems to presume a very tight coupling between
>instances
>and a schema, which is highly problematic in the real world: schemas evolve,
>differences between validators could mean that "invalid" instances (as far
>as the
>XQuery processor are concerned) get into the database, business
>requirements cause
>manual over-rides to accept structurally invalid but lucrative invoices,
>etc. etc.
>etc.
These are precisely the reasons I want to be able to have type safety when
I need it. If schemas evolve in a way that changes the name of the 'price'
element to 'list-price' for some instances but not others, then my
function will always computed 0 as the total for an invoice that uses
'list-price', but it will compute the correct price for the instances I had
in mind when I wrote the function. I would like static analysis to tell me
there's a problem when the instances no longer match the assumptions under
which I wrote my code.
>I can think of lots of scenarios where I would want my get-total()
>function to
>process the "merely well-formed elements whose name happens to be 'invoice'".
But XQuery works perfectly well for queries on merely well-formed documents
- do you have a scenario in mind that it does not handle well?
>Finally, while I can understand the Query WG's desire to build on the rest
>of the
>W3C infrastructure, in practice this named typing approach disenfranchises
>the
>majority of the world that doesn't (yet???) use W3C Schema.
I really don't think this is true at all. It just tells the rest of the
world that they need to figure out how to define the mappings into our data
model. We really need to have *some* model to work with, and it pretty much
has to support XML Schema, DTDs, and well-formed XML, as well as XML views
of relational data.
>OK, maybe
>"disenfranchises" is too strong (since queries can always fall back to
>string types,
>or DTD types can be mapped ...) Still, the assumption that the W3C's
>schema language
>would quickly replace DTDs and other XML-syntax schema languages sounded a
>lot more
>plausible 3 years ago when the XQuery activity got underway than it does
>today.
>Lots of large-scale software projects have to re-visit their requirements
>as the
>external realities change before the project is finished ...
In 2002, it is true that the majority of commercial XML database products
that use typed data are using XML Schema - are there trends that I am
missing here?
Jonathan
|
