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

[Dave]

Be careful about culling the spec to fit the hardware. By the time 
you're done, the hardware will be
at least twice as good as it currently is.

Please add Accelerometer environment sensor, if such sensor make the cut.

Dave A

Joe D Williams wrote:
>
>
>
>> 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
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org