[x3d-public] concerns about focus on X3D Unified Object Model (X3DUOM) [was: Leonard Dalys response]

Don Brutzman brutzman at nps.edu
Sun Aug 20 17:34:30 PDT 2017


Thanks for the insightful observations and for all related dialog getting us to this stage.

Relevant references:
=============================================================
	Wikipedia: Entity–component–system
	https://en.wikipedia.org/wiki/Entity-component-system

"Entity-component-system (ECS) is an architectural pattern that is mostly used in game development. An ECS follows the Composition over inheritance principle that allows greater flexibility in defining entities where every object in a game's scene is an entity (e.g. enemies, bullets, vehicles, etc.). Every Entity consists of one or more components which add additional behavior or functionality. Therefore, the behavior of an entity can be changed at runtime by adding or removing components. This eliminates the ambiguity problems of deep and wide inheritance hierarchies that are difficult to understand, maintain and extend. Common ECS approaches are highly compatible and often combined with data oriented design techniques."
=============================================================
	Wikipedia: Composition over inheritance
	https://en.wikipedia.org/wiki/Composition_over_inheritance

"Composition over inheritance (or composite reuse principle) in object-oriented programming is the principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class.[2] This is an often-stated principle of OOP, such as in the influential book Design Patterns.[3]"
=============================================================

These references indicate that ECS is one type of software design pattern that is not necessarily at odds with a object-oriented patterns.  ECS can achieve similar organization with perhaps-greater ease of adding further functionality at run time.

Since ECS is a design pattern, we can expect that multiple ECS approaches and implementations are possible.  Indeed some of the existing X3D implementations seem to exhibit some of those characteristics already.

One might also observe that the functional consistency of object-oriented interfaces can be thwarted if an ECS addition of components doesn't follow similar rigor.  Breaking abstract semantics and user expectations isn't good, caveat developer...

Wondering if you see anything in the existing X3D interface hierarchy, or emerging unified object model, that prevents creating an ECS implementation that is consistent with the many other types of O-O implementations that have already been achieved for X3D?

If there is something else that ECS might need defined, that is interesting too.

If ECS implementation approaches can be helped and not blocked by X3D object model clarity, then we are supporting the original motivation of the X3D Abstract Specification: functional consistency that is implementable in a variety of ways.

Abstract semantic coherence of scene-graph rendering and interaction remains our goal, supporting both conservative and progressive designs.


On 8/20/2017 8:51 AM, Andreas Plesch wrote:
> There is room for many 3d engines/frameworks/players/browsers on the very wide web, and there are many. In the declarative space there is really only a-frame which can be seen as a competitor. The success of a-frame is partially due to its ECS design, but equally due its continued, stable development and good support of developers via many channels including GitHub, slack, and meetings.
> 
> While I consider a-frame's ECS design sound, I think bringing ECS to X3D would be more of a distraction than helpful at this point.
> 
> In fact, there is also a demand for an object-oriented, hierarchical, and declarative scene graph, and x3dom currently fills that niche. Many developers may prefer an imperative approach, and fine grained control down to hardware details, but there is also a large group which is less performance minded and more structure, app minded.
> 
> To me the innovation the formal object model provides is in making the spec. and implementations more robust. However, I am not sure if it makes meaningful improvement or functional changes easier or harder. In a sense it seems to engrave the status quo more deeply, into xml. John Carlson had good ideas about that.
> 
> This is where the visions for a future x3d seem to diverge between a conservative  and a progressive approach.
> 
> Given limited participation, I think leveraging as much as possible of the existing investments in the spec., tools, and implementations will be a necessity for the foreseeable future. This favors a conservative approach unless some entity wants to provide resources for a more ambitious rethinking and overhaul. Autogenerated interface code is a good example for leveraging, among others.
> 
> How can the object model be leveraged to help deep DOM integration ? By generation of IDL ?
> 
> -Andreas

We have talked about the possibility of someday creating a WebIDL version of X3D object model, again using autogeneration techniques, as current tasks get completed.

	WebIDL Level 1
	W3C Recommendation 15 December 2016
	https://www.w3.org/TR/WebIDL-1

"Abstract. This document defines an interface definition language, Web IDL, that can be used to describe interfaces that are intended to be implemented in web browsers. Web IDL is an IDL variant with a number of features that allow the behavior of common script objects in the web platform to be specified more readily. How interfaces described with Web IDL correspond to constructs within ECMAScript execution environments is also detailed in this document. It is expected that newly published specifications reference this document to ensure conforming implementations of interfaces are interoperable."

Perhaps the consistent availability of JSON encoding and WebIDL for X3D might help us align with HTML5/DOM even further?

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



More information about the x3d-public mailing list