Re: Extending VRML, *quite* politely

Mark Pesce ([email protected])
Wed, 22 Feb 95 14:31:59 -0800


Gavin & list members -

>-- 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
>problem?

Question: Can we put some declaration at the head of the VRML file which
indicates "diffs" between the nodes as given in this file, and the nodes as
specified in the "official specification"? That way, the browser, upon
opening the file, could know if it can parse the contents of the VRML file,
or, alternately, pipe it through a local "VRMLint" utility to clean it up
before parsing. This means anyone can add any VRML node they see fit to
implement, and *any* VRML file can be read in by *any* VRML browser. In theory.

This might look like

#VRML V1.0 ascii

becoming

#VRML V1.0 ascii BinVRML CP BLAH BLAH ETC...

[This could indicate that this file contains nodes that load "binary" or
pre-compiled VRML, and uses Cyberspace Protocol-defined network addressing.]

Certainly the right place to indicate differences from the standard is in
the line which declares the file type; i.e. the first line. It also makes
it relatively easy for VRML generators to provide in-band information to
VRML parsers about which extra features have been added to the file.

Or is this too much work?

>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.

This approach, I believe, eliminates that problem.

Mark
---------------------------------------------------------------
Mark Pesce
[email protected] * http://www.hyperreal.com/~mpesce
I AM * 31 - 418 - 2012 * That's AL