[x3d-public] IMPORT/EXPORT Use [was: Statement permitted placements]

Don Brutzman brutzman at nps.edu
Sat Jul 15 13:49:47 PDT 2017


On 7/14/2017 12:08 PM, Leonard Daly wrote:
> Roy did a very detailed analysis of statement location.

Yes.

Getting consistent expressions among all the encodings and language bindings will help us avoid problems.  Once again, Object Model for X3D (OM4X3D) shows relevance and can help describe statement location in an object-oriented manner for language bindings.

> I think that any discussion of IMPORT / EXPORT statements may be premature until it is figured out how files and their nodes will be inlined in HTML. There is a single namespace and namescope in HTML causing the following issues when X3D is integrated with DOM:

Leonard, not understanding why there seems to be a namespace conundrum, it does not have to the case.

There are scene demos already showing event routing using DOM, event routing using ROUTES, and a mix (for example ROUTEs in Cobweb-supported scenes).

Keeping HTML attributes for id associated with DOM events, and separately keeping X3D attributes DEF/USE for ROUTE events, avoids name-collision problems.

This approach has even further appeal because it can work satisfactorily in a single global DOM tree (which I think you assume) or a primary + shadow DOM approach which decouples ordinary page-refresh HTML from high-frame-rate interactive 3D graphics.

Scoping of X3D DEF/USE visibility already occurs within a ProtoDeclare, and within one or more loaded Inline subgraphs (which already handles your case 4 below), so it is not a far step to similarly define such scoping/separation of namespace tables once in the DOM.  The DOM has no knowledge of DEF/USE, X3D ROUTEs have no knowledge of id attributes, and so coexistence can occur without collision.

In that sense, since the specifications are currently distinct: X3D ROUTE assing events to an HTML5/DOM id (or conversely, HTML5/DOM events to an X3D DEF node) is not defined, and only becomes a problem if new specification definitions create such a problem.  We do not have to create such a conundrum.

This has been brought up a number of times but still does not appear in your list of alternatives.  Please consider how it avoids the difficulties you describe.  Perhaps there is a better way to describe how this can work?

Simple illustrative diagram attached with descriptive prose in following Web3D 2017 presentations.  We can further refine and improve this loosely coupled approach based on implementation experience using X3DOM/Cobweb in various HTML browsers.  The "rosetta stone" bouncing-ball example (showing HTML5+DOM+SVG+HTML events+X3D+X3D events+user interaction) is a good place to start.

	X3D Version 4
	http://www.web3d.org/x3d4

	"Future of X3D" presentation and detailed notes from Web3D 2017 Conference, Brisbane Australia, 7 June 2017
	http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3D.pdf
	http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3dWeb3d2017June7.pdf
	http://www.web3d.org/sites/default/files/image/wg/X3D%20Version%204/PresentationPanoramaFutureOfX3dPaulGrimm20170607_135611.1600x492.jpg

This loose coupling may be a variation on your approach (C) below? - not sure.  Reconciling Inline/IMPORT/EXPORT names is the same for for event passing to/from any node.  If IMPORT/EXPORT only refer to a DEF name within scoped X3D scene graphs, no collisions occur (as already shown in other X3D encodings).

In any case we can't conflate HTML5/DOM event passing with X3D event passing.  They are different.  W3C controls those specifications, while we are aligning X3D specifications to coexist well.  W3C describes functional semantics for the HTML5/DOM/SVG/MathML part of the DOM tree, we will describe functional semantics for the X3D part of the DOM tree.

Thanks for considering these valuable possibilities.


> 1) All nodes are available to all other nodes at all times
> 2) IMPORT does not have any meaning
> 3) EXPORT does not have any meaning
> 4) Uncertain how to handle a file that gets Inlined more than once since all DEF and ID from the Inline will be duplicated
> 
> Possible solutions are:
> A) Do not put the contents of any Inline into the DOM
> B) Do not put the contents of any X3D file into the DOM
> C) Modify the DEF & ID values on each Inline so they are unique
> 
> (A) has the potential problem of completely hiding all of the interior nodes and making it unavailable. In this case IMPORT and EXPORT can be defined to make sense by providing access to those fields. Unfortunately this breaks a different goal of full DOM integration.
> 
> (B) This is like (1), but more extreme. It essentially makes X3D plugin-like in that there is complete separation between DOM and X3D.
> 
> There is a variant on (A)/(B) where only certain (developer controllable) Inline contents are loaded into the DOM. This partially breaks the goal of DOM integration and still leaves the problem of keeping DEF/ID values unique (C)
> 
> (C) This solution creates a virtual namescope in that the DEF/ID values are modified so that they are unique within the parent DOM. This is potentially tricky since these values can be programmatically assembled. It might be possible to make all of the necessary modifications to the nodes in the Inline file, but unsolvable (or close to it) to change other code in either the parent or other Inline nodes that may cross-refer to those values.
> 
> 
> -- 
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
> 
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 


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 --------------
A non-text attachment was scrubbed...
Name: ComposingEventModelsBetweenHtmlDomPageAndX3dScene1200x927.jpg
Type: image/jpeg
Size: 288385 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170715/055a7e59/attachment-0001.jpg>


More information about the x3d-public mailing list