[x3d-public] [x3dom-users] inline access from dom

[Andreas Plesch]

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


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


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


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

multiple instances of inlines:

<Inline DEF='a1' namespacename='arrow1' url='arrow.x3d' />
<Inline DEF='a2' namespacename='arrow2' url='arrow.x3d' />

This only would make sense if there is a plan to modify each arrow
individually (otherwise, the second arrow would be a USE instance).
document.getElementById('arrow1__headcolor').setAttribute('diffuseColor','1
0 0')
document.getElementById('arrow2__headcolor').setAttribute('diffuseColor','0
1 0')

There is an equivalent EXPORT/IMPORT path for SAI access.

The cobweb dom bridge allows similarly:

document.querySelector('Inline[DEF="a1"]
Material[DEF="headcolor"]').setAttribute('diffuseColor','1 0 0')
or shorter since the DEFs are unique within their subtrees:
document.querySelector('[DEF="a1"]
[DEF="headcolor"]').setAttribute('diffuseColor','1 0 0')
document.querySelector('[DEF="a2"]
[DEF="headcolor"]').setAttribute('diffuseColor','0 1 0')

As  you can see this looks quite similar to  namespacename prefixes but
does not require the additional field, and instead just can use the DEF
field. This kind of brings up the question why x3dom does not simply use
the DEF name as namescope prefix ? Is there a case where you would want to
use different DEF names but the same namespacename ?

<Inline DEF='a1' namespacename='arrow1' url='arrow.x3d' />
<Inline DEF='a2' namespacename='arrow1' url='arrow.x3d' />

I cannot see immediately how this could be of use ?

A 3D environment in a web page should be able to Inline the same file
> multiple times (e.g., a row of trees) without causing a problem with the
> DOM. It should also be possible to group and individually animate those
> objects. For example, a number of trees of the same kind would all sway in
> the wind. Trees of the same height would behave similarly. One tree might
> be special and need to sway differently. It should be possible to apply an
> animation to the entire class of trees and a special animation to the
> special tree. If all of the trees had the same class, then (at least
> theoretically) the animation could be applied to the class. The special
> tree would have a unique ID so that could be animated separately.
>

There is class attribute for HTML elements for convenient selection of all
elements belonging to the same class. I tend to think it is more of a
convenience feature.

Let's think through the scenarios:

1) multiple instances: DEF/USE for cloning, multiple DEFs with the same url
for individual instances
2) swaying trees: DEF='swayingTree' / USE ; animate swayingTree internally
3) swaying trees, but each a bit differently: more of a case for
prototypes, could include script for sway behaviour depending on height
4) special tree: DEF='special Tree', access and animate specially


> What Andreas has written below is an element-attribute-value selector that
> goes down to the final leaf to set a value. If the Inline's parent (the
> file that contains the node <Inline url='InlineParent.x3d'>) uses this node
> multiple times, then Andreas' querySelector statement would change all of
> the arrowheads that fit the criteria. This is not necessarily bad, but just
> needs to be considered.
>

.querySelector always only selects a single element. If they are multiple
elements which fit the selector, the 'best' fit is chosen or all things
being equal the first one. .querySelectorAll gives you all the fitting
elements.

I think it is true to say that it is always possible to construct a path
from an Inline node down to the targeted node inside which is unique. DEFs
inside the inline need to be unique within their scene and DEFs in the
parent also need to be unique. So it is always possible to construct
[DEF='parentName'] [DEF='nodeName'] or in prefix notation
parentName__nodeName .

Anything not starting with an ID reference or a unique tag in the scene
> (e.g., <body>) may not refer to a unique node.
>
=== InlineParent.x3d ===
>     :
> <Inline DEF='arrow' url='arrow.x3d'></Inline>
>     :
>
>
> === arrow.x3d ===
>     :
>     :
> <Appearance>
>     <Material DEF='arrowheadmat' diffuseColor='0 0 1'></Material>
>         :
> </Appearance>
>
>
>
> So I think rather than ask what would it take to adopt the selector
> approach, a more fundamental question needs to be answered - how should
> files be imported into a scene and inserted into the (HTML) DOM? I think
> once that question is answered the rest will be easy.
>

This is certainly a good question to ask. I thought about not exposing
Inlined content at all for DOM access for cobweb, and instead rely on html
templating or the newish HTML Imports functionality which deals with
similar issues. With HTML Imports an HTML file is imported as a separate
DOM first and then can be cloned and appended into the main document. It
feel like this could replace a lot of the Inline functionality. I should
put together an example page using HTML Imports (which is rejected by
Mozilla).

The question how files should be imported also implies if there should be a
change in how EXPORT/IMPORT works now for X3D/SAI ? Both x3dom and
cobweb_dom implicitly export all nodes in an inline. Should EXPORT/IMPORT
be streamlined similarly ?


> I created a new public Wiki page on Web3D.org (http://www.web3d.org/wiki/
> index.php/Importing_and_adding_nodes_in_HTML) where results of this
> discussion are recorded.
>
>
> Leonard Daly
>
>
>
> Hi Leonard,
>
> I guess I am looking for guidance and a discussion on how ideally content
> internal to Inlines should be identified. I do like the CSS selector
> approach because if does not involve adding an additional namespacename
> field to Inline. But there may be other approaches.
>
> What would it take to adopt the selector approach in x3dom ? So you can do
> this:
>
> SceneElement.querySelector("Inline[DEF='arrow']
> Material[DEF='arrowheadmat']).setAttribute("diffuseColor","1 0 0")
>
> -Andreas
>
> On Sat, Oct 1, 2016 at 11:54 PM, Leonard Daly <web3d at realism.com> wrote:
>
>> Andreas,
>>
>> I am not sure if you are looking for comments, advice, discussion, or
>> just posting a notice. I don't want to go off on a tangent here. I am
>> rather familiar with how and almost why X3DOM does it.
>>
>>
>> Leonard Daly
>>
>>
>> I am working on adding DOM access to inline scenes for my Cobweb DOM
>> bridge:
>>
>> https://andreasplesch.github.io/cobweb_dom/tests/inline_in_inline.xhtml
>>
>> The idea is to add the external inline scene DOMs to the main scene DOM
>> as children of the Inline elements. Once added, the mutation observer picks
>> up modifications of these children and does not need to do anything other
>> than it already does for the main scene.
>>
>> It works well although I do not know how web browsers deal with large
>> combined DOMs. Also, a small addition to Cobweb.js is currently needed.
>>
>> One effect is that one can use CSS selectors with querySelector to drill
>> down to specific elements in inline scenes, even through hierarchies of
>> inlined inlines. See example. This way the DEF names can be used even if
>> they are identical across scenes. X3D semantics and functioning is not
>> affected.
>>
>> X3dom uses a different approach of prefixes to id/DEF attributes to
>> enable access to elements in inlines. Not sure if x3dom could use instead
>> or in addition Selectors ? This would require adding the Inline DOMs to the
>> main DOM but perhaps this is already almost done ?
>>
>> So I am considering also adding the same option of a namespacename prefix
>> to element IDs but the effort would be really for compatibility. Thinking
>> about it, while possible probably not a priority unless there is a
>> compelling use case.
>>
>> X3D has EXPORT/IMPORT to deal with accessing nodes in inlines. I think
>> the SAI equivalent is roughly that all nodes are EXPORTed by default and
>> that in addition to a DEF name it becomes possible to address a node by its
>> path in the scene hierarchy. Perhaps something to consider for the
>> standard: X3D selectors.
>>
>> Andreas
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>
>> _______________________________________________
>> X3dom-users mailing listX3dom-users at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/x3dom-users
>>
>> -- *Leonard Daly* 3D Systems Architect & Cloud Consultant President,
>> Daly Realism - *Creating the Future*
>>
> --
> Andreas Plesch 39 Barbara Rd. Waltham, MA 02453
>
> -- *Leonard Daly* 3D Systems Architect & Cloud Consultant President, Daly
> Realism - *Creating the Future*
>



-- 
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/20161002/27dd7c9e/attachment-0001.html>