> What happens when an author specifys a non-VRML URL for a WWWInline?
> There are a couple of possibilities:
> 2. The WWWInline wraps up other types into 3D objects. For example,
> referencing a 2D image could result in a texture-mapped rectangle being
> the WWWInline's appearance. A pretty cool feature, but it adds a lot
> of implementation burden and supporting all of the common MIME types
> would be almost impossible.
It doesn't add much implementation burden if the navigator response is
"sorry, not supported" (or more likely, inserting some default
geometry representing the <unrecognized geometry> symbol at the appropriate
location, not unlike Mosaic's usage of the NCSA logo (though that was an
odd selection, to my mind)). True, it may be that a souped-up RTF inliner
is unlikely to be implemented in most navigators... but is that any reason
to block this valuable extension path for all the MIME types which
*would* be very desirable to support? (And you might be surprised at
how easily most mailcap-specified viewers might be intergrated into
inline VRML texture overlays, if a general X display->texture interface
were written.)
> 3. Behavior is left up to the implementation.
Yes... but as Linas has suggested in other contexts, we can provide
some implementational guidance so that each navigator doesn't derive
a completely different interpretation of the types.
> I suggest WWWInline node understand only VRML references, and consider
> all other types errors (option 1).
I don't see why this should be the case. I posted a case example (a
spiced-up VRML version of the _Inventor Mentor_ cover) last Tuesday
using WWWInline on non-VRML data, and like Robert Glidden, I
think we should definitely leave room for supporting inlined non-VRML
objects. To return to my justification last Tuesday,
< Sure -- I don't expect all this [inlined HTML, images, video, spatialized
< audio sources, scripted geometry-synthesizers, etc.] to be possible in a
< first-pass implementation, though I don't really think these examples are
< far-fetched, or even beyond what we might hope to see in six month's time
< (with the possible exception of the weather .mailcap synthesizer ;-) But
< in the interest of supporting future VRML extensions without kludging
< in various gross hackeries, let's try to leave the navigator interpretation
< of inlined data types as general as possible. It's no sin if some legal
< expressions have no implemented support in the early generations.
Is this still problematic?
Brygg