[x3d-public] motivations and potential renaming of OM4X3DasX3DUnified Object Model (X3DUOM)

[John Carlson]

I’d also like to discuss the Object Model XSD http://2014.web3d.org/specifications/x3dObjectModel.xsd and how it relates to other standards. This is a meta model, or a schema for the object model.  Should this be integrated with the X3D XML schema?  Should we use a different standard besides XSD for this?  There is already a rich set of OO and model driven architecture standards. If we do integrate the two XSD schemas, can end users extend the object model (archetypes) to extend X3D similar to prototypes?  Does the object model replace the schema and schematron as the basis for X3D validation?

John

Sent from Mail for Windows 10

From: John Carlson
Sent: Sunday, August 20, 2017 6:08 AM
To: Leonard Daly; Don Brutzman; X3D Graphics public mailing list; Roy Walmsley
Cc: Myeong Won Lee; Michael Russalesi; Masaki Aono
Subject: RE: [x3d-public] motivations and potential renaming of OM4X3DasX3DUnified Object Model (X3DUOM)

Really, there should be more tools for standards interoperability between the semantic standards, the schema standards, the specification language standards, and the object modeling standards.   Where should I bring this up?  Is there a body which looks at interoperability between standards?

I am aware of an XSD to OWL converter. We may be able to modify it to include our XSD extensions.  Does anyone else know of tools to convert between the previous set of standards? Can we better spend our time working on existing standards and extending them, instead of creating our own standards?

John

Sent from Mail for Windows 10

From: John Carlson
Sent: Sunday, August 20, 2017 5:56 AM
To: Leonard Daly; Don Brutzman; X3D Graphics public mailing list; Roy Walmsley
Cc: Myeong Won Lee; Michael Russalesi; Masaki Aono
Subject: RE: [x3d-public] motivations and potential renaming of OM4X3D asX3DUnified Object Model (X3DUOM)

Also, how do the semantic standards like RDF/RDFS and OWL relate to the object model? Would it be better to represent the object model in these standards, and get the advantages of the tools to edit, search, etc. associated with them, instead of going out and creating our own schema for modelling which we have to write all the tools for?  If the object model was in RDF or OWL, would we be able to generate X3DJSAIL and the abstract specification from it using NLP tools, in multiple languages?

I’ve already mentioned specification languages with regards to this, but was ignored.  There is an ISO standard specification language.  Anyone care to use it?  What are standards for when you can invent your own?

I sniff NIH.  It smells bad.  We should be using standards generated by the standards community.

Also XMI comes to mind  http://www.omg.org/spec/XMI/2.5.1/PDF I have also mentioned this before, but probably in a smaller group.

John

Sent from Mail for Windows 10

From: Leonard Daly
Sent: Saturday, August 19, 2017 10:12 PM
To: Don Brutzman; X3D Graphics public mailing list
Cc: Myeong Won Lee; Michael Russalesi; Masaki Aono
Subject: Re: [x3d-public] motivations and potential renaming of OM4X3D as X3DUnified Object Model (X3DUOM)

Don et al,

I appreciate the construction of an object model for X3D as laying a strong foundation for understanding the structure of the existing standard and providing a path for future evolutionary development of the standard.

I do have the following concerns:
1) The name is very close to an existing and well-known product - X3DOM. In fact this name looks like a typo of that. Unless a major education effort is made, there will be confusion when people see just the name; beside the verbal use will sound like "X3 dumb". Since the Consortium is very resource-limited, I suggest the (significantly less) effort be put into developing a new and non-conflicting name.

2)  No work has been done to identify what features should be in a web-based 3D/VR/xR graphics standard. This starts with a basic premise that the standard needs to support 3D (and other) graphic capabilities in a specified collection of environments. Then the concept requirements are developed and refined so that they meet the usual requirement conditions (consistent, complete, etc.) plus there exists a path from the existing situation (probably X3D V3.3) to the desired end goal. Not doing this reach step leads to incremental enhancement of the existing standard. We know that incremental enhancement is insufficient because there is minimal adoption of X3D compared to other standards that have been around a shorter amount of time - glTF, WebGL, THREE.js, etc.

3) In my conversations with Mike Russalesi, I understood his interest in developed DLLs and other libraries that would read and write X3D to compete with FBX (primarily) and glTF (by extension). X3D does a lot more than FBX and a bit more than glTF, especially in the area of user interaction. Developing an Object Model for V3.x and applying that to the future (V4+) will not address the need to I/O libraries and the need and requirements for an interchange format. For example, X3D and glTF both include lights. In cinematic computer graphics (the kind used for movies, TV, and games), lighting of all kind is the responsibility of the lighting technical director. It does not belong with the modeler or animator (though on small productions these may be the same person with different responsibilities). A modeler who insists that his/her lighting be used will not have a job for very long.

4) As I understand object modeling in computer science, it is done before the specification is developed. I have never heard of an object model being auto-generated from an XML Schema from a specification document.  The (ASCII-Art) diagram developed by Joe was originally done to make sure that the interfaces and node hierarchy was consistent and complete, and to illustrate the relationships between the various nodes (abstract and concrete) and interfaces. The source for this diagram was the specification text, not the other way around. I do not remember ever trying to fit X3D into DOM (especially since DOM is an API), though it may have been an effort not part of the X3D WG.

5) Game engines for at least the last 10 years have used an Entity Component System (ECS). ECS was developed in the early 2000's because of performance issues with handing extensive object hierarchy. ECS is how Unity, Unreal, and A-Frame work. It drives their internal data structure and run-time. Without some sort of explanation of how X3D can be used in an ECS, it will be dismissed by the entire game community. [Note that THREE more closely aligns with WebGL and is more object-oriented.]

6) The Consortium is very resource limited. It has having difficulty keeping up. One of the recommended standards is over 10 years old (19777-2) and other one is only at Committee Draft (CD) text level. The graphic capability of X3D is significantly behind the industry for appearance (no bump maps, occlusion maps, opacity maps, displacement maps,...), animation using GPUs, multiple lighting models, and physically based rendering. Creating more work, especially in the area of ISO standardization will totally exceed the capacity of the volunteers who do this work. There is significantly less work involved in producing a Consortium standard, so that might be more achievable.

7) I believe that the Consortium should clearly define what it wants to achieve and develop a plan (including schedule and budget) necessary to get there. Work that is not specifically on the plan that does not impede the plan is great, but cannot use Consortium resources that interfere with work on the plan. This plan needs to be approved by the BOD so everyone is on board. It can then be used as a selling point for membership because it is clear what is being worked on and what is the schedule.


Leonard Daly

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 

-- 
Leonard Daly
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - Creating the Future 



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