Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The Power of Groves
 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
