OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[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

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

-----Original Message-----
From: Sean McGrath [mailto:sean@digitome.com]

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