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

[Len Bullard <cbullard@hiwaay.net>]

Steve Schafer wrote:
> 
> On Fri, 11 Feb 2000 20:25:55 -0600, you wrote:
> 
> >Hint:  it is obvious to map XML elements to VRML nodes and XML
> >attributes to VRML fields. If you try that, how much and what kind of
> >information do you lose if you do?
> 
> Beats me. That's why I was asking you. Or are you telling me that I
> have to go and learn VRML and redo the entire analysis myself? Some
> sort of rite of passage?

No, I gave a description of the VRML abstraction.  In one post is most
of 
the information you need.  You are well trained.  Can you do the 
analysis with groves?  Not?  Ok, then is the grove description too 
abstract to be easily understood by a well trained person?  Is the 
description I gave inadequate?  Not formal enough?  What would be 
formal enough?  A universal framework of definitions?

Which one?  It helps to evaluate the suitability of the tool as 
a universal framework of definitions for specifying languages.

> >Regardless, the point of this is to bring everyone along with the
> >discussion, to make all of the thread participants comfortable with
> >groves in order to evaluate their suitability for untangling the W3C
> >language specifications and any others.
> 
> Perhaps that is _your_ point, but it is certainly not the reason that
> I asked the questions that I did and got the thread started in the
> first place. 

There is a rather large and interesting audience here.  Some of them 
are not technical, but financial.  There is a growing unease that 
their recommendations to their investors based on the work from 
the W3C are not based on sound technology.  In other words, hacks are 
not necessarily the best way.  They are the quick way, they make a
big splash, they work for awhile, then as you say, inconsistencies 
are found.  For some, it is necessary to get the business of using 
the web on a more sound footing.  Exploring the power of groves 
may be one piece of that strategy just as getting more intelligent 
routers that can handle load balancing may be another.

> Groves are not an "end user" technology,
> any more than assembly language, for example, and I don't see a lot of
> point in expending effort in producing a _Groves for Dummies_. Nobody
> to whom that kind of book would be addressed would even care to read
> it. _Groves for Technically-Inclined Persons_ would be more realistic.

So far, the very powerful and influential people in the W3C community 
have looked past groves.  Political or technical?  If the latter, we 
can drop this.  If the former, then the consumers are ill-served.

> No, it's the second step. The first step is to observe and analyze the
> problem, and attempt to determine the requirements. 

That is why I suggest we look at some real world issues such as VRML 
and the problems of using XML as a second encoding.  There are 
both political and technical issues.  If we can demonstrate a technical 
advantage, the political issues are exposed as just that and reasonable 
individuals can proceed reasonably.  The political issues are the 
*usual ones* so we don't have to get into that.  The technical issues 
expose some interesting problems when using XML that aren't there 
when groves are applied although they reappear when the property sets 
of XML are used.

> The second step is
> to build an abstraction that you expect will be able to serve as the
> basis for the solution of that problem. 

Right.  On the table is the groves conceptual framework.  Should it 
be rebuilt, discarded, or applied?  Eliot is an influential editor 
and is suggesting the W3C could start over.  I don't feel good about 
that suggestion, but given the W3C's political influence and history 
of burglary, I'm not sure it isn't the expedient way.  I don't propose 
to change their vocation.

> That's why I'm curious about the history of VRML. It's all part of the analysis.

Right.  Coming back to that presently.

> >HTML works.
> 
> Which universe do you live in? Everyone I know despises HTML. They use
> it because it's the only game in town, but they look forward to the
> day that it finally goes away.

Hmm.  Just a short five years ago, many of us here were explaining to 
the HTML community (eg, Dan Connoly) that they had put a hack out there 
that despite its massive popularity would require the same group then 
being lambasted (the SGML community) to come back and clean up.  HTML 
and DHTML are working for many applications.  Easy to teach, easy to 
apply let's say compared to hacking in the MFC with window handles 
and the like just to build a simple dropdown box.  HTML has not been 
the only game in town for a decade.  I worked with markup systems 
on networks with stylesheets ten years ago.  Who convinced you and 
your friends that it was the "only game in town"?  Well-trained?  
Perhaps.  Easily lead or ill-informed?  Perhaps.  Perhaps it was 
just the easiest game in town.

Fact is, we take this worm a bit at at time, feed the young bird what 
it can swallow, convince the moneymen to let the bird fly, and 
we do the next sensible thing with the next worm.  At this juncture, 
we posit that we need a universal framework of definitions to specify
languages.
Now, why do we need that, what should be in that framework, and 
what will be the results of applying it?

Quick.  Another bird, the so called universal schema language, 
is about to fly.   Looking at it, in my opinion, it is yet 
another overbuilt baroque spec that may make things harder, not 
easier for the consumers.  But that is just an opinion.  Frankly, 
given good RDBs, DTDs, and scripting languages with class support, 
plus some system-specific but excellent techniques such as HTC 
files, I can do most of the work on my plate today.  A can of worms, 
yes, but easy to swallow.  I can't say the X-schema is easy to 
swallow now that a committee has hacked it.  It was a pretty good idea 
when it was DTDs as instances plus datatypes.

> Fine. I'd be happy to. So tell me about the problems you've had with
> other data abstractions so that I can try to determine whether or not
> groves would work better.

I gave a break down.  You did not find it formal enough.  I shall 
simplify.  Next post.

len