Re: [www-vrml] VRML still the most popular Web3D format - by far.

[Braden McDaniel <braden@endoframe.com>]

On Mon, 2004-09-06 at 20:49 -0700, Don Brutzman wrote:
> Braden McDaniel wrote:
> 
> > [...]
> > Which, from where I'm sitting, makes "Extensible" 3D less extensible
> > than VRML97. Because I'm interested in a spec that will enable an
> > extensible implementation. VRML97 enables an implementation that can be
> > extended by plugins--written by users--which can be referred to with a
> > browser-agnostic syntax; thus enabling content that can scale to various
> > browsers. I do not see how X3D enables that approach; and (consequently)
> > I also see no mapping for VRML97 content that takes advantage of it.
> 
> This is a pretty simple matter, hopefully hard to confuse.  We've
> 
> a. kept prototypes identically as in VRML97, in all their glory.

Yes. As I (and the FAQ) have mentioned, it's EXTERNPROTO that's been
changed.

> b. added components for browser-level extensibility as well as
>     better control of browser footprint, if desired

Theoretically, I guess an implementation could provide a means for users
to register new components and associate a component identifier with a
user-defined implementation. Is that accurate?

This doesn't really add to extensibility with respect to VRML97; but it
certainly changes things. It adds a layer of packaging: now node types
must be added in aggregates. VRML97's EXTERNPROTO didn't really prevent
this; it just didn't enforce it (i.e., nothing prevented one from
packaging multiple node implementations in a single shared library). I
am inclined to think these components are more of a benefit to someone
organizing a spec than they are to someone wanting to extend a browser.

> c. augmented Inline with IMPORT/EXPORT for extending behaviors of a subscene
>     up to the parent, without having to convert everything into a prototype

That's strictly syntax. It adds nothing to extensibility.

> d. multiple mechanisms for adding new XML validation checking for new nodes.

I don't think formalized means of syntax checking contribute to
outlining an extensibility strategy for implementations. (Which is not
to say that such a thing isn't useful.)

> http://www.web3d.org/x3d/specifications/ISO-IEC-19775-FDIS-X3dAbstractSpecification/Part01/concepts.htmll#PrototypeSemantics
> http://www.web3d.org/x3d/specifications/ISO-IEC-19775-FDIS-X3dAbstractSpecification/Part01/concepts.html#Externalprototypesemantics

Curious. 4.4.5.1 includes, "...the implementation of the node type is
stored externally, either in an X3D file containing an appropriate PROTO
statement or using some other implementation-dependent mechanism." That
seems to give sufficient leeway in the implementation as to be
incompatible with what the FAQ claims. Is this text obsolete? If not,
care to square it with the FAQ?

> http://www.web3d.org/x3d/specifications/ISO-IEC-19775-FDIS-X3dAbstractSpecification/Part01/concepts.html#Components

This says a lot about how the spec describes components; I don't see
that it says anything about how these components would facilitate an
extensible browser implementation.

> So as far as X3D extensibility goes, (a + b + c + d) > a.  More isn't less.

Ahem. Funny math isn't useful.

It is spelled out in Web3D's X3D FAQ that X3D has discarded VRML97's
mechanism for extending implementations. And as far as I can tell,
*there is no upgrade path*. That is, VRML97 content that includes
EXTERNPROTOs that include references to a browser-defined implementation
have no mapping to X3D.

This has significant consequences for an implementation that uses the
extensibility model described in the VRML97 spec. I am not certain, but
I fear there could be no way to square the runtime model of such a
browser with the requirements of X3D.

-- 
Braden McDaniel <braden@endoframe.com>

-------------------------------------------------------------------------
for list subscription/unscrubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html