Re: Some Questions About VRML

Andrew C. Esh ([email protected])
Fri, 24 Mar 1995 14:55:46 -0600 (CST)


On Fri, 24 Mar 1995, Jan Hardenbergh wrote:

>
> I dod not see this thread get started, but it seems now to be discussing
> whether we should design for more than ISO/Latin1 in text.

And, like a fool, I jumped in in the middle and my comments were assumed
to be referring to just such a limitation. I want no limits. Not even ones
on progress. That's why I'm trying to talk everyone out of becoming the
center of internationalization, here. We'll never get anything done.
Can't we just leverage off the general efforts on i18n and leave it at
that? Am I going to have to try to fix VRML pages which have Chinese as
their source code? I'll leave that to someone who knows Chinese, and can
do a better job. Right now let's just get something running.

> > This is exactly the sort of thinking I cannot abide by. Why should we
> > halt all progress on a system just because a certain segment of the
> > potential users have a history of doing things differently? Why should we
> > bend over backward to accomodate a group of people who may not even be
> > aware that we are trying to help them?
>
> If VRML is going anywhere, and it has Text, it will be i18n capable.
> (i18n is internationalization - i 18 letters n.)
>
> > We need to stop thinking in terms of perfection in design, or technical
> > "utopia". There is no such thing. Progress is a process. First we write
> > lame little imagination ticklers like Doom, and then build on what we
> > learn. We cannot allow ourselves to be hobbled by the idea that VR and 3D
> > have to be perfectly designed, with all the loose ends discussed to death
> > before we can write one line of code. Think, Design, Model, Build,
> > Evaluate, and then go back to Thinking. If this cycle stops inside any
> > phase, the system ceases to function, and progress halts. There is death
> > in that.
>
> That is true for the evolution of technology. However, there is another
> force at
> work. VRML is becoming a standard. That, by definition, means parts of it
> do get frozen. The parts that get frozen should be designed for the future,
> how
> far into the future defines the lifespan of VRML.

Yes, we need to be careful with standards. We also have to be careful not
to wait too long, or other groups will skip the standard and build their
own systems. Then we have a mess, and no effective standard.

I see VRML lasting about five years, unless there is an active series of
revisions. Something better will replace it.

---
Andrew C. Esh                 mailto:[email protected]
Computer Network Technology   [email protected] (finger for PGP key)
6500 Wedgwood Road            612.550.8000 (main)
Maple Grove MN 55311          612.550.8229 (direct)
<A HREF="http://www.mtn.org/~andrewes">ACE Home Page</A>