[x3d-public] Preliminary Announcement for XSeen: problems inmotivation phrasing; multi-spec clarity, DOM interface immediacy

Sun Jul 9 14:04:02 PDT 2017

I guess there are archetype models and prototype models. I prefer prototype models, and am not really into metamodeling.

To me, an archetype is like DNA, and a prototype is an animal or vegetable. While the behavior of the archetype may be interesting, and tell the entire behavior of the prototype, I find prototype behavior much more varied and interesting to study.

I am also a Programming by Demonstration fan.

Archetype models and prototype models work together. A combination is best. I view DOM as both an archetype and prototype model combined.

Your terminology may be different, I’m just floating this as a trial balloon.

John

Sent from Mail for Windows 10

From: Don Brutzman
Sent: Sunday, July 9, 2017 4:34 PM
To: Leonard Daly
Cc: X3D Public
Subject: Re: [x3d-public] Preliminary Announcement for XSeen: problems inmotivation phrasing; multi-spec clarity, DOM interface immediacy

[TLDR summary: to help unravel problems in motivation phrasing, here is standards analysis on those topics along with an examination of immediacy for DOM interfaces.]

"Seek first to understand."  When technical mismatches or disagreements exists, it is more professional and constructive to first identify what each is saying - rather than claim an incorrect characterization not described by the topic itself.

First, here are relevant specification abstracts and excerpts of top-level interest:

==========================================================
HTML5: A vocabulary and associated APIs for HTML and XHTML
W3C Recommendation 28 October 2014
Latest Published Version: http://www.w3.org/TR/html5

Abstract. This specification defines the 5th major revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). In this version, new features are introduced to help Web application authors, new elements are introduced based on research into prevailing authoring practices, and special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability.

3 Semantics, structure, and APIs of HTML documents
https://www.w3.org/TR/html5/dom.html#dom
Every XML and HTML document in an HTML UA is represented by a Document object. [DOM]

3.1.1 The Document object
The DOM specification defines a Document interface, which this specification extends significantly:
[...]

==========================================================
W3C DOM4:  W3C Recommendation 19 November 2015
Latest published version: http://www.w3.org/TR/dom

Abstract. DOM defines a platform-neutral model for events and node trees. DOM4 adds Mutation Observers as a replacement for Mutation Events.

4.1 Introduction to "The DOM"
In its original sense, "The DOM" is an API for accessing and manipulating documents (in particular, HTML and XML documents). In this specification, the term "document" is used for any markup-based resource, ranging from short static documents to long essays or reports with rich multimedia, as well as to fully-fledged interactive applications.

These documents are presented as a node tree. Some of the nodes in the tree can have children, while others are always leaves.

==========================================================
Scalable Vector Graphics (SVG) 1.1 (Second Edition)
W3C Recommendation 16 August 2011
Latest version: http://www.w3.org/TR/SVG11

Abstract.  This specification defines the features and syntax for Scalable Vector Graphics (SVG) Version 1.1, a modularized language for describing two-dimensional vector and mixed vector/raster graphics in XML.

Appendix B: SVG Document Object Model (DOM)
https://www.w3.org/TR/SVG11/svgdom.html

This appendix provides an introduction to the SVG DOM and discusses the relationship of the SVG DOM with the Document Object Model (DOM) Level 2 Core Specification [DOM2]. The specific SVG DOM interfaces that correspond to particular sections of the SVG specification are defined at the end of corresponding chapters in this specification, as follows:
[...]
The SVG DOM builds upon and is compatible with DOM Level 2. In particular:
* The SVG DOM requires complete support for DOM Level 2 Core [DOM2]
* Wherever appropriate, the SVG DOM is modeled after and maintains consistency with the Document Object Model HTML ([DOM1], chapter 2).
* The SVG DOM requires complete support for DOM Level 2 Views [DOM2VIEWS].
* The SVG DOM requires support for relevant aspects of DOM Level 2 Events [DOM2EVENTS]. (For the specific features from DOM 2 Events that are required, see see Relationship with DOM Level 2 Events.)
* For implementations that support CSS, the SVG DOM requires complete support for DOM Level 2 Style Sheets ([DOM2STYLE], chapter 1) and relevant aspects of DOM Level 2 CSS ([DOM2STYLE], chapter 2). (For the specific features from DOM 2 CSS that are required, see Relationship with DOM Level 2 CSS.)

A DOM application can use the hasFeature method of the DOMImplementation interface to verify that the interfaces listed in this section are supported. The list of available interfaces is provided in section Feature strings for the hasFeature method call.

All SVG DOM objects that directly correspond to an attribute, e.g. the SVGAnimatedLength ry in an SVGRectElement, are live. This means that any changes made to the attribute are immediately reflected in the corresponding SVG DOM object.

==========================================================

This is such a great list of prerequisites for SVG DOM interoperability that it might serve as an excellent starting point for X3D Document Object Model (DOM) requirements as well.

The nature of the word "immediately" (in SVG DOM above) is particularly interesting.  Some implementers might construe such an interface as 'identically' from a software perspective, but please note that the specification did not use that term.  Given a user-centric functional context for all of these specifications, it sure seems more like the chosen word "immediately" means from a user perspective.

Looking even closer at event timing... At least 2 decades of experimental research has clearly shown that the timing and immediacy of 3D visualizations and of emerging VR/AR applications is quite different from that of 2D images, or of hypertext web pages.  Hence the X3D v4 motivation to align user-interaction event models, rather than conflate them.  You can find more on this topic in Web3D 2017 Conference presentation "The Future of X3D" recently given by Roy Walmsley and I.

	Presentation about Future of X3D at Web3D 2017 Conference, Brisbane, Australia
	http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3D.pdf

	Detailed notes about Future of X3D at Web3D 2017 Conference, Brisbane, Australia
	http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3dWeb3d2017June7.pdf

	Excerpted, attached is draft figure:
	Composing Event Models Between HTML DOM Page and X3D Scene

[Leonard: several requests to publish presentation documents over past month are still unresolved...  Perhaps as Web3D Consortium Webmaster you might assist?  Similarly for Mitch Williams' GearVR presentation.  Unfinished task is to link these at the session entry on the program page: http://web3d2017.web3d.org/program]

Continuing to build by repeating some key facts, to avoid mistaken claims: working group efforts plus community efforts plus multiple implementations (X3DOM, Cobweb) have made significant progress for several years.  Among many other things, current code demonstrates how
- X3D can indeed be part of a DOM Document tree structure for HTML,
- Scene graph node access can be "live" in an X3D sense (ROUTEd events) or "live" in an HTML5/DOM sense (DOM callbacks),
- Different event models for DOM and X3D are defined in specification documents, yet both can co-exist together at run time.

Roy Walmsley's "rosetta stone" example even goes a step further, illustrating how HTML5 + DOM + SVG + X3D can co-exist with both X3DOM and Cobweb simultaneously.  My reaction, as before: *Wow*.

	https://twitter.com/i/web/status/804019489905917952
	X3DOM http://www.x3dom.org  - Cobweb http://titania.create3000.de/cobweb  - discussion on #X3D public mailing list … #HTML5 #SVG
	http://web3d.org/pipermail/x3d-public_web3d.org/2016-November/005612.html

	X3DOM Cobweb Event-Passing Demos: HTML5 DOM SVG X3D
	https://youtu.be/md5oozTTw7M

HTML5/DOM and X3D standards share another fundamental similarity in that they specify user-facing functionality, rather than specific implementation source-code patterns.  That is the nature of the X3D specification revision being designed.  So, similar to any other implementer: your software approach may well work just fine (again hoping so) but it will not be the only software architecture possible that meets user-facing functional requirements for X3D.

As we continue aligning X3D v4 implementations and specifications, it remains to be seen whether the already-general HTML5/DOM architecture is 100% sufficiently general to allow complete X3D functional integration.  We may well need to add special X3D-related methods for DOM, similar to those found in SVG specification.  We certainly strive for similar integration power for X3D, but the need to add such special methods has not yet been considered or shown.  More work is needed on this important alignment task - and having multiple separate open-source approaches certainly helps.

So. Giving accurate descriptions to alternative efforts, then building upon them for clarity and further progress, is a good path to achieve success.  Such an approach is certainly how the X3D Standards process continues its progress (for more than 20 years now, without stopping).

Again as before: it is important to be wary of incorrect characterizations that can contradict or confound others, helping no one.  It is better to build, since getting clear about challenges helps focus candidate solutions to best effect.

I hope that these further explorations and explanations are useful, helping to recalibrate your motivation section accordingly.  Again wishing you well.

On 7/8/2017 7:45 PM, Leonard Daly wrote:
> Don,
> 
> 
>> Hi Leonard.  It was great to see that your project is progressing - congratulations. Implementing and evaluating possible improvements to X3D is always good.
> 
> Thank you. That is much appreciated.
> 
>> However your current motivation section has problems:
> 
> I always appreciate comments to help word things better, but in this case there is no problem in motivation phrasing.
> 
> X3D in all public releases of the standard is not DOM integrated. There are no public documents that explicitly show how a future generation of X3D would be DOM integrated. That may happen in the future, but that has been worked on without public results for over three years.
> 
> I have spent less than 3 calendar months part time putting XSeen together with the very explicit purpose of being DOM integrated. It uses DOM events, HTML scripts, and WebGL rendering that differ in detail from what X3D does. I contend that neither X3DOM nor Cobweb are fully integrated with DOM. Parts of their internal structure is exposed to and interacts with DOM, but at least the event model is not X3D or not DOM.
> 
> I never claims that X3D was not declarative. In fact with few exceptions (Shaders in particular), I think X3D is an excellent model as the design of a declarative language. The language is quite rich and expressive. To go beyond the basics in A-Frame requires a developer (someplace in the chain) writing JavaScript code and integrating it with the A-Frame API.
> 
> Leonard Daly
> 
>> =======================
>> "Why Another 3D Language
>>
>> Neither X3D nor A-Frame are designed as a declarative, DOM-Integrated language. A-Frame has several deficiencies that make it not suitable for the enterprise (see the presentation "Declarative VR/3D Environment" given at SVVR2017). X3D is not designed for the DOM. XSeen is very explicitly designed as a language that is fully integrated with the DOM and has the enterprise features of X3D."
>> =======================
>>
>> As you well know, X3D is not a frozen capability and X3D integration with DOM/HTML5 is the primary goal of X3D version 4. This several-year effort continues to progress steadily.  Multiple major implementations have integrated X3D and DOM/HTML5: X3DOM and Cobweb.  Further, VRML/X3D design has always been declarative. Successes keep accumulating, lessons learned keep growing, and further improvements keep emerging thanks to cooperative work by many people.
>>
>> Saying otherwise is incorrect and confusing to others interested in learning more about Web-based 3D technologies.
>>
>> I recommend that you improve your motivation statements. Correctly identifying strengths of relevant technologies makes opportunities for progress more understandable.  Getting clearer also helps new work constructively influence ongoing X3D version 4 development activities, benefiting everyone.
>>
>> Hope this helps.  Thanks for your many contributions and continuing efforts.
>>
>>
>> On 6/26/2017 12:46 PM, Leonard Daly wrote:
>>> The latest version of XSeen (V0.3) has been pushed to GitHub. It includes initial work on Animation. After looking at many different kinds of implementations of 3D animations, I concluded that getting the developer involved in the rendering pipeline for each frame was not needed, nor desirable. X3D though the use of events for each stage of the pipeline does put the developer in the "loop" and forces inefficiencies, especially for pre-defined (key-frame) animations.
>>>
>>> While XSeen does not yet offer full key-frame animation (just start/end points + transition style), it does illustrate how to do key-frame animation without the developer in the middle of each frame. This structure does hint at how the developer can get access when needed.
>>>
>>> In addition to code updates, there is now an XSeen project page (http://realism.com/xseen) where all of the test cases are listed. Each test case can be executed from the web page and displays as an overlay.
>>>
>>> * XSeen project page: http://realism.com/xseen
>>> * XSeen code on GitHub: https://github.com/DrX3D/XSeen/tree/development
>>> * XSeen language definition: http://tools.realism.com/specification/xseen/language-definition
>>> * XSeen internals documentation: http://tools.realism.com/specification/xseen/xseen-internals
>>>
>>> XSeen is built upon the architecture of X3D and A-Frame. The JavaScript library is supported by THREE and TWEEN plus pieces extracted from X3DOM. John Carlson provided the JSON to XML converter. It is early-stage work and not everything is fully developed out or functional. Please report any issues you have with the software or documentation. Contributions are always welcome. XSeen code is joint licensed as MIT / GPU. XSeen documentation is licensed as Creative Commons Share-Alike (CC BY-SA).
>>>
>>> -- 
>>> *Leonard Daly*
>>> 3D Systems & Cloud Consultant
>>> LA ACM SIGGRAPH Chair
>>> President, Daly Realism - /Creating the Future/
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170709/db39e820/attachment-0001.html>