If a browser lacks the code to parse a section, it would be represented by a
stand-in 'bounding box' and label, which the author (or generating tool) is
required to specify. It should be possible to distribute the parser
extension via URL reserence in the VRML file, installing it just before it
is needed. The user might be given the option to install it for future use
- otherwise it'd be discarded on exit.
One way to try out new parsers would be to use the same machine independent
scripting language used for behaviors. Some such extensions will become
popular and be ofsered in fast machine-specific form.
It should be possible to assign standard parser types to such extensions,
and allow authors to specify such a type as well as a 'fall-back' URL in
case the user doesn't have the correct machine dependent parser installed.
If a type hasn't been standardized and 'installed' in the browser, its scope
would be limited to the scope of the world it is defined in.
Someone is likely to suggest using a URL to refer to a script file, instsad
of a special embedded section. That might work, so long as a single
'extension script' file type is used, with the parsing-helper specified in
the main VRML file (so the parser can avoid downloading the script file if
it lacks the correct parser for some reason). But often the point of these
extensions is to be very compact - small enough to fit well in-line. I tend
to favor allowing in-line 'special parser' script, and letting the parser
put a URL in that section if it wishes.
Tom Craver
Intel Corporation
Opinions Expressed are Mine, Not Intel's