Lists Home |
Date Index |
- From: Len Bullard <email@example.com>
- To: firstname.lastname@example.org
- Date: Sat, 12 Feb 2000 11:40:27 -0600
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
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
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.