Lists Home |
Date Index |
- From: Len Bullard <firstname.lastname@example.org>
- To: "W. Eliot Kimber" <email@example.com>
- Date: Mon, 07 Feb 2000 19:02:58 -0600
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
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
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
> 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
> 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
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.