[x3d-public] inline access from dom -- Export/Import & X3DOM

[Leonard Daly]

Andreas,

There is a lot in this email. You have raised many good questions and 
I'm still digesting all of it. I'll going to split it into pieces so I 
can more easily address the parts and to make it easier (I hope) for 
others to follow.


> Hi Leonard,
>
> thank you for this excellent summary of the inline situation in X3D 
> and x3dom, and the implications in terms of DOM integration which 
> provides an good basis for a discussion.
>
>
>     Some background first. Not that you need this, but others
>     following the discussion might. The X3D Standard
>     (http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Inline
>     <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Inline>)
>     indicates that all nodes loaded via an Inline occupy a separate
>     namescope (sort-of like a name-space, but without a lot of the
>     structure) from the parent scene. This prevents direct
>     communication between the parent and the children of an Inline.
>     The Import/Export statements allow certain information to be
>     passed between the parent/child. The namescope applies only to
>     information passing. Rendering is all rolled-up.
>
>
> I think it is useful to think about the motivation for requiring a 
> separate namescope and the default of no direct communication between 
> the scene and inline content. One big reason must be that an author 
> should not need to worry about DEF naming collisions when using an 
> inline. But is there a fundamental reason to not EXPORT all inlined 
> nodes by default, eg. allow IMPORTing them ? The IMPORT statement 
> still enforces the definition of a unique name for the imported node.

To my knowledge, there is no technical reason; however, good coding 
practice has been to "hide" internal structures, data, and 
routines/methods from the caller. This is a little different from code 
because the logic structure is not available. I think this may be more 
of the case where auto-EXPORTING everything requires a good reason, 
rather than assuming it should be done.


>     X3DOM implements this requirement with the following. If only the
>     X3D-defined fields are used, then the Inlined nodes are not loaded
>     into the (HTML) DOM. They are maintained in the list of rendered
>     nodes so content can be visible. Since they are not in the DOM,
>     those nodes cannot be accessed with DOM-oriented calls (e.g.,
>     jQuery). At this time X3DOM does not support Import/Export.
>
>
> Yes. There is a slight complication I believe. When x3dom uses 
> xmlhttprequest to load an inline file, I think the xml file gets 
> loaded into a separate dom tree which is then parsed to produce x3dom 
> nodes for the x3d scene graph which are in turn rendered. So I believe 
> the inline does have its dom nodes, they are just not part of the main 
> dom.

Yes, XHR does load it into a dom (not the page DOM) for further 
processing. After processing that dom is deleted (technically made 
available for garbage collection).



>     If the X3DOM field 'namespacename' is present and a value is
>     provided, the value appended with a double underscore is prepended
>     to all DEFs. If the field 'mapdeftoid' is TRUE, then the
>     prepending is also done to IDs (it's actually a little more
>     complicated than that, but this will do for now). The Inlined
>     nodes are still maintained in a separate X3-DOM namescope. This is
>     necessary because Inline's 'url' field can change and those nodes
>     would need to be removed. The separate namescope allows those
>     nodes to be identified.
>
>
> Just to give an example:
> <Inline url='arrow.x3d' namespacename='arrow1' />
> arrow.x3d:
> .. <Material DEF='headcolor' .. /> ..
>
> external x3dom access: 
> document.getElementById('arrow1__headcolor').setAttribute('diffuseColor','1 
> 0 0')
>
> How would nodes in inlines within inlines be identified ? Double 
> prefixes ? Imagine an inline of an bow with arrow: 
> bow1__arrow1__headcolor ?

I have not tried this, so this is based on my understanding of the code 
(which I know to not be complete). I don't think the parser for Inline 
expands any namespacename values so names would not be double prefixed.



>
>
>     [Switching back to regular HTML] Elements added to an HTML
>     document through the DOM become full elements in the page's DOM.
>     There is no separate namescope. It is the responsibility of the
>     adding code to ensure that there are no 'id' value conflicts (ids
>     are unique throughout the document).
>
>
> Yes, ids are the responsibility of the author or dom manipulation 
> code. However, using .querySelector and CSS selector it is often 
> possible to have a selector specific enough to identify a unique 
> element without using an id attribute.
>
>     This is similar to X3D in that DEF names need to be unique
>     throughout the namescope. This slight variant allows the author to
>     use an Inline multiple times because each instance is in its own
>     namescope.
>
>
>  In fact, document.querySelector([DEF='uniqueName']) allows uniquely 
> identifying a x3d node in a DOM environment without having to 
> introduce id attributes at all.

Yes. There are many ways to get to a unique element. For example, the 
page may only have one <h1> element or a single instance of <x3d>. It is 
not always necessary to use IDs. Which is used depends on the context of 
doing the search and the information the developer has available.

The remainder will be in another email.


-- 
*Leonard Daly*
3D Systems Architect & Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161005/4261b8c3/attachment-0001.html>