<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="m_-6107552470267862612quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Date: Mon, 19 Jun 2017 14:26:38 -0700<br>
From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a>><br>
To: <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
Subject: Re: [x3d-public] Inconsistencies in Requirement<br>
Message-ID: <<a href="mailto:5bfc474e-db40-1f1e-2e44-06a6f79ff6ed@realism.com" target="_blank">5bfc474e-db40-1f1e-2e44-06a6f<wbr>79ff6ed@realism.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Andreas,<br>
<br>
Interesting points. I've added information I know (or found) embedded in<br>
your comments.<br>
<br>
><br>
> I read the message below yesterday and I don't see how it answers the<br>
> issue of USE statements. Perhaps it is my lack of understanding of<br>
> something here. Can it the answer please be restated. To help things<br>
> along I am summarizing my points.<br>
><br>
> 1) The X3D specification requires nodes to have more than one<br>
> parent in<br>
> the case of DEF/USE<br>
><br>
><br>
> 2) For V4, there are statements that all X3D nodes will be in the DOM.<br>
><br>
><br>
> I saw also a statement that there could be a parallel tree approach,<br>
> such as x3dom and cobweb_dom employ.<br>
> It may be also instructive to determine how x3dom currently deals with<br>
> DEF/USE. My recollection is that DOM elements with a USE attribute<br>
> have just one parent (they have to) but are mapped to x3dom nodes (in<br>
> javascript memory) which have the DEF parent (through a map).<br>
<br>
I have looked through the code and have not yet been able to find the<br>
specific lines that deal with 'USE'. X3DOM does deal with 'USE' as can<br>
be seen in the example at<br>
<a href="https://examples.x3dom.org/example/x3dom_defUse.xhtml" rel="noreferrer" target="_blank">https://examples.x3dom.org/exa<wbr>mple/x3dom_defUse.xhtml</a>. View-source shows<br>
that it is used in the second 'Shape'. I suspect that the second 'Shape'<br>
is removed from the DOM but kept in the scene graph.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">The second shape is still in the DOM. But I am not sure what happens if its USE attribute is modified.</div><div dir="auto"><br></div><div dir="auto"><a href="https://github.com/x3dom/x3dom/search?utf8=%E2%9C%93&q=defmap&type=" target="_blank">https://github.com/x3dom/<wbr>x3dom/search?utf8=✓&q=defmap&<wbr>type=</a><br></div><div dir="auto"><br></div><div dir="auto">shows how DEF is implemented.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6107552470267862612quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This particular method breaks (2 - not all X3D nodes are in the DOM). I<br>
believe Andreas describes Cobweb as doing essentially the same thing.<br>
<br>
<br>
><br>
> cobweb_dom is initally loading nodes including USE nodes with the SAI<br>
> importDocument(DomNode) function<br>
> (<a href="http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FunctionsBrowserObject" rel="noreferrer" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19777-1/V3.3/<wbr>Part1/functions.html#t-<wbr>FunctionsBrowserObject</a>)<br>
> . USE nodes added later to the DOM are parsed into the x3d graph using<br>
> cobwebs parser which I think takes care of parenting to the x3d DEF node.<br>
><br>
> A-frame has an assets systems which allows reuse of components in<br>
> multiple entities. I suspect A-frame avoids copying and would<br>
> reference the same asset multiple times. This is possible because<br>
> A-frame also has a parallel scene graph (the THREE graph) which exists<br>
> in memory apart from the DOM.<br>
<br>
I have looked at the asset system in A-Frame, but not in sufficient<br>
depth to determine whether<br>
1) It uses the data as a single copy inserted into the DOM in the asset<br>
statement with the uses not appearing in the DOM<br>
2) It copies the information from the asset definition to the node that<br>
uses it<br>
3) It uses the asset-defined information by reference<br>
<br>
If the asset system does not expand nodes in the DOM when it is used,<br>
then it could very easily work like CSS by supplying a common definition<br>
that other nodes just refer to (#3 above).<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6107552470267862612quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> Another angle is the shadow DOM but I am not sure if that applies<br>
> since I suspect that it also does not allow multiple parents.<br>
<br>
Shadow DOM is (sort-of) like regular DOM. You are right about not<br>
allowing multiple parents. It allows you to expose elements to the<br>
(page) renderer without them being directly visible in the DOM. Since<br>
the scene graph is roughly parallel to the DOM, adding another DOM seems<br>
to me to be increasing the complexity without necessarily solving the<br>
problem.<br>
<br>
Even though it is 6 years old, this article provides a good basic<br>
description of Shadow DOM -<br>
<a href="https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/" rel="noreferrer" target="_blank">https://glazkov.com/2011/01/14<wbr>/what-the-heck-is-shadow-dom/</a><br>
<br>
><br>
> I think SVG has DEF/USE as well. SVG then must define some exceptions (?).<br>
<br>
Not being an SVG expert, I had to look this up. I found this Stack<br>
Overflow questions:<br>
<a href="https://stackoverflow.com/questions/19246232/svg-reuse-a-line-node-with-def-and-use" rel="noreferrer" target="_blank">https://stackoverflow.com/ques<wbr>tions/19246232/svg-reuse-a-<wbr>line-node-with-def-and-use</a><br>
<br>
It describes that the 'use' attribute does a deep clone and inserted<br>
into the generated tree. Unfortunately, the answer did not provide a<br>
reference, but it does look like it is quoting something important.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">The svg spec. needs a lot of language to deal with def/use:</div><div dir="auto"><br></div><div dir="auto"><a href="https://www.w3.org/TR/SVG/struct.html#Head">https://www.w3.org/TR/SVG/struct.html#Head</a><br></div><div dir="auto"><br></div><div dir="auto"><a href="https://www.w3.org/TR/SVG/struct.html#UseElement">https://www.w3.org/TR/SVG/struct.html#UseElement</a><br></div><div dir="auto"><br></div><div dir="auto">An excerpt:</div><div dir="auto">"</div><div dir="auto"><span style="font-family:sans-serif;font-size:medium;background-color:rgb(255,255,255)">T</span>he effect of a <a href="https://www.w3.org/TR/SVG/struct.html#UseElement" style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">‘use’</a> element is as if the contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the <a href="https://www.w3.org/TR/SVG/struct.html#UseElement" style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">‘use’</a> element as its parent and all of the <a href="https://www.w3.org/TR/SVG/struct.html#UseElement" style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">‘use’</a> element's ancestors as its higher-level ancestors. Because the cloned DOM tree is non-exposed, the SVG Document Object Model (DOM) only contains the <a href="https://www.w3.org/TR/SVG/struct.html#UseElement" style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">‘use’</a> element and its attributes. The SVG DOM does not show the referenced element's contents as children of <a href="https://www.w3.org/TR/SVG/struct.html#UseElement" style="background-image:initial;background-position:initial;background-size:initial;background-repeat:initial;background-origin:initial;background-clip:initial">‘use’</a> element<font face="sans-serif" size="3"><span style="background-color:rgb(255,255,255)">.</span></font></div><div dir="auto"><font face="sans-serif" size="3"><span style="background-color:rgb(255,255,255)">"</span></font></div><div dir="auto"><font face="sans-serif" size="3"><span style="background-color:rgb(255,255,255)"><br></span></font></div><div dir="auto">Mostly use seems understood as referencing def but the actual representation then needs to be a deep and unexposed copy.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6107552470267862612quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><br><br>
<br>
><br>
> Overall, it looks like it may be necessary to rely on more than the<br>
> DOM alone for DEF/USE functionality.<br>
<br>
Offering another possibility. Unreal (and I think Unity) create a class<br>
for each object. If something is "copied", then it is sub-classed from<br>
the original class. Changes to the parent propagate to all subclasses;<br>
however, a sub-class can override any property (which would then<br>
propagate to sub-sub-classes). I think that means in "X3D"-speak, the<br>
"DEF" node defines the master class. Any node that "USE"s it would<br>
create a subclass. A USE node could also redefine fields for that<br>
subclass, and even make itself available for subclassing by using a DEF<br>
statement. This would look something like:<br>
<br>
<Transform DEF='Master' translation='1 2 3' rotation='0 1 0 0' scale='1<br>
1 1'>...</Transform><br>
<br>
<Transform USE='Master'>...</Transform> <!-- strict subclass of Master --><br>
<Transform USE='Master' DEF='Alpha' rotation='1 0 0<br>
1.57'>...</Transform> <!-- subclass of Master with a change of rotation --><br>
<Transform USE='Master' DEF='Beta' rotation='0 0 1<br>
1.57'>...</Transform> <!-- different subclass of Master with a change<br>
of rotation --><br>
<Transform USE='alpha' scale='2 2 2'>...</Transform> <!-- subclass of<br>
Alpha with a change of scale --><br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Svg also allows reusing a modified use for subclassing, judging from the spec. . I have never tried this.</div><div dir="auto"><br></div><div dir="auto">Could be cool. There may be a chance to make this a backwards compatible addition to x3d ?</div><div dir="auto"><br></div><div dir="auto">Trying to come up with a practical use case. Cars. Blue Cars. Blue cars with lights on.</div><div dir="auto"><br></div><div dir="auto">Andreas</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_-6107552470267862612quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
<br>
><br>
> some thoughts, Andreas<br>
><br>
> 3) For V4, there are statements that it will be backward<br>
> compatible (as<br>
> much as possible)<br>
> 4) The DOM specification prohibits nodes with more than one parent.<br>
><br>
> It is not possible for Web3D Consortium to change the DOM<br>
> specification<br>
> (though it is possible to petition for a change). It is possible to<br>
> change the X3D specification (1). It is also possible to relax the<br>
> statements in (2) and (3).<br>
><br>
> There are inconsistent requirements if DEF/USE means a reference<br>
> to the<br>
> DEF node and all nodes are in the DOM.<br>
> There are consistent requirements if DEF/USE means a copy of the node<br>
> tree originating at the DEF node (drop #1&3)<br>
> There are consistent requirements if not all X3D nodes are in the DOM<br>
> (drop #2)<br>
><br>
> I would be interested in hearing anyone else's ideas on how the<br>
> inconsistencies in existing statements and specifications can be<br>
> resolved.<br>
><br>
> Leonard Daly<br>
><br>
><br>
> P.S. regarding 'class' and USE. Going strictly by the X3D<br>
> specifications, it makes no sense to allow 'class' in a node as<br>
> the USE<br>
> attribute indicates that what appears in this position in the scene<br>
> graph is a reference to a node defined elsewhere. There is no<br>
> provision<br>
> for this DEF node to be anything other than a reference.<br>
><br>
><br>
><br>
> > Primary is getting to clarity on best possible USE definition<br>
> for X3D<br>
> > per se. We discussed Thursday on spec teleconference.<br>
> ><br>
> > It would seem that allowing different 'class' attributes on USE<br>
> in the<br>
> > XML Encoding is over-generous and should be tightened to not be<br>
> > allowed. We were able to come up with examples that showed diverse<br>
> > class+USE is problematic (e.g. cannot style a Material node to be a<br>
> > class='somethingBlue' while styling a USE version of the same<br>
> node to<br>
> > be class='somethingRed').<br>
> ><br>
> > Next will be considering if 'class' attribute can be advanced to<br>
> > abstract spec and hence all encodings; currently it is only<br>
> > reserved/defined in XML Encoding.<br>
> ><br>
> > Regarding DOM tree and X3D tree, they do not have to be<br>
> considered as<br>
> > necessarily identical all of the time. If event models are<br>
> decoupled<br>
> > and handing off in tandem, then synchronization would occur<br>
> after each<br>
> > respective update. There are different ways for implementations to<br>
> > accomplish this - all worth considering, with HTML5/DOM<br>
> > Recommendations being authoritative regarding functionality.<br>
> ><br>
> > So, step by step. If we can define semantics that work<br>
> > consistently/coherently, and can be implemented, we then refine<br>
> > iteratively for use in each X3D encoding.<br>
> ><br>
> ><br>
> ><br>
> > On 6/15/2017 10:58 AM, Leonard Daly wrote:<br>
> >> The original purpose (and still used in this manner) of the 'USE'<br>
> >> attribute is to indicate that another node should also appear in<br>
> >> place of the node declaring 'USE'. In fact the specification states<br>
> >> (4.4.3 -<br>
> >><br>
> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics" rel="noreferrer" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19775-1/V3.3/<wbr>Part01/concepts.html#DEFL_<wbr>USESemantics</a><br>
> <<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics" rel="noreferrer" target="_blank">http://www.web3d.org/documen<wbr>ts/specifications/19775-1/V3.<wbr>3/Part01/concepts.html#DEFL_<wbr>USESemantics</a>>)<br>
> >> that "the same node is inserted into the scene graph a second time,<br>
> >> resulting in the node having multiple parents".<br>
> >><br>
> >> This requirement is not allowed in DOM (see<br>
> >> <a href="https://www.w3.org/TR/dom/#concept-node-tree" rel="noreferrer" target="_blank">https://www.w3.org/TR/dom/#con<wbr>cept-node-tree</a><br>
> <<a href="https://www.w3.org/TR/dom/#concept-node-tree" rel="noreferrer" target="_blank">https://www.w3.org/TR/dom/#c<wbr>oncept-node-tree</a>> for the standard,<br>
> >> <a href="https://www.w3.org/wiki/Traversing_the_DOM#Nodes" rel="noreferrer" target="_blank">https://www.w3.org/wiki/Traver<wbr>sing_the_DOM#Nodes</a><br>
> <<a href="https://www.w3.org/wiki/Traversing_the_DOM#Nodes" rel="noreferrer" target="_blank">https://www.w3.org/wiki/Trav<wbr>ersing_the_DOM#Nodes</a>> for the<br>
> >> explanation). A DOM element is allowed to have at most one<br>
> parent. It<br>
> >> is possible to create a (deep) copy of the node and insert it into<br>
> >> the tree. That gives a structure like:<br>
> >><br>
> >> [Meant to be seen in fixed width font]<br>
> >><br>
> >> B - C - D<br>
> >> /<br>
> >> A<br>
> >> \<br>
> >> E -CC -DD<br>
> >><br>
> >> Where A is the parent of this (sub-)tree, B is the node that start<br>
> >> one branch (e.g., Transform). C is the 'DEF'ed node with a child of<br>
> >> D. E is a separate child of A (e.g., a different Transform) CC<br>
> is the<br>
> >> 'USE' version of C. Since HTML does not allow multiple parents ('B'<br>
> >> and 'E'), a copy of 'C' needs to be made. This needs to be a deep<br>
> >> copy (all children) as no node can have more than one parent.<br>
> >><br>
> >> The problem with a deep copy is that it is non-deterministic as the<br>
> >> element is self-referential (it refers to it's parent, which refers<br>
> >> to it...)<br>
> >><br>
> >> It seems to me that there is a conflict in requirements between<br>
> X3D's<br>
> >> statement on DEF/USE and the requirement to put all X3D nodes<br>
> in the<br>
> >> DOM. There are several ways around this:<br>
> >> 1) Remove the multiple parent requirement from DEF/USE<br>
> >> 2) Remove the requirement of all nodes being in the DOM.<br>
> >><br>
> >> Each has advantages and disadvantages. Which choice is made<br>
> >> determines how X3D operates in the HTML/DOM environment.<br>
> >><br>
> >><br>
> >> Leonard Daly<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >>> Hi all,<br>
> >>><br>
> >>> Recently we updated the DTD/schemas to make the ?name? field of<br>
> >>> nodes like MetadataBoolean, or FloatVertexAttribute a required<br>
> >>> field. However, we then realised that when any of these nodes has<br>
> >>> the ?USE? attribute, the ?name? field must not be set. Hence the<br>
> >>> changes needed to be revisited.<br>
> >>><br>
> >>> I started to look at the JSON schema for the MetadataBoolean node,<br>
> >>> to try to implement this stricter validation requirement. With<br>
> some<br>
> >>> online assistance I found that I could easily make either one<br>
> or the<br>
> >>> other required, but not both. This would meet the original<br>
> requirement.<br>
> >>><br>
> >>> However, this raised a more general question in my mind. When any<br>
> >>> node has the ?USE? attribute set, what other fields/attributes are<br>
> >>> permitted?<br>
> >>><br>
> >>> As a test case, I concentrated on the MetadataBoolean node. I came<br>
> >>> up with a JSON schema that might illustrate this better. I have<br>
> >>> attached a snapshot image for this fragment of the JSON schema.<br>
> >>><br>
> >>> The validation of the MetadataBoolean node begins with a ?one of?<br>
> >>> operator (shown immediately to the right of the<br>
> MetadataBoolean box.<br>
> >>> This operator requires that one, and only one, of the two<br>
> subschemas<br>
> >>> be valid. For the first subschema (the upper of the two) I simply<br>
> >>> removed the ?@USE? property, making the ?@name? field required (to<br>
> >>> meet the original requirement). For the second subschema (the<br>
> lower<br>
> >>> of the two) I made the ?@USE? property required, and only<br>
> added the<br>
> >>> ?IS? property. Note that both subschemas only permit those<br>
> >>> properties listed (i.e. additional properties are disallowed).<br>
> >>><br>
> >>> In principle, there should be no difficulty applying this<br>
> validation<br>
> >>> methodology within the JSON schema to all nodes.<br>
> >>><br>
> >>> Some questions:<br>
> >>><br>
> >>> 1. Is this validation methodology correctly aligned with the<br>
> >>> standards?<br>
> >>> 2. Do we want to apply this methodology to all nodes?<br>
> >>> 3. Do we want to apply this methodology to other validation<br>
> tools,<br>
> >>> e.g. Schematron, and also consider whether the XML schema or<br>
> the DTD<br>
> >>> have sufficient expressive power too.<br>
> >>><br>
> >>> All comments appreciated,<br>
> >>><br>
> >>> All the best,<br>
> >>><br>
> >>> Roy<br>
> >>><br>
> >>><br>
> >>><br>
> >>> ______________________________<wbr>_________________<br>
> >>> x3d-public mailing list<br>
> >>> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> >>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><br>
> <<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/lis<wbr>tinfo/x3d-public_web3d.org</a>><br>
> >><br>
> >><br>
> >> --<br>
> >> *Leonard Daly*<br>
> >> 3D Systems & Cloud Consultant<br>
> >> LA ACM SIGGRAPH Chair<br>
> >> President, Daly Realism - /Creating the Future/<br>
> >><br>
> >><br>
> >> ______________________________<wbr>_________________<br>
> >> x3d-public mailing list<br>
> >> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> >> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><br>
> <<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/lis<wbr>tinfo/x3d-public_web3d.org</a>><br>
> >><br>
> ><br>
> ><br>
> > all the best, Don<br>
><br>
><br>
> --<br>
> *Leonard Daly*<br>
> 3D Systems & Cloud Consultant<br>
> LA ACM SIGGRAPH Chair<br>
> President, Daly Realism - /Creating the Future/<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL:<br>
> <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170618/76e05456/attachment-0001.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x<wbr>3d-public_web3d.org/attachment<wbr>s/20170618/76e05456/attachment<wbr>-0001.html</a><br>
> <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170618/76e05456/attachment-0001.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x<wbr>3d-public_web3d.org/attachment<wbr>s/20170618/76e05456/attachment<wbr>-0001.html</a>>><br>
><br>
> -----------------------------<wbr>-<br>
><br>
> Message: 2<br>
> Date: Sun, 18 Jun 2017 10:20:48 -0700<br>
> From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a><br>
> <mailto:<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.<wbr>com</a>>><br>
> To: <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> Subject: Re: [x3d-public] Resource bound to operation.<br>
> Message-ID: <<a href="mailto:30465783-809b-a43e-6289-2eb0eb853c9f@realism.com" target="_blank">30465783-809b-a43e-6289-2eb0e<wbr>b853c9f@realism.com</a><br>
> <mailto:<a href="mailto:30465783-809b-a43e-6289-2eb0eb853c9f@realism.com" target="_blank">30465783-809b-a43e-62<wbr>89-2eb0eb853c9f@realism.com</a>>><br>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
><br>
> John,<br>
><br>
> I don't follow this at all. What would the 'open' and 'execute'<br>
> methods<br>
> do? There are too many different ideas I can think of for each<br>
> statement, that I don't know where to begin.<br>
><br>
> Leonard Daly<br>
><br>
><br>
><br>
> On 6/16/2017 12:54 PM, John Carlson wrote:<br>
> > Would it be possible to have SAI or Dom that operated like this:<br>
> ><br>
> > var key = scenegraphNode.open("delete");<br>
> ><br>
> > var keys_key = scenegraphNode.open("list");<br>
> ><br>
> > var key2 = node.open("get", "field1");<br>
> ><br>
> > var key3 = node.open("put", "field1");<br>
> ><br>
> > var key5 = key3.execute(keys_key);<br>
> ><br>
> > var keys_again = key2.execute();<br>
> ><br>
> > var list = keys_again.execute()<br>
> ><br>
> > key.execute();<br>
> ><br>
> > keys_key.execute(); // fails<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > x3d-public mailing list<br>
> > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><br>
> <<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/lis<wbr>tinfo/x3d-public_web3d.org</a>><br>
><br>
><br>
> --<br>
> *Leonard Daly*<br>
> 3D Systems & Cloud Consultant<br>
> LA ACM SIGGRAPH Chair<br>
> President, Daly Realism - /Creating the Future/<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL:<br>
> <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170618/b8d64db4/attachment.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x<wbr>3d-public_web3d.org/attachment<wbr>s/20170618/b8d64db4/attachment<wbr>.html</a><br>
> <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170618/b8d64db4/attachment.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x<wbr>3d-public_web3d.org/attachment<wbr>s/20170618/b8d64db4/attachment<wbr>.html</a>>><br>
><br>
> -----------------------------<wbr>-<br>
><br>
> Subject: Digest Footer<br>
><br>
> _____________________________<wbr>__________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a> <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/list<wbr>info/x3d-public_web3d.org</a><br>
> <<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/lis<wbr>tinfo/x3d-public_web3d.org</a>><br>
><br>
><br>
> -----------------------------<wbr>-<br>
><br>
> End of x3d-public Digest, Vol 99, Issue 45<br>
> *****************************<wbr>*************<br>
><br>
><br>
><br>
><br>
> --<br>
> Andreas Plesch<br>
> 39 Barbara Rd.<br>
> Waltham, MA 02453<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><br>
<br>
<br>
--<br>
*Leonard Daly*<br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - /Creating the Future/<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170619/a158b525/attachment.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3<wbr>d-public_web3d.org/attachments<wbr>/20170619/a158b525/attachment.<wbr>html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><br>
<br>
<br>
------------------------------<br>
<br>
End of x3d-public Digest, Vol 99, Issue 48<br>
******************************<wbr>************<br>
</blockquote></div><br></div></div></div>