[x3d-public] XML3D 5.0 and X3D V4.0

[Don Brutzman]

Kristian, congratulations on your great progress and thanks for the thoughtful recommendations.  (Apologies for my delayed response, have been traveling.  Hopefully you've gotten other feedback also.)

I think it would be great if you might join us for an X3D working group teleconference to discuss these points further.  If Wednesday 0800 pacific is inconvenient for you, let's find a better time.

As ever, the Web3D Working Group process is our path proven for over 20 years that supports design, consideration of alternatives, implementation, evaluation and specification.

We encourage everyone to join Web3D and follow this open process, which is an unparalleled opportunity individuals and institutions in the 3D industry, government, other organizations and academia.

Here are some quick reactions, utterly oversimplified but conversation starters, listing corresponding points that are either in support or tilting way from your key issues.

a. Streamline the model.  Profiles are defined for common use cases; components and levels allow any degree of subsetting.  Perhaps a better profile than Immersive is needed for common Web use.  Meanwhile implementations continue to support growing percentages of the X3D spec, which is quite consistent.  Yes X3D has many nodes, added gradually in response to authoring need.  Comparing X3D node count to HTML5, SVG and MathML is interesting.

b.  Support CSS.  My goodness yes.  The 'class' attribute has been reserved for some time and cascading stylesheets are mature.  Your award-winning paper at Web3D Conference 2015 and work with W3C Declarative 3D Working Group makes you a natural to lead this effort.  After laying out goals and issues, might we start the new year with CSS becoming a monthly topic?

c.  Resolve the DAG conflicts.  Can these be described, documented and demonstrated with examples please.  Our first task must be to let X3D be X3D and HTML5/DOM be HTML5/DOM, then document event passing precisely.  At that point "show stoppers" (if any) will be quite revealing.  We gained a lot of experience when reconciling External Authoring Interface (EAI) approach with a reconciled Scene Authoring Interface (SAI) that worked both externally with HTML Script code and internally with X3D Script nodes.  Of course there are many many event-passing and event-queue mechanisms in simulation that may look different at first but are actually reconcilable, all the way from discrete-event systems to real-time and distributed virtual environments.  I believe that alignment is much more powerful than attempts to homogenize.

d. Strip ROUTEs and sensors.  First law of engineering:  "if it isn't broken, don't fix it."  More slogans: there is more than one way to do things.  Further "when you come to a fork in the road, take it" provides instructive guidance.  Archival stability and broad interoperability trumps unnecessary overspecialization.  Much more interesting is mapping between event passing approaches, which likely also provides good practices that can reconcile/harmonize HTML5 and X3D design patterns for user interaction.

e. Strip Programmable shaders.  Your points are strong, and were made before... but shaders were passed anyway.  Should that still be the case, or should it be deprecated, or should further refinements occur?  Definitely a topic worth re-examination and due diligence.  At the very least we should list any security and stability vulnerabilities in detail.  Use of the Programmable Shaders Component probably should not be permitted by X3D players without deliberate warning and user authorization.  Microsoft's experience closing WebGL vulnerabilities when implementing a WebGL cross-compiler in DirectX are likely very helpful in this regard.

I was able to participate in a few brief meeting conversations during this past week and your points certainly seemed to generate interest.

Looking forward to further dialog in a working group context so that these important issues can be addressed thoroughly and deliberately.

I hope future messages might also include analysis of whether common ground exists between XML3D and X3D that might open the door to initial interchange of models.

Again thanks for excellent feedback and strategic guidance.  Good luck with your work.


On 11/26/2015 11:14 PM, Kristian Sons wrote:
> Dear X3D community,
>
> I am happy to announce that we released version 5.0 of XML3D. It is a major clean-up of things we learned within releases 4.0-4.9 since 2012. Moreover, it includes feedback from the community, further streamlines the abstract model and integrates some CSS properties. Finally, and maybe most important, we have a reasonably complete specification:
> http://xml3d.org/xml3d/specification/5.0/
>
> What's that got to do with X3D? Well we think that XML3D 5.0 includes some concepts that might be interesting to consider for X3D V4.0. We would like to highlight some aspects we focused on in the design of XML3D, but also some hurdles we had to overcome and that might be good to avoid for a web-integrated version of X3D.
>
> So starting from the X3DOM integration model (DOM API, DOM events, HTML elements as texture source and additional more efficient means to represent and transmit data), we think that (at least) the following amendments are essential for a web-integrated X3D V4.0:
>
> - _Streamline the model_: X3D has way to many nodes. Same is true for X3DOM. In particular if compared to HTML. The Web Components initiative has been started to be able build and encapsulate functionality that can be derived from existing functionality (similar to Prototypes). It includes Custom Elements which are motivated to "Rationalize the platform." Same should apply to X3D. Many nodes can be implemented with few lines of JavaScript or WebComponents. A similar discussion on "convenience nodes" was already started on this mailing list [1].
> In XML3D, we expose data processing to the user to build higher-level functionality from basic blocks. In the end, we have only like 5 real scene elements (mesh, model, light, view and group).
>
> _ Support CSS_: X3DOM has some support for CSS 3D transforms, but otherwise no CSS properties are supported (for elements other than the X3D element). Support at least "display", "visibility", "z-index" and other useful properties.
>
> - _Resolve the DAG conflicts_: There are still unsolved issues how to solve inconsistencies between the DOM tree and the X3D DAG representation! I brought up the issue on the mailing list [2] and there were three (valid) solution sketched how it could be resolved (I prefer the web-like way of dangling references). How ever the final solution looks like, it needs to be defined.
>
> - _Strip Routes and Sensors_: Routes are a nice concept, but we do not need an additional event system in the web. I think everything can be solved with DOM events, observers and there are enough APIs to generate time events.
>
> - _Strip Prototypes_: See above: The four technologies behind WebComponents provide similar functionality.
>
> - _Strip Programmable shaders_: The consortium resisted from adding platform-specific elements for so long. This component is horrible. It ties the scene not only to a specific graphics API, but also to a specific implementation and to a specific rendering algorithm (you can't use a single shader for forward & deferred shading). Better use shade.js ;)
>
> These are just recommendations from our lessons-learned. They should not be regarded as criticism. Some are really essential to solve (DAG), others would make the next version of X3D leaner and closer to web concepts. On the other hand, if applied, the result would be very similar to XML3D ;) But well, that is what we worked on over the last years.
>
> Kind regards,
>    Kristian
>
> [1] http://web3d.org/pipermail/x3d-public_web3d.org/2015-July/003474.html
> [2] http://web3d.org/pipermail/x3d-public_web3d.org/2015-April/003310.html
>


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