[x3d-public] V4.0 Open discussion/workshop on X3D HTML integration

Andreas Plesch andreasplesch at gmail.com
Wed Jun 15 17:44:21 PDT 2016


See below:

On Tue, Jun 14, 2016 at 12:31 PM, Don Brutzman <brutzman at nps.edu> wrote:

> Thanks for your note Andreas.
>
> On 6/6/2016 9:58 AM, Andreas Plesch wrote:
>
>> Hi Don,
>>
>> On Sun, Jun 5, 2016 at 2:32 PM, Don Brutzman <brutzman at nps.edu <mailto:
>> brutzman at nps.edu>> wrote:
>>
>>     Wondering if the x3dom dual-graph page dom structures align with the
>>> draft work on Shadow DOM at W3C.
>>>     https://www.w3.org/TR/shadow-dom
>>>
>>
> Interestingly the abstract for this working draft seems to indicate that
> they are defining a suggested best practice, not a required software API.
>
>         "Abstract. This specification describes a method of combining
> multiple DOM trees into one hierarchy and how these trees interact with
> each other within a document, thus enabling better composition of the DOM."
>

The abstract may sound like the spec. aims more generally at any DOM tree
but I do think it is very targeted to the HTML5 web browser environment:
https://www.w3.org/TR/shadow-dom/#elements-and-dom-interfaces



The shaw-dom spec is being upstreamed to the dom spec.
>>
>> https://dom.spec.whatwg.org/
>>
>> This is a good resource, since it also explains the web page DOM in
>> detail.
>>
>
> Yes.  Of course whatwg is not the owner of the specification, but they
> have great engagement and are highly influential with W3C.  Personally I've
> always thought that "Living Standard" is an oxymoron - how can you have
> stable interoperability if the so-called standard is allowed to change at
> any point?  Better term is likely something like "Draft Recommendation" in
> this context.  Whatever - they do good work, much of which eventually
> converges in the actual W3C Recommendations.
>
> As you know, the W3C HTML5 Recommendation is the primary reference we need
> to align with for DOM interoperability.
>
>         HTML5:  A vocabulary and associated APIs for HTML and XHTML
>         W3C Recommendation 28 October 2014
>         http://www.w3.org/TR/html5/
>
>
Well, the whatwg.org reference is straight from the w3.org spec. draft:
https://www.w3.org/TR/shadow-dom/#shadow-trees
This is why I mentioned it.

So w3.org themselves seem to view whatwg.org as the best and most up to
date  formulation of the in progress spec. recommendation.

"Living standard" may be an oxymoron but seems well established as a
concept. To me it suggests a serious attempt to advance an existing
standard in a responsible manner and with the expectation that a
significant portion is eventually agreed on as an actual standard.

I am not sure if the shaw-dom aligns with the dual graph approach because
>> the shadow-dom is still a dom structure and not a scene graph. I think it
>> may be still necessary to define a x3d dom and interfaces similar to
>> https://developer.mozilla.org/en-US/docs/DOM/DOM_Reference#SVG_interfaces
>>
>
> Yes it is interesting.  I'm pretty certain that these SVG-specific
> interfaces are in addition to the regular DOM interfaces - do you know
> where to confirm that?
>

Yes, this is my understanding. "DOM" most often refers to an HTML document
but the model can be used for any XML document including SVG.
http://www.w3.org/TR/2015/REC-dom-20151119/

Note also there is a link between HTML and SVG in that html5 has a svg
element:
https://www.w3.org/TR/2014/REC-html5-20141028/embedded-content-0.html#svg

So there are separate HTML DOM and SVG DOM interfaces where the SVG DOM
interfaces define interacting with SVG elements which on HTML5 web pages
are provided within a svg html5 element. But SVG also lives outside of a
HTML page, inkscape is an example. Outside of an HTML the same SVG DOM
interfaces can be used.

The authoritative versions of SVG DOM are typically found as appendices in
> the SVG Recommendations themselves, along with definitions in IDL, Java and
> Ecmascript:
>
>         Scalable Vector Graphics (SVG) 1.1 (Second Edition)
>         W3C Recommendation 16 August 2011
>         https://www.w3.org/TR/SVG11/
>         Appendix B: SVG Document Object Model (DOM).
>         https://www.w3.org/TR/SVG11/svgdom.html
>
>         Scalable Vector Graphics (SVG) Tiny 1.2 Specification
>         W3C Recommendation 22 December 2008
>         Appendix A. The SVG Micro DOM (uDOM)
>         https://www.w3.org/TR/SVGTiny12/svgudom.html
>
>          Mobile SVG Profiles: SVG Tiny and SVG Basic
>         W3C Recommendation 14 January 2003, edited in place 15 June 2009
>         https://www.w3.org/TR/SVGMobile/
>         Appendix G. Mobile SVG DOM
>         https://www.w3.org/TR/SVGMobile/#sec-dom
>
>         Scalable Vector Graphics (SVG) 2
>         W3C Editor’s Draft 14 June 2016
>         https://svgwg.org/svg2-draft/
>         Appendix A: SVG Document Object Model (DOM)
>         https://svgwg.org/svg2-draft/svgdom.html


The mozilla mdn pages are just convenient and give a browser developer's
view including what is actually implemented.

    I'm hoping that John Carlson gets a chance to look at whether his JSON
>>> prototype expander might be adaptable as part of x3dom - that would be
>>> pretty valuable.  Although Fraunhofer has outstanding prototype support in
>>> their Instant Reality engine, it has never been clear why that code can't
>>> simply be applied in x3dom as well.  Certainly a consistent approach would
>>> seem to make both codebases more coherent and maintainable for them.  If
>>> Fraunhofer refuses to adapt or release the Instant Reality prototype code
>>> then we will just have to do it ourselves... John's work seems like a big
>>> step in that direction
>>>
>>
>> Well, I would not have a good idea on how to implement prototypes in
>> x3dom. Not sure if the Instant Reality code would really help. One idea may
>> be to see if there is an existing declarative way to register new custom
>> elements using web components, and extend that. But I do not think there is.
>>
>> https://www.w3.org/TR/custom-elements/
>>
>
> Here is the premise:
> - X3DOM is written in JavaScript and can read X3D nodes.
> - Prototype Expander is is written in JavaScript and can write X3D nodes.
> - Prototype Expander could be a preprocessor for X3DOM scene loader.
>

Not sure of thinking about Protos as something to be expanded is quite
correct. It well may be. Would expansion not be akin to a macro or template
? javascript for web pages has plenty of templating solutions involving
preprocessing.


>     Also thanks for pointing out important questions about Fraunhofer's
>>> stewardship of the X3DOM project.  It will be good to learn more about
>>> their intentions so that our community can align effectively.  There has
>>> been no handoff.
>>>
>>
>> Well, there have been no fixes or updates to the code base on github for
>> a long time and a recent issue response suggested that FHG considers x3dom
>> community supported.
>>
>
> Certainly there may be important roles for a few Consortium members to
> ensure that the working group's X3D version 4 efforts are being coherently
> implemented and integrated in both the X3DOM and Cobweb open-source
> codebases.  "Implement and evaluate" is how we ensure any specification
> functionality actually works. Plenty of room for community participation
> too.  8)
>
>     Regarding the X3D event system: a changing value of any field in any
>>> node can be sent as an input to any field in any node, as long as types
>>> strictly match (apples to apples).  Rephrased: a ROUTE passes a
>>> time-stamped value from one node to another. Internal to an X3D scene
>>> graph, that has been implemented dozens of times.  Seems extremely simple.
>>>
>>
>>     External to an X3D scene graph, meaning via a browser using the Scene
>>> Access Interface (SAI), mechanisms are similarly well defined.  Since the
>>> DOM is string based, and since any X3D event value can be expressed as a
>>> string, it seems like we have a straight connect-the-dots approach awaiting
>>> us.  Forgive me for using a four-letter word, but if interested individuals
>>> might actually _read_ the HTML5/DOM and X3D specifications, then the
>>> answers to most implementation & alignment questions are likely spelled out
>>> for us.
>>>
>>
>> https://dom.spec.whatwg.org/#events would be HTML5 side of events.
>>
>> Is the statement at https://dom.spec.whatwg.org/#action-versus-occurance
>> compatible with
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Events
>> ?
>>
>
> Seems like a part of the mix of information to explore...
>
    It will be great to get our wiki organized for clarity and go-forward
>>> action on these important X3D version 4 design issues.
>>>
>>
>>     Thanks for letting us know about your other explanations - very
>>> interesting!  8)
>>>
>>
>> Yeah, VR is not really part of this discussion (although it could be a V4
>> topic) .
>>
>
> Mostly expecting that much of VR support is part of the Mixed and
> Augmented Reality (MAR) spectrum we are already exploring/supporting with
> ISO for X3D v4.1.  Probably more is needed as well.  Draft MAR Reference
> Model is online (for Web3D members) and will be a hot topic at Web3D
> Conference 2016 next month.
>
>         Mixed Augmented Reality (MAR)
>         http://www.web3d.org/working-groups/mixed-augmented-reality-mar
>
> and
> ==========================================================
> http://www.web3d.org/member/mixed-augmented-reality-mar-member-resources
>
> Mixed Augmented Reality (MAR) Member Resources
>
> Mixed and Augmented Reality (MAR) capabilities present computer-generated
> information within the real world, developing compatible extensions to X3D
> visualization and interactivity that implement an emerging ISO reference
> model.
>
> This page includes some Web3D Member-Confidential resources for the Mixed
> Augmented Reality (MAR) Reference Model being produced by ISO/IEC JTC1/SC24
> Working Group 9.
> * N 3778 ISO-IEC CD2 18039.pdf
> * Perey-MAR_RefModel_March_24_2015.pdf
> * nwip_form-mar-fc-feb-20.pdf
> * MAR-info-model.2016February21.pdf
> ==========================================================
>
>     Looking forward to continuing, sustainable evolution and progress
>>> together.
>>>
>>
>> I think if there is way to open spec. drafting more along the lines of
>> other www spec. efforts on github, there is a chance to attract a wider
>> community for more man power which would be much needed.
>>
>> Andreas
>>
>
> Yes good ideas.  Web3D Consortium has always strived to find the right
> balance.
>
> Good progress:  Roy has been carefully adding each of the many X3D
> Specifications to Github, and group editing of new versions is underway.
>  Access is limited to Web3D members who request it.
>
>         https://github.com/Web3DConsortium
>
> Membership is open to all organizations and even individuals.
> Participation has benefits, modest fees are necessary to support this good
> work.  The membership agreement also has strict rules regarding
> Intellectual Property Rights (IPR) that have successfully protected this
> entire body of work as a royalty-free public resource of great value.
>
>         http://www.web3d.org/participate
>
>         http://www.web3d.org/join
>
> In every case for the many X3D specifications over the past two decades,
> community input and community review is included in our process.  This is
> well recognized as fundamentally important - indeed essential for success.

Thanks for your insights and the great continuing discussion Andreas.
>
> v/r Don
>
>
>     On 6/3/2016 11:40 AM, Andreas Plesch wrote:
>>
>>         Hi Roy, group,
>>
>>         I would like to join the 2h open discussion on Wednesday but will
>> be in an all day meeting, actually on the West Coast.
>>
>>         These are excellent questions and trying to answer them will help
>> getting closer.
>>
>>         Here are some thoughts.
>>
>>         The discussion on introducing an id field seemed to point towards
>> the need to have fuller integration in the sense that it is difficult to
>> isolate features. It may be necessary to define a x3d dom similar to the
>> svg dom, with the corresponding interfaces. svg is very successful on the
>> web but it took a long time to arrive there.
>>
>>         x3dom has a dual graph approach. There is the x3d graph and in
>> parallel the page dom graph which are kept in sync but are both fully
>> populated. Johannes would know better how to explain the concept.
>>
>>         It looks like FHG decided that x3dom is now considered community
>> (only?) supported. This probably means it will be out of sync as newer web
>> browsers arrive, or webgl is updated.
>>
>>         I explored Aframe a bit more. It will be popular for VR. It is
>> still in flux and evolves rapidly. The developers (mozilla) focus on its
>> basic architecture (which is non-hierarchical, a composable component
>> system) and expects users to use javascript to develop more advanced
>> functionality (in the form of shareable components). So it is quite
>> different, fun for developers, and for basic scenes easy for consumers.
>> Since most mobile VR content at this point is basic (mostly video spheres
>> and panos), it is a good solution for many.
>>
>>         (As a test I also implemented indexedfaceset as an Aframe
>> component, and it was pretty easy - after learning some Three.js. So it
>> would be possible to have x3d geometry nodes on top of aframe. Protos,
>> events and routes are another matter but also may not be impossible).
>>
>>         There is still space for x3d as a more permanent, and optionally
>> sophisticated 3d content format on the web.
>>
>>         Event system: My limited understanding is that on a web page, the
>> browser emits events when certain things happen. Custom events can also be
>> emitted by js code (via DOM functions) for any purpose. (All ?) events have
>> a time stamp and can have data attached. Then, events can be listened to.
>> There is no restriction to listening, eg. all existing events are available
>> to any listener. A listener then invokes a handler which does something
>> related to the event. js code can consume, cancel, or relay events as
>> needed (via DOM functions). It is not unusual that many events are managed
>> on a web page. events can be used to guarantee that there is a sequence of
>> processing.
>>
>>         So how does the x3d event system relate ? There is a cascade, and
>> directivity. How long does an event live ? one frame ? Until it fully
>> cascaded through the scene graph ?
>>
>>         Since x3dom and cobweb are currently the only options, from a
>> practical stand point a question to ask may be this: what is needed to make
>> x3dom and cobweb easy to use and interact with on a web page ? Typically,
>> the web page would provide an UI, the connection to databases or other
>> sources of data, and the x3d scene is responsible for rendering, and
>> interacting with the 3d content. For VR, the UI would need to be in the
>> scene, but connections and data sources would still be handled by the web
>> page.
>>
>>         Cobweb in effect allows use of the defined SAI functions. Is it
>> possible to define a wrapper around these functions to allow a DOM like API
>> (createElement, element.setAttribute .. element = null) ? It may be since
>> they are similar anyways and it would go a long way. But it still would not
>> be sufficient to let other js libraries such as D3.js or react control and
>> modify a scene since they would expect x3d nodes to be real DOM elements.
>>
>>         VR: A current issue is control devices. It would be probably
>> useful to go over the spec. and see where there is an implicit assumption
>> that mouse or keyboard input is available. VR HMDs have different controls
>> (head position and orientation(pose), one button) and hand held controllers
>> (gamepads, special sticks with their own position/orientations) or the
>> tracked hands themselves become more popular. In VR, you do want to your
>> hands in some way.
>>
>>         Perhaps, it makes sense to have <Right/LeftHand/> nodes
>> paralleling <Viewpoint/> with position/orientation fields which can be
>> routed to transforms to manipulate objects ?
>>         How  a browser would feed the <Hand> nodes would be up to the
>> browser. InstantReality has a generic IOSensor.
>>
>>         Andreas
>>
>>
>>         On Wed, Jun 1, 2016 at 4:53 PM, Roy Walmsley <
>> roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com> <mailto:
>> roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>>> wrote:
>>
>>             *X3D HTML integration____*
>>
>>             *__ __*
>>
>>             *X3D V4.0 Open discussion/workshop____*
>>
>>             *__ __*
>>
>>             *June 8^st 2016 at 1500-1700 UTC (0800-1000  PDT, 1500-1700
>> GMT, 1700-1900 CET)____*
>>
>>             *__ __*
>>
>>             A discussion/workshop on version 4.0 of X3D which aims to
>> consider the following questions, and suggest potential solutions.____
>>
>>             __ __
>>
>>             __·         __What level of X3D integration into HTML5 do we
>> want?____
>>
>>             __o   __Do we want to be fully integrated like SVG?____
>>
>>             __·         __Do we want/need a DOM spec? If so:____
>>
>>             __o   __Which DOM version should it be based on?____
>>
>>             __o   __Do we want to fully support all DOM/HTML features?____
>>
>>             __·         __Do we want to maximize the backwards
>> compatibility of V4.0 with V3.3? Or break away completely?____
>>
>>             __o   __Do we want to retain SAI?____
>>
>>             __·         __What features do we want? For example,____
>>
>>             __o   __How is animation to be handled? The X3D way of
>> TimeSensor and ROUTEs, or an HTML way, such as CSS3 animations, or else
>> JavaScript?____
>>
>>             __o   __How is user interaction to be handled? The X3D way of
>> Sensors, or the HTML way with event handlers?____
>>
>>             __o   __Do we need any different nodes? One example might be
>> a mesh node?____
>>
>>             __o   __Do we want Scripts and Prototypes in HTML5?____
>>
>>             __o   __How do we want to handle styling?____
>>
>>             __·         __What profile(s) do we need for HTML?____
>>
>>             __ __
>>
>>             The discussion/workshop will be held on the Web3D
>> teleconference line. It is open to anyone interested in X3D. Please e-mail
>> roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com> <mailto:
>> roy.walmsley at ntlworld.com <mailto:roy.walmsley at ntlworld.com>> or
>> brutzman at nps.edu <mailto:brutzman at nps.edu> <mailto:brutzman at nps.edu
>> <mailto:brutzman at nps.edu>> for teleconference details.____
>>
>>             __ __
>>
>>             If you can’t join in the discussion, but would still like to
>> contribute to the debate, your comments would be welcomed on the X3D public
>> mailing list at x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>> <mailto:x3d-public at web3d.org <mailto:x3d-public at web3d.org>>.____
>>
>>             __ __
>>
>>             Roy Walmsley____
>>
>>             X3D WG Co-chair____
>>
>>             __ __
>>
>> [...]
>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>
> 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 graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>



-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160615/2b0dbfcc/attachment-0001.html>


More information about the x3d-public mailing list