Re: PHIL: Constraining the Discussion

Mark Waks (justin@dsd.camb.inmet.com)
Fri, 17 Jun 94 12:46:29 EDT


Mark argues for a bit more focus in the discussion:
>I am not saying that these other issues are unimportant; just that in the
>context of developing an initial VRML specification, they are not relevant.
>In fact, before level-of-detail or object registration in a shared
>environment can be discussed cogently, we will need some real-world
>experience with VRML, understanding its drawbacks and strengths, before we
>can go and revise the specification. VRML must be allowed to evolve; to
>expect it to emerge, full-grown, Athena-like, from the mind of this list,
>smacks of self-indulgence. We haven't even begun to use VRML yet, what
>makes anyone think they have the answers when we can't even formulate the
>questions?

Agreed, but with reservations. One lesson of history is that languages
that are written without a clear understanding of their context tend
to be miserable failures. That applies here just as much as anywhere.
Saying that we can simply go back and revise VRML ignores how fast
things tend to set in concrete in the computer biz. If we create a
language that is really lousy for the application, it'll get out,
people will look at it, decide that VRML is a complete waste, and
ignore any further efforts. (Don't laugh -- this is exactly the
problem that Ada 9X, the new revision of the language, is facing.)
If we create a language that is sorta okay, but limited, people will
write tools for it and be unwilling to scrap those tools if we
have to overhaul the language heavily. It's important that the
language we create be at least *close* to a likely final model, and
that the upgrade path be straightforward.

Essentially, this discussion has been about the requirements for
the language (at least, most of it has). And I think that that's
been very useful in understanding the problem that we're trying
to solve.

Now that said, I think we've probably talked out most of the Grand
Issues, and are converging on some consensus. What we're writing, at
least initially, is an object description language. The language needs
to have some capabilities for inheritance, and needs to support some
mechanisms for scalability, allowing different browsers to interpret
scenes at different levels of detail. It should support some sort of
mechanism allowing the browser to pick up local copies of objects,
instead of necessarily fetching them over the Net. It should be
straightforward to subset, so we can write the critical bits first.
Any other requirements that I've forgotten?

-- Justin
Who should also point out that coming up
with a requirements list in one week
is *lightning* fast by real-world
standards...

Random Quote du Jour:

On Modern Music:
"The biggest innovation is an electronic marvel about the size of an old-
fashioned record player, called a sampler. With it, you can record snatches
of other people's music digitally (ie, with a sound quality that matches the
original) and then mix them up and call the product your own. No youngster
fancying his future as a composer need be deterred by an ignorance of music
theory, lack of skills or advanced tone deafness."
-- from The Economist