[x3d-public] IMPORT/EXPORT Use
Leonard Daly
Leonard.Daly at realism.com
Sun Jul 16 20:32:59 PDT 2017
There seems to be some confusion in the responses from Don and John.
First I am only discussion Inline and IMPORT/EXPORT. While the
discussion and results may provide useful with PROTOs / EXTERNPROTOs,
these are not part of the discussion; neither are Events.
To help clarify things I have started a blog post series on topics
causing integration problems of X3D into DOM.
List of issues: http://realism.com/blog/integrating-x3d-dom-issues
Description of Inline issue and possible solution:
http://realism.com/blog/integrating-x3d-dom-inline
Ramification of above possible solution:
http://realism.com/blog/integrating-x3d-dom-unique-values
Since not everyone would jump to a URL, I'll summarize my findings here.
There are not that many issues, some small (case of names), some quite
large (scripts & events). At this time to my knowledge, only six
conflicts have been identified between HTML and X3D. The other two posts
are only looking at Inline and parts by extension, other external X3D files.
I believe that I have identified a solution to the namescope issue for
X3D functionality. This is presented and discussed in the second link.
The third link discusses a ramification of that solution pertaining to
ID values.
The import take-away in the solution is that it provides a means for X3D
applications (the code that displays X3D content) to maintain separate
namescopes (at least for Inline) for X3D functionality AND preserve DOM
structure for HTML functionality. At this early stage, this appears to
work for everything except the 'id' attribute. The 'id' attribute (or
field) is not defined in 19775-1, only the XML encoding (4.3.4 --
http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax).
I will address the other issues at a future time.
I am using Andrea's message to respond because I think it is the most
recent.
>
> 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.
To answer Don's questions about understanding...
It is possible to Inline the same file multiple times. If each file is
loaded into the parent's namescope than any DEF names will not be
unique. DOM has a single namescope.
> 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 ?
These topics are complex enough. You (Don) are adding so many other
topics to the conversation that there is almost no hope of understanding
and resolution. Even though X3D event routing is one of the primary
reasons for having DEF names, including events into this part of the
conversation brings up a large number of issues with the difference
between X3D events and DOM events. It is very important to keep those
separate right now.
I don't think there is a clear understanding of shadow-DOM. The W3C
working draft (2017-02-03) is at https://www.w3.org/TR/shadow-dom/.
A shadow-DOM is a document object model (structure) that participates in
rendering, but is not part of the primary DOM. It must be attached to an
existing element with the .attachShadow method. It allows elements to be
rendered without their styling "leaking" into the rest of the page.
Putting things in the Shadow DOM does not mean they are inaccessible
from the regular DOM.
Shadow-DOM is not some sort of magical hidden DOM that provides complete
separation of regular DOM from special stuff. I am sure that new and
imaginative ways of using it will come about, but that is difficult to
do right now when the spec is still being developed.
>
>
> 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 is the trailer to my solution in the posts listed at the top of
this message.
> 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?
>
I did. It's in the posts. I've described this issue before, but I think
this is the first time I collected pieces on one fairly narrow topic and
included a potential solution for most of the problem.
>
> 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/FutureOfX3D.pdf>
> http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3dWeb3d2017June7.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
> <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.
X3DOM uses the namespacename attribute to determine what to do with an
Inline. If it is blank, then the X3D nodes are not put into the DOM and
only appear in the scene graph. If it is defined, the DEF and ID
(depending on other attributes) are modified and the nodes are entered
into the DOM with the modified values. Note that there are still issues
if an Inlined file Inlines a second file. If the first file is Inlined
more than once and supplies a value for namespacename, then there will
still be name conflicts.
X3DOM does not use Shadow DOM.
My issue with IMPORT/EXPORT is for the case where there is a single
namescope. What is the use/value of such statements when all they can do
is alias names, since everything is imported/exported anyway.
>
> 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.
>
I am very explicitly not mixing X3D events and DOM events. That is
another topic.
>
>
> 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.
Web Components are (or will be) part of the browser, though there are
poly-fill libraries for these right now. Simple intro to Web Components
-- https://developer.mozilla.org/en-US/docs/Web/Web_Components
>
> 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.
I presume that (1) is 'Use Inline..."
The contents of external X3D files can be stored as elements, not in the
DOM (but in variables stored in the DOM). Since it is not in the DOM, it
would not need to be cloned.
Are you talking about something like:
var externalX3d = readExternal (externalUrl);
var copyOfExternalX3d = deepClone (externalX3D);
var ele = document.getElementById('AppropriateX3dNodeElementId');
ele.addChildren (copyOfExternalX3d);
// (4): package up the above to meet the requirements
// Not sure what you mean by (5)
>
> 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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
--
*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/20170716/712080ee/attachment-0001.html>
More information about the x3d-public
mailing list