[x3d-public] inline access from dom -- Inline Trees, Reuse, and Access
Leonard Daly
web3d at realism.com
Tue Oct 11 15:53:34 PDT 2016
Part 2 -- skipping all of the material covered in the previous email...
This part addresses Inlines calling Inlines calling ..., multiple uses
of content, perhaps from different locations, and how to access all of
them...
Well I was going to write that, but I have been doing a lot of thinking
about the proper structure and role of X3D. I think once that is defined
a lot more will flow into place.
Inline (and related - some not yet defined) nodes are really important.
They allow a developer to build a scene in pieces (or multiple
developers to work on a scene). I cannot foresee a situation where
something like that does not exist.
The details of how to access the internals may change depending on how
the data is loaded (potentially the data format) and the kind of
protection that might be needed. For example a model may represent a
part that should not be modified (because of licensing, etc.). The X3D
library may need to enforce (to an extent) that restriction by not
exposing that model to the DOM and user modification. Note that I am not
arguing for absolute protection or DRM mechanisms.
Leonard Daly
>
>
> 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.
As was discussed in the previous email, the double prefix convention is
probably not used. Even if it was, names could easier get carried away
so not to be much use. Some of my statements below get more into best
development practices rather than strictly specification or implementations.
Traditional X3D development creates very deep node trees as the
developer tries to reuse as much as possible. This does reduce the
memory footprint at the expense of added complexity in the scene.
>
> 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
> <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
>> <mailto: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
>>> <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 list
>>> X3dom-users at lists.sourceforge.net
>>> <mailto:X3dom-users at lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>> <https://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
-- *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/20161011/a71bc003/attachment-0001.html>
More information about the x3d-public
mailing list