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

[Andreas Plesch]

Date: Sat, 15 Jul 2017 13:49:47 -0700

> From: Don Brutzman <brutzman at nps.edu>
> To: Leonard Daly <Leonard.Daly at realism.com>
> Cc: <x3d-public at web3d.org>
> Subject: Re: [x3d-public] IMPORT/EXPORT Use [was: Statement permitted
>         placements]
> Message-ID: <c4d14574-4751-f384-0fe2-988b2e754701 at nps.edu>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> 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.
>

At first glance there is the major difference that X3D inline has a
protected, separate namescope while dynamically added content (inlined) for
DOM is just part of the main document. So IMPORT/EXPORT only makes sense
for DOM if inlined content can somehow be kept separate.


> 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.
>

 I think this line of thought means there is no real need for IMPORT/EXPORT
in DOM ?


> 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.
>
>
Yes, I think that should be possible (although perhaps such separation is
not very elegant). In addition, with X3D nodes being DOM nodes, X3D nodes
can be also controlled, eg. receive events, from outside the X3D
scenegraph, via SAI. So there is overlap of control by routes and x3d
scripts, and control by DOM javascript. Perhaps even competition.


> 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).
>
>
ShadowDOM may be the only way to implement strict X3D Inline in a HTML
browser as a subtree. However, I am not sure if X3D Inline would be an
intended use of ShadowDOM. Since ShadowDOM was not available when x3dom was
developed, x3dom just appends the Inline's nodes to the main X3D scene.
Also, I am not sure if ShadowDOM is intended to completely prevent access
to the added subtree.

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.
>
>
Keep in mind there is also the need to define the interfaces between these
parts 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
>

I think this is what Don suggests.


> > 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.
>

Agreed, that the developer expectation probably would be that Inlined
content would be accessible (and I tried to do that for cobweb-dom). On the
other hand, a web compatible inline would be probably defined or
implemented outside of X3D anyways, in addition to the x3d inline. For
example, the webcomponents import functionality (
https://www.webcomponents.org/introduction#html-imports) or html5 template (
https://www.w3.org/TR/html5/scripting-1.html#the-template-element) comes to
mind.

Here is a (thought) experiment with x3dom and import:

1) Use import to import a x3dom inline document.
2) write a short script to get the imported scene, clone it, and insert it
somewhere into a x3dom main scene, perhaps as a group.
3) see if it works.
4) bonus: write a short custom element 'x3dimport' which does 2)
5) bonus: add an attribute which identifies which import to clone and
insert.

A web developer would probably try something like this to get inline
capability.

>
> > (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.
>

With the DOM .querySelector method it is possible to uniquely refer to any
node in a DOM since paths and parent child relationships can be used. This
makes separate namescopes less of an issue for DOM purposes.

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170716/24bb6504/attachment.html>