Re: Extending VRML, politely
Donna Marie Calcote (firstname.lastname@example.org)
Tue, 21 Feb 1995 20:48:45 -0600
>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?
this is good forethought. you are providing for potential developments.
>-- 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
it would be a good start!
>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
yes. let them know that it is experimental and that they use it at their own
>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.
when the concensus is that the new feature is a valuable addition to the 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.
any experienced software developer knows that features under development by
a group may have design differences to resolve, and if we get independent
input from a variety of sources with all bearing in mind that the 'final'
implementation will most likely be a compromise of the various contributions.
build in the features, but make them easily removeable.
email@example.com|donna marie calcote|our lady of the cosmic frame
creation is phuzziesopht|1's & 0's are dolphins' dreams|musician for hire
rhetorical questions? homie don't play that|i want my world-wide-web ;)
more information is better.|it <CAN> happen!--colin powell