[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Data Model(s) for XML 1.0 / XML Devcon / DOM / XSL / Query
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Sean McGrath <firstname.lastname@example.org>, email@example.com
- Date: Mon, 26 Feb 2001 09:31:25 -0600
All the GroveMen said was, here is a node/property
data model with grove plans for the different states one
can find a grove in. Not rocket science; just hard to
sort out given the path to that abstraction came from a
model based on parsing and validation as one process.
o XML Syntax: the lowest common denominator agreement. Go here for
absolute process. IOW, you do the heavy lifting
but the bits will be the bits you expect. Parsing is just
parsing. XML doesn't care what you mean; you care. Lift at will.
o Base InfoSet/Grove: Can't work with bits? Here is a usually
reliable description of what the bits *mean*. Validatible but
only by applying the data model rules for *meaningful interpretation*.
InfoSet cares what you mean, but only that you mean what it
cares about. It lifts its heavy parts; you lift the rest.
o Extensions to InfoSets/GrovePlans: Share a more complex
interpretation with others? Here is a way to plan how to
test your communication to see if you still agree on that
interpretation and can *meaningfully* do the right thing.
Keeping everyone *meaningfully involved* is hairy.
Let's all lift together, 1.....2.....3: LIFT!
XML as *a family of infosets* is always going to have hairy edges.
Anyone who ever designed classes for a large system with multiple
applications knows how hairy this gets. It wasn't a mistake
to build XML from syntax, but each time a new language infoset is
said to be "standard" when it is really an "application consensus",
we get new data models. That isn't a problem until
one of these new models forces a loopback into the base
interpretation of "what the bits mean". The oopMen talk about
the problem of getting abstract classes right the first time.
The relational schema designers talk about denormalized tables
and 'rotten indexing'.
Is there a forseeable end to this? Is Henry's proposal a loop back through
the base infoset to tighten it and perhaps add a few extensions to
hold together the current round of language data model needs?
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Sean McGrath [mailto:firstname.lastname@example.org]
On the other hand, I fear the
will make the whole base family of XML standards
intractable without the property sets/groves abstractions.
The simpleton in me refuses to believe that
the world should be or needs to be this