xml-dev - Re: The Power of Groves: The VRML View

[Steve Schafer <pandeng@telepath.com>]

On Thu, 10 Feb 2000 19:18:31 -0600, you wrote:

>Because it is always hard to get started from an existing language 
>and its meta-definitions, then map to another meta-language or 
>framework of definitions, I am presenting an abbreviated version 
>of the VRML language as described in Late Night VRML 2.0 with 
>Java (Couch, Ballreich, Roehl and Brown).

What I'd like to see is a reasonably concise description of how XML
was found to be unsuited to the task. What specific features (or lack
thereof) of XML notation made it inappropriate for VRML? What kinds of
structural relationships were you trying to model for which XML
notation was too cumbersome?

Where I'm coming from:

Unlike Peter and probably most of the others participating in this
discussion, I'm actually very comfortable discussing all of this in
abstract terms. (Perhaps it's because I'm a physicist by training--I
don't know.) And I do strongly feel that looking at the abstract
picture is the way to understand precisely where any deficiencies may
lie.

I understand and agree that in order to make all of this great stuff
accessible to web page designers and the like, we need to come up with
something that isn't going to cause them to just roll their eyes,
throw up their hands, and walk away. But I don't think we can build
usable tools unless we have a firm, formal foundation, one which will
inevitably include numerous abstract models. Without that foundation,
we're just chasing our tails. No matter what "standard" is agreed
upon, users of tools based on that standard are going to quickly find
significant limitations, which will launch another round of
standardization, and so on ad infinitum. With a solid foundation, we
can be confident that the tools that we build on top of it have some
hope of standing up to practical use.

We need to make this stuff accessbile, but first we need to make it
work. I'm an experienced software developer; I've written parsers,
interpreters, sophisticated text and graphics rendering engines, etc.
Complex modeling and programming issues don't scare me. What scares me
is the possibility that I'm going to embark on a major journey using
groves as a fundamental data abstraction for a very large project, and
then a year from now I'm going to hit a brick wall because of some
unforeseen deficiency.

-Steve Schafer