[X3D-Public] X3dom + PROTO; special profiles?

Joe D Williams joedwil at earthlink.net
Tue Nov 10 08:04:49 PST 2009




> Hi Johannes.  It is not clear to me what the rationale for your HTML 
> profile is.  It would be important to list a broad common set of use 
> cases and corresponding constraints for deployment which would 
> justify a dedicated profile.

I also suggest looking mainly at Interactive with Anchor and Inline, 
HAnim (humanoid animation), and ooh yeah, some elements of GeoSpatial, 
and some physics, NURBS, ooh Yes! and also ARIA, first. That would 
keep the basic code we need to test at a reasonable level while 
representing a fine set of capabilities.

>
> As an example, I think that such use cases could be made for a 
> Mobile Profile
> that might add a few things to the already-existing X3D Interactive 
> Profile.
> The constraints are a need for lightweight scenes (due to limited 
> bandwidth)
> that can be handled by deployed simple-capability hardware on mobile 
> devices.
> Good cross-checks on such a profile would be to approximately match 
> the
> demands/capabilities set by OpenGL ES for Embedded Systems and the 
> SVG mobile
> profiles (Tiny and Basic).
> http://www.w3.org/TR/SVGMobile
> http://www.khronos.org/opengles
>

Thanks Don, for reminding Mobile, and whatever Planet9 needs.

> As a counterexample:  when I author HTML pages, in general i plan 
> for the general web user who typically has a highly capable desktop 
> or laptop system. so as an author i'd want to be able to use X3D 
> Full Profile with HTML, likely including networked avatars with 
> physics etc. over X3D Earth locations, since there are no general 
> bandwidth or hardware constraints to constrain the capabilities of 
> Web users interacting with such scenes.
>

Right, it is only fair to think that interactive 3D in html will 
attract alternative and enhanced interfaces, including, maybe through 
ARIA, the emerging Accessibity user agents.


> In support of what you are saying, of course it is possible today to 
> properly declare the support you've defined using Interactive 
> Profile and a number of component tags.  (That might be worth 
> enumerating).  If indeed a number of scenes commonly find that level 
> of X3D capability useful, that is good evidence of the author-driven 
> use cases which might justify defining a new profile.
>

Even sub-component features. Just a couple of important nodes from a 
component. For HAnim subset, maybe just specify LOA1?

> If the rationale for a new profile is what can be done overlaying a 
> javascript X3D viewer over a WebGL layer in an HTML browser, then 
> support for XML parsing and different image formats might be assumed 
> available.

Two targets:
* An X3D scenegraph that can run in/behind <canvas> using the WebGL 
layer.
The scenegraph is 'outside' the HTML5 DOM.
* An X3D scenegraph appearing as 'Inline' user code
The scenegraph is a part of the 'null' namespace DOM.

The first means that the host Ecmascript recognizes the X3D user code.
The second choice means that the HTML 5 browser parser recognizes the 
X3D  as 'native' code.

For the second choice, the goal is that HTML5 produces the same DOM 
for text/html and for application/xhtml+xml. Fortunately(?) that 
concept seems to be wrapped around the idea that the HTML 5 browser 
has a bulit in vocabulary of language and behaviors. Is this basically 
a way to eliminate the need for namespaces in HTML 5 in any flavor? 
Well, at least in the text/html serving.

In the case of the HTML5 web browser, this means the nodenames and 
atributes names and processing are part of its built-in feature set. 
In XHTML using namespaces this is relatively easy because the 
namespace feature can identify the need for the browser to provide a 
specific addressable context in the DOM. Ideally this would identify a 
particular sequence of code that would be processed separately but 
connected, similar to what is accomplished by <object> to allow 
processing by an an integrated or add-on processor/runtime.

However, the text/html serving produces a 'flat' DOM where all inline 
user code is in the same (null) namespace. So, the path taken by 
MathML is that it has graduated from needing a separate namespace to 
becoming part of the HTML 5 namespace. The 'native' vocabulary of 
text/html is extended while the XHTML flavor can continue to use its 
reserved namespace.

OK, maybe too much, but how can the WebGL bridge gaps between the two 
areas of use?

> Maybe such a "no-plugin profile" might be tied to WebGL or O3D 
> limitations.  Hard to say if those rendering-layer APIs will have 
> any particular barriers preventing implementation of a 
> full-capability X3D player on top - a clever X3D player could likely 
> implement most X3D capabilities given some workable form of a good 
> rendering API to build on.

Far down the road this depends on how much of the internal event 
system remains in the SAI and how much gets exposed to the DOM. For 
example, putting the DOM onclick on a Box is misleading for someone 
learning the SAI. Seems like I want to skip over thinking of the X3D 
code ending up being treated as indivdual elements in the 'flat' DOM. 
I think be brave and think of X3D behaviors mostly running in the SAI 
environment. It seems like a whole different and simplified 
environment when DOM can address individual X3D elements without 
getting the running context. The svg external DOM scripting I have 
seen wants to get the context first, before changing the code.

>
> p.s. for those interested:  more thoughts on components, profiles 
> and related
> extensibility topics can be found in _X3D for Web Authors_ Chapter 1
> which is online at
> http://x3dgraphics.com
> http://x3dgraphics.com/chapters/Chapter01-Technical_Introduction.pdf
> [after some generalities, details on pp. 12-16]

Great, I'll take another look.

>
> all the best, Don

Thanks and BEst REegards,
Joe 




More information about the X3D-Public mailing list