[x3d-public] IMPORT/EXPORT Use (Leonard Daly)

[Andreas Plesch]

On Sun, Jul 16, 2017 at 11:33 PM, <x3d-public-request at web3d.org> wrote:

> Date: Sun, 16 Jul 2017 20:32:59 -0700
> From: Leonard Daly <Leonard.Daly at realism.com>
> To: x3d-public at web3d.org
>

...

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

Let's say a strict X3D interpreter would keep the inline only in the
internal parallel X3D scenegraph, and not in the DOM.

Hm, even in that case it would be possible to access the Inline content
from javascript.


>
> >
> >
> > Keep in mind there is also the need to define the interfaces between
> > these parts of the DOM tree.
>

I believe this is the difficult part.


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

It would be use inline without using the Inline X3D node.


>
> 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);
>
>
Yes, in effect but using imports.

<link rel="import" href="myInline.html">
var externalX3D = document.querySelector("link
[rel='import'][href='myInline.html']");// or so
var copyOfExternalX3d = externalX3D.clone(true);
var ele = document.getElementById('AppropriateX3dNodeElementId');
ele.addChildren (copyOfExternalX3d);

Cloning is only necessary in case the same import needs to be used
multiple times.

// (4): package up the above to meet the requirements
>

4) would be <my-Inline />


> // Not sure what you mean by (5)
>

5) would be <x3d-Inline src='myInline.html' />
and using the src attribute in the querySelector.

Andreas

-- 
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/20170717/695149c1/attachment-0001.html>