[x3d-public] [x3dom-users] inline access from dom -- Inline Trees, Reuse, and Access

[doug sanden]

> A simple consideration is that the prototype declaration must 
> be in the same parent context as each instance.
Or ancestor context? Authoring tool white_dune and freewrl search up the ancestor contexts till a matching declare is found. One idea is to load libraries of common protos one level higher than scene.

 
From: x3d-public [x3d-public-bounces at web3d.org] on behalf of Joe D Williams [joedwil at earthlink.net]
Sent: October 13, 2016 4:29 PM
To: X3D Graphics public mailing list; x3dom mlist; Leonard Daly
Subject: Re: [x3d-public] [x3dom-users] inline access from dom -- Inline Trees, Reuse, and Access

> The details of how to access the internals ...

in a way, this deep sensing and manipulation pf elements in a highly
structured and connected scenegraph is solved directly in X3D by use
of the 'execution context' concept. A context is the set of nodes and
fields to which the SAI gets current direct access. For the SAI it is
called the SAIexecutioncontext. There is a parent context and zero of
more child contexts. A child context may be the parent of a child
context, and so on.

There are very concise rules that define how events can be shared
between one context and another. A parent context knows the name for
each child context. When you are navigating a context, you only know
about interfaces exposed in the current containing parent context
including interfaces exposed by included child context(s).

http://www.web3d.org/documents/specifications/19775-2/V3.3/index.html

http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/concepts.html#ExecutionContext

"An execution context is the run-time semantic equivalent to a name
scope described in 4.4.7 Run-time name scope in ISO/IEC 19775-1. "

http://www.web3d.org/documents/specifications/19775-2/V3.3/index.html

http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#Runtimenamescope

"Each X3D browser defines a run-time name scope that contains all of
the root nodes currently contained by the scene graph and all of the
descendant nodes of the root nodes, with the exception of nodes hidden
inside another name scope. Prototypes establish a name scope and
therefore nodes inside prototype instances are hidden from the parent
name scope.
Each Inline node or prototype instance also defines a run-time name
scope, consisting of all of the root nodes of the file referred to by
the inline node or all of the root nodes of the prototype definition,
restricted as above. Other nodes or extension mechanism may be
introduced which specify their own name scope."

Wonderfull. So I think I would like to add X3D Script node to that
list because "this" is its name scope and except for its declared
interfaces it does not need to know anything about what is going on
outside.

I would also like to add any concrete node to that list because, in
the same sense as a prototype instance is a child context, any node is
actually a unique child execution context.

Consideration of DEFed and USEd nodes is slightly different, We will
see that the DEF node is a unique child execution context. All USE
instances are always in the same parent execution context, and
actually operates as if each USE instance is the same child execution
context as the DEF instance. You can't change one without changing the
others.

For X3D, each prototype declaration, each Inline, each proptotype
instance, and by my inclusion each Script, all are like any any other
X3D node. Inline is a great start for thinking about this is because
in any authoring tool you want to be able to support the simple act of
just dropping a complex something into the scene directly without
breaking anything. No matter how complicated it is inside, the thing
you are dropping acts just like any other content node.

This is very convient because by default each Inline has no available
interfaces to the parent context and the parent context does not
recognize any of the 'internal' Inline node operations. Except, that
is, for IMPORT and EXPORT which can be used to declare available
parent and child context interfaces.

Likewise for prototypes, where the allowed interfaces must be
consistently defined in both the parent context and in the child
context. A simple consideration is that the prototype declaration must
be in the same parent context as each instance.

It turns out that all this makes it very convenient using X3D runtime
events and routes. Events to and from the child context are available
by direct declaration right there in the user code. So, with IMPORT
and EXPORT, an inline can operate just like a prototype, which means
just like any other concrete node. Even for an X3D Script node where
the interfaces are also fully described, it only knows about its
parent context and the parent context only can know about the declared
child context intefaces. The actual internal workngs of the child node
context are of no concern to the parent context.

So OK then, that is some of the undercover workings of the X3D SAI.
These are the parts you don't really need to worry very much about
because it works. <route from=gozouta to=gozinta> If you don't have
enough of those you just make more nodes and routes. Of course it is
easy to see that source and destination nodes for routes must be in
the same execution context. It just works for a conforming
implementation, of which there are many.

When you are scripting the scenegraph using an 'internal' script node
it is obvious that the script only has access to nodes in the current
context. Inlines are by design shielded from interaction with the
parent context. Prototype instances have only defined interfaces. For
sure, it is easy to see that a parent context does not have direct
access to any internal nodes of any instance of an inline or a
prototype except those interfaces that are declared.

http://www.hypermultimedia.com/x3d/Quick/SAIABSDEFS.htm

is an old (even the spec link has changed) cut at my understanding the
SAI in terms of a memory aid.

It seems like the general form is this:

 SAIExecutionContext.SAINode.SAIField.SAIFieldValue;  The main
containing scene, each proto instance,
  and each inline instance is a distinct and independent
  execution context in the current scene graph. So for X3D SAI it
seems that in order to gain access to any field value in the scene all
you must do is navigate to the correct parent context, then know the
name of the child context you wish to interact with. In principle this
should give scripting access to any field of any child context without
concern for a duplicate name in a different child context.

... more to come ...

Joe



  ----- Original Message -----

From: "Leonard Daly" <web3d at realism.com>
To: "X3D Graphics public mailing list" <x3d-public at web3d.org>; "x3dom
mlist" <x3dom-users at lists.sourceforge.net>
Sent: Tuesday, October 11, 2016 3:53 PM
Subject: Re: [x3dom-users] inline access from dom -- Inline Trees,
Reuse,and Access


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


--------------------------------------------------------------------------------


> ------------------------------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>


_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org