xml-dev - Re: The Power of Groves

["W. Eliot Kimber" <eliot@isogen.com>]

Len Bullard wrote:

> > Len:  It has an abstract model:  roughly, the InfoSet.
> >
> > Eliot:  Yes, it has an abstract model, but what is the abstract model that
> > underlies the XML abstract model? Within the infoset (or the SGML
> > property set), "element" is a specialization of "node". It is "node"
> > that is the base underlying abstract data model from which the
> > specialized types "element", "attribute", "data character", etc. are
> > defined.
> 
> Roughly
> 
> (ELEMENT | ATTRIBUTE | DATA CHARACTER) IS_A NODE
> 
> ok.  You have three names and you named them.
> 
> So, then is the claim that the XML <!ELEMENT IS_A infoSet Element
> is not definitionally complete?  Is this yourNames vs theirNames
> or is there a deeper issue here?

A deeper issue: what is a "node". The Property Set Definition Annex
formally defines what a node is (as Didier said, a named collection of
properties), defines some basic rules for nodes and their relationships,
and so on. This provides a simple definitional framework from which more
specialized models can be built. That is, given that "element" is_a
"node", I know things about elements simply because they are nodes. I
can write generic software that can, for example, do addressing of
element nodes without knowing anything about the semantics of elements. 

Groves and property sets are purely about using a common language to
describe the characteristics of data instances so that generic software
(e.g., a HyTime engine, a DSSSL engine) can process it and so that you
can write processing standards without having to say anything about
implementation-level data structures.

> > Without this completely generic, universal, base, there is no
> > way to meaningfully compare different data models to define, for
> > example, how to map from one to other, because they are not defined in
> > terms of a common definitional framework.
> 
> My problem here is that we seem to be in an MMTT trap.  That is,
> I can point to at least four other languages that claim the
> *name* "node".  The trick is to prove that what each calls a node
> is the same.

Exactly. Until you define what a node is, you have no formal basis for
comparing two different "nodes". If you have such a definition then you
can define a formal correspondence through a single common form.
Otherwise you are faces with an N x N mapping.
 
> As you say, "not defined in terms of a common definitional framework."
> 
> What common definitions?  Are these common definitions or
> common semantics?

Common definitions: the Property Set Definition Requirements annex,
which defines the basic rules for grove definition and (abstract)
representation.
 

> > *I* didn't know about it. James didn't know about it (or if he did,
> > didn't mention it).
> 
> Then do your homework next time and tell James to do his.  

Freakin' bite me. I didn't know about it, for whatever reason. I didn't
go out of my way to be ignorant on this subject. And I'm certainly in no
position to be telling James Clark what homework he should do. I was
100% busy editing a huge standard and helping develop XML and doing a
high-presure consulting job at the same time. It didn't happen. I'm
trying to correct that now.

Cheers,

E.