Extending VRML, politely

Gavin Bell (gavin@krypton.engr.sgi.com)
Tue, 21 Feb 1995 16:28:06 -0800

Netscape has been criticized for implementing HTML extensions
independently of any larger design/review process.

I don't want to argue about whether or not Netscape is right or wrong
(or even whether or not it matters) for adding <BLINK> support to
their browsers, I want to discuss the larger issue of how somebody
implementing VRML browsers and tools can add new, experimental
features without angering the larger community of VRML users and

For example, part of the Inventor group at Silicon Graphics is busy
working on VRML-related stuff. What problems will be caused if we
produce a VRML browser capable of reading all Inventor nodes, and not
just the VRML draft spec nodes?

-- My thoughts: The problem is that authors might unknowingly produce
VRML worlds that could only be read into Inventor-based browsers.
That would be bad. Would a "VRMLLint" program that checked a VRML
file for correctness and use of only official VRML nodes, plus an
Inventor to VRML translator program be enough to alleviate the

I guess I'm looking for some concensus on the polite way of adding new
features to the VRML spec. Something like:

1. Implement as an experimental feature. Implement in such a way that
users know that they are using an experimental feature
2. Propose to VRML mailing list. Discuss, debate, convince.
3. Others implement/use the new feature.
4. New feature becomes part of the "official" VRML spec.

I'm an implementor, and know that designs often change in the middle
of implementation-- that's why I think it is OK to implement something
before proposing it as a standard. The danger is that there will be
several different, incompatible implementations of the same feature.
I'm convinced that will happen anyway, since design differences are
often resolved by implementing different alternatives and seeing which
one works best in practice.