[
Lists Home |
Date Index |
Thread Index
]
On Thu, 5 Sep 2002, Jeff Lowery wrote:
> I thought someone else would note that the DTD
>
> <!ELEMENT MY-NON-BOOLEAN ((TRUE | FALSE)?, (TRUE | FALSE))>
>
> is nondeterministic and therefore not allowed by XML Schema. Or does it
> matter?
It's easy to construct a deterministic case. Just add another element!
> I guess if the point is that XML doesn't map ideally to objects, then a
> particular choice of schema language is moot. But binding XML to object
> data (and back) seems in general easier than, say, porting object data to
> relational models (and plenty of people are still doing that).
Seems roughly the same difficulty to me.
> What is the argument? That XML should be XML, objects should be objects, and
> database tables should remain tables? But they won't stay in their little
> respective corners! If the argument is instead that all data model
> mappings should be carefully crafted on a case-by-case basis, then
> personally I'm very dissatisfied with that prescription. The natural order
> of things is that complexity breeds simplicity by necessity. Did I miss an
> alternative solution somewhere?
The specific argument is that XML Schema should not allow derivation by
extension by default. And people should be very careful if they choose to
do it explicitly.
The general argument is that this kind of confusion arises because XML
Schema is trying to do two jobs at once. First it is trying to constrain
the *syntax* of a class of XML documents. In this it is like DTDs, RELAX,
etc. The second thing is to try to define a mapping into an object
oriented model with subtyping. In this it is unique. As they say: "It is
both good and original. But that which is good is not original and that
which is original is not good." ;)
Mapping from XML into objects is fine. But it is a totally separate and
unrelated task to *defining the schema* for the XML. Does your relational
schema map from relations into objects? One job is defining syntax. A
separate job is defining semantics/ontology (whether using OO techniques,
logic techniques, whatever).
I took a stab at solving the object-binding problem myself. I'm not sure
whether to continue with it as is because I'm very tempted by a
Regular-language based strategy:
http://www.prescod.net/xml/xbind/
I haven't had as much time for it as I would like.
If I were going to build subtyping into a schema language, it would be in
some sense transformation based. The gist of it is that it is the new
types responsibility to describe how it can be mapped into an instance of
the supertype. And it would be the responsibility of some bit of software
(schema processor, PSVI generator, something) to hide the extra stuff from
applications who don't want to see it.
Architectural forms are close to this idea but there are all kinds of
annoying details that make them not optimal. Like: you couldn't write a
DTD where dog subtypes animal. You had to write a DTD for dog and a
logically separate DTD for animal and if you wanted to allow them both in
your document you would do that with parameter entities or something.
There are too many details to go into but the gist is that archforms are
ackward but they have the right ideas, IMO.
Paul Prescod
|
