<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Date: Sun, 18 Jun 2017 10:18:16 -0700<br>
From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com">Leonard.Daly@realism.com</a>><br>
To: <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
Subject: [x3d-public] Inconsistencies in Requirements [was: Validation<br>
improvements for "USE" attribute]<br>
Message-ID: <<a href="mailto:9364121c-2f7c-e998-da78-27808d24a8d8@realism.com">9364121c-2f7c-e998-da78-<wbr>27808d24a8d8@realism.com</a>><br>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"<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 parent in<br>
the case of DEF/USE<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2) For V4, there are statements that all X3D nodes will be in the DOM.<br></blockquote><div><br></div><div>I saw also a statement that there could be a parallel tree approach, such as x3dom and cobweb_dom employ.</div><div> </div><div>It may be also instructive to determine how x3dom currently deals with DEF/USE. My recollection is that DOM elements with a USE attribute have just one parent (they have to) but are mapped to x3dom nodes (in javascript memory) which have the DEF parent (through a map).</div><div><br></div><div>cobweb_dom is initally loading nodes including USE nodes with the SAI importDocument(DomNode) function (<a href="http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FunctionsBrowserObject">http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FunctionsBrowserObject</a>) . USE nodes added later to the DOM are parsed into the x3d graph using cobwebs parser which I think takes care of parenting to the x3d DEF node.</div><div><br></div><div>A-frame has an assets systems which allows reuse of components in multiple entities. I suspect A-frame avoids copying and would reference the same asset multiple times. This is possible because A-frame also has a parallel scene graph (the THREE graph) which exists in memory apart from the DOM.</div><div><br></div><div>Another angle is the shadow DOM but I am not sure if that applies since I suspect that it also does not allow multiple parents.</div><div><br></div><div>I think SVG has DEF/USE as well. SVG then must define some exceptions (?).</div><div><br></div><div>Overall, it looks like it may be necessary to rely on more than the DOM alone for DEF/USE functionality.</div><div><br></div><div>some thoughts, Andreas</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3) For V4, there are statements that it will be backward 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 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 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 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 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 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 for X3D<br>
> per se. We discussed Thursday on spec teleconference.<br>
><br>
> It would seem that allowing different 'class' attributes on USE 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 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 considered as<br>
> necessarily identical all of the time. If event models are decoupled<br>
> and handing off in tandem, then synchronization would occur 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>
>> <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/<wbr>documents/specifications/<wbr>19775-1/V3.3/Part01/concepts.<wbr>html#DEFL_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/#<wbr>concept-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/<wbr>Traversing_the_DOM#Nodes</a> for the<br>
>> explanation). A DOM element is allowed to have at most one 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 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 X3D's<br>
>> statement on DEF/USE and the requirement to put all X3D nodes 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 some<br>
>>> online assistance I found that I could easily make either one or the<br>
>>> other required, but not both. This would meet the original 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 MetadataBoolean box.<br>
>>> This operator requires that one, and only one, of the two 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 lower<br>
>>> of the two) I made the ?@USE? property required, and only 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 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 tools,<br>
>>> e.g. Schematron, and also consider whether the XML schema or 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">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/<wbr>listinfo/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">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/<wbr>listinfo/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: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170618/76e05456/attachment-0001.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/<wbr>attachments/20170618/76e05456/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<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">Leonard.Daly@realism.com</a>><br>
To: <a href="mailto:x3d-public@web3d.org">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">30465783-809b-a43e-6289-<wbr>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' 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">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/<wbr>listinfo/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/20170618/b8d64db4/attachment.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/<wbr>attachments/20170618/b8d64db4/<wbr>attachment.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">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/<wbr>listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
------------------------------<br>
<br>
End of x3d-public Digest, Vol 99, Issue 45<br>
******************************<wbr>************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>