xml-dev - Re: The Power of Groves

[Len Bullard <cbullard@hiwaay.net>]

I need to trim out some of this excellent discussion because the point 
I've been looking for is the applicability of groves, what they are 
good for, and how that might be of use in situations such as we face 
in VRML where multiple spec parents force ugliness into the
implementations. 
In some respects, for VRML, that is spilt milk, but I've done this 
long enough to see standards come and go, so perhaps it is the 
tools, techniques, and practices of standardization that should be 
examined.  We know XML can't do the job in all cases for all kinds 
of application languages.  The *semantic web* and the *fractal 
web* are largely delusions, fun, but not very useful.

<aside>The first idiot that mutters "Internet Time", take this to the 
bank, you get us into the messes.</aside>

>W. Eliot Kimber wrote:
> 
> XML *appears* to be a universal data abstraction, but it's not quite,
> because it is already specialized from nodes with properties to
> elements, attributes, and data characters.

It has an abstract model:  roughly, the InfoSet.

> This is why Len's recent
> comment about an XML representation of VRML not working well with the
> DOM is not at all surprising. Of course it doesn't. The DOM reflects the
> data model of XML (elements, attributes, and data characters) not the
> data model of VRML. This is always the case for XML.

Yes.  But note that I did not say we could not create an XML encoding of 
VRML.  Trees and bushes map as long as the ground can be a root.  No 
mysticism in this:  the problem of this mapping is that there are 
multiple meta contracts governing a shared description of a semantic. 
We have X3D and it is XML; it will simply be ugly because we are 
asked to use wrapper tags to cover the mismatched abstractions. 
If you had replied, "groves could be used to make that abstraction 
more useful" I would have thought groves more interesting for the 
problem:  a meta contract for multiple encodings, perhaps more 
descriptive, perhaps as an adjunct to the abstract IDL.
 
> I have observed that the world desperately needs a universal data
> abstraction. I think that one of the reasons that XML has gotten so much
> attention is that it *looks like* such an abstraction (even though it's
> not).

Begging a bit.  XML is SGML.  It gets a lot of attention because it 
is a) a good solution for a set of knotty problems b) the solution 
espoused by a currently powerful consortium.  It is good news and maybe 
for the wrong reasons, but selah.

> I also don't think it really matters what the abstraction looks like in
> detail--what's important is that we agree on what it is as a society.

Societies do not implement; societies do not agree.  Societies can 
be said to be characterized by agreements, but agreements are first 
and foremost contracts among individuals.

> I think that groves are a pretty good first
> cut, but we could certainly improve on them. The advantage that groves
> have at the moment is that they are standardized, 

That is perceived.  Standards are just paper with names on them.  
If HyTime's history vs the history of HTML and XML prove anything, 
it proves the value of the names often outweigh the value of the 
contents to which names are appended.  Sad but so.

> > 2) Does the grove paradigm, or something similar to the grove
> > paradigm, constitute a Universal Data Abstraction?
> 
> Yes, obviously.

Unproven and I think, unprovable.


> Because groves can be applied to any kind of data (per the discussion
> above) it follows that the DSSSL and HyTime standards can be applied to
> any kind of data. 

I think that is unproven but it is an interesting assertion.  A problem 
is that as long as DSSSL and HyTime remain obscure and impenetrable, 
they will not be adopted for such.  It is impractical to create 
yetAnotherStandardsPriesthood.

> I agree completely. That is one reason we're working on rationalizing
> EXPRESS and groves. As part of that effort, we have created EXPRESS
> models for the SGML and HyTime property sets, providing an example of
> using a more generalized formal modeling language to specify the data
> models the groves reflect. You could, of course, do the same thing with
> UML and define a generic algorithm for going from a UML model to a grove
> representation of the data objects conforming to that model.

Que bueno.  I hope that work makes it way into the process and practice 
of standardization.  IMO, we have many of our current problems because 
standardization as practice and technique is still a black art and 
still overdriven by documentation constraints, eg, the need to 
stay within the constraints of the prior version once a standard 
is adopted as such.  This is quite an incentive and means to 
perpetuate consultancies and political power bases beyond reasonable 
returns.

> It's too bad that we didn't appreciate the existence
> or applicability of EXPRESS at the time, because if we had we very well
> might have used it.

That strikes me as odd.  We certainly did know about it.  The original 
work on EXPRESS and SGML takes place before groves.  That is why the 
PDES model had the SGML string for documents.  Dr Goldfarb was certainly 
aware and in fact, some sought funding to make it possible for he and 
the inventor of EXPRESS to work together on a harmonization.  Like 
many good things CALS money could have done, I suspect that is another
that 
got lost in the grime of consultancy.  Those who started that effort 
as usual got called back to their companies and told it wasn't 
important.  There is always time but not always support.  Que lastima.

> In practice it probably wouldn't have caused
> anyone harm if we had required support for longer names.

Obscurity bites in most prose, but in a standard, it is a fatal flaw.

If the work on HyTime is not to be lost, present what it is 
good for, how to apply it, and perhaps, show this in the 
framework of real problems.  

Is a grove a means to standardize?  Is it better and why?  For what?
In 50 words or less.

len