[x3d-public] motivations and potential renaming of OM4X3D as X3D Unified Object Model (X3DUOM)

[Don Brutzman]

Earlier this week I had an excellent in-depth discussion with Mike Russalesi on Object Model for X3D.  Some of you may already know that Mike has provided strong encouragement towards creating DLLs for X3D.  Here is a recap with further analysis and some excellent go-forward options.

1. *Problem*. The existing X3D abstract interfaces in the X3D Specification are sufficiently general to map to a variety of programming languages, but unfortunately are incomplete.  While all nodes and fields are included with strong typing throughout, X3D statements (such as ROUTE, IMPORT/EXPORT, PROTO etc.) are not specified in an object-oriented manner.  This occurred because the original design of X3D was focused on code blocks within the Script node, and were not looking at more-general goals like HTML-page-inclusion or programmatic-construction of full X3D models.

	X3D Abstract Specification: 4.4.2 Object model
	http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Objectmodel

An ASCII-art diagram originated by Joe Williams shows all interfaces and nodes (but no statements) and is found at

	X3D Abstract Specification: 4.4.2.3 Interface hierarchy
	http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#InterfaceHierarchy

2. *Motivation*. Our original efforts to fully specify all aspects of X3D for any object-oriented use were first inspired by mapping everything to fit inside HTML5 Document Object Model (DOM).  This early effort identified a number of gaps.  When we continued to work on a JSON encoding for X3D, these same issues were cast in sharp relief because JSON is exceedingly strict and thorough (hence the "O" in JSON).

3. *Approach*.  As a result of these gaps, much discussion on the mailing list and much effort by Roy Walmsley, John Carlson and myself was applied.  The X3D XML Schema as further annotated to list all fields with accessType inputOnly or outputOnly (which cannot by themselves appear in an XML or VRML model).  Strong typing and a consistent abstract interfaces were also applied to previously ignored X3D statements.  Corresponding implementations in JavaScript and Java have been built to demonstrate the soundness of these improvements. This work is described in detail as part of the Web3D 2017 Conference Tutorial.

	Figure:  Creation and Autogeneration of Object Model for X3D
	http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dCreation.png

	Design tutorial: Object Model For X3D (OM4X3D) Master Class, Web3D 2017
	http://www.web3d.org/specifications/X3DUOM/ObjectModelForX3dMasterClassWeb3dConference2017June7.pdf

4. *Insight*.  As originally hoped, many benefits and much progress has flowed from this effort.  In our discussion, it became clear that these X3D object model efforts are
a. making it progressively easier to define closely matching APIs in a variety of programming languages,
b. coherently simplifying and streamlining X3D, not creating "node bloat" or further variations, and
c. defining a _unified_ object model that makes X3D widely applicable in many domains and applications, using consistent APIs. (Thanks Mike!)

5. *Suggested steps*.  The work is converging nicely.  More to follow:
a. Adding different programming-language bindings to X3D, as shown in the recently proposed Specification Relationships diagram update, is a straightforward matter.
b. As X3DJSAIL has shown, such APIs can even be automatically created - meaning that future X3Dv4+ evolution is easily accommodated without error.
c. Renaming the (awkward) Object Model for X3D (OM4X3D) as X3D Unified Object Model (X3DUOM) better describes these powerful benefits.
d. Object model progress should be part of X3Dv4 Abstract Specification, updating and completing the existing interface hierarchy.
e. Corresponding updates should be applied to 19775-2, the Scene Access Interface (SAI) Abstract Specification.  We're going beyond Script node.
f. Development of programming-language APIs for X3D using JavaScript, Java, C, C++, C# and Python can continue to proceed in parallel.

Given the many efforts to date, renaming opinions by other contributors to the X3D object model are especially welcome.

I've taken the liberty of applying this potential rename so that we can see how it looks.  Improvements and informed consensus are always welcome.  A first-draft page collecting the current set of related assets can now be found at

	X3D Unified Object Model (X3DUOM)
	http://www.web3d.org/specifications/X3DUOM.html

	X3D Graphics Standards: Specification Relationships (proposed update)
	http://www.web3d.org/specifications/X3dSpecificationRelationships.2017August11.png

More slidesets and resource links will be added.  For example, Dr. Myeong Won Lee has an excellent Unity application running on a mobile phone that uses the draft X3D SAI for C++ to load H-Anim characters and X3Dv4 Motion nodes that provide BVH mocap animations.  Dr. Masaki Aono has also been experimenting with Python design patterns, we hope to compare these constructs to the pyjnius transcoding produced by John Carlson.   Additional experiments welcome.

It is interesting to consider how this effort has streamlined and consolidated X3D, reducing mismatches and unifying different approaches coherently.  I think that the object model unifications can be considered as useful progress in streamlining and modernizing X3Dv4.

All discussion welcome, what do you think?  Looking forward to further comment plus continuing dialog during X3D Working Group meetings.

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