[X3D-Public] Draconian restrictions on Inline loading of X3D content
brutzman at nps.edu
Wed Oct 5 10:09:52 PDT 2011
The X3D specification sayeth:
> 9.4.2 Inline
> It shall be an error to specify a file in the URL field that has a set of component definitions that is not a subset of the components of the containing world. In addition, the components shall not be of a higher support level than those used by the containing world, either implicitly or through the PROFILE declaration or additional COMPONENT statements. When an inlined world requests capabilities greater than its parent, the following actions shall occur:
> an error shall be generated,
> the URL shall be treated as not interpretable as specified in 9.3.2 X3DUrlObject, and
> the next URL shall be loaded and checked in accordance with 9.2 Concepts.
Some browsers might well already have the capabilities already
available to handle nodes at higher profiles or higher component level.
There was extensive discussion about this requirement at the time.
However I'm not sure I understand the rationale for forbidding
X3D players from handling content they can capably render.
Also relevant is the general X3D design principle to avoid requiring
X3D players to report errors if possible, since detecting and
reporting errors can sometimes add additional overhead and reduce
Here is a funky example that also illustrates a dilemma here:
+ Parent scene at Full Profile
--+ Inline child at Immersive Profile
+-+ Inline grandchild at Full profile
Wondering, do people agree that we might allow browsers to optionally
support inlined content above the specified level of the parent
(as defined in the specification) if they are able to do so.
all the best, Don
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270 MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D, virtual worlds, underwater robots http://faculty.nps.edu/brutzman
More information about the X3D-Public