Lists Home |
Date Index |
- From: Steve Schafer <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 11 Feb 2000 23:09:38 -0600
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?
>If you don't know you may be less trained or more uncomfortable than you
>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. I am looking to become a "consumer" of the grove
paradigm, to use it as a basic data abstraction, to build tools that
understand it, etc. I may very well be able to turn that work into
something useful that I can give to others who are not interested in
the fine details, but that is not my primary motivation. I need groves
(or whatever abstraction I settle on) for purely pragmatic reasons. If
I learn something useful while I'm implementing groves, I will
certainly share it, but I assure you that most of what I figure out
about groves, at least in the early stages, is going to be highly
technical and of no direct interest whatsoever to those who are trying
to, say, set up an e-commerce web site next month. What I learn about
groves may in fact be useful to these kinds of users down the line,
but by that time I or someone else will have hopefully wrapped up the
groves to such an extent that these users will never even need to know
that the groves are there. 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.
>> And I do strongly feel that looking at the abstract
>> picture is the way to understand precisely where any deficiencies may
>Not necessarily first.
No, it's the second step. The first step is to observe and analyze the
problem, and attempt to determine the requirements. 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. I started this thread because
I wanted some feedback, some assurance that I wasn't heading down a
dead-end path. I wanted to hear success stories, but I also wanted to
hear failure stories, from people who tried groves or DSSSL or HyTime
or XML or something similar, and couldn't get it to work. That's why
I'm curious about the history of VRML. It's all part of the analysis.
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.
>Then I would say the best thing is to help those of us who are not
>so well trained to understand this so we will not as a mass embrace
>something that will trouble you or us later.
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.