<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Andreas,<br>
<br>
Interesting points. I've added information I know (or found)
embedded in your comments.<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKdk67vwE_xKJt5Xx2iiQn7_oD6jOH3yV_KGFpeRjRf8CgZo1w@mail.gmail.com">
<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"><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>
</div>
</div>
</blockquote>
<br>
I have looked through the code and have not yet been able to find
the specific lines that deal with 'USE'. X3DOM does deal with 'USE'
as can be seen in the example at
<a class="moz-txt-link-freetext" href="https://examples.x3dom.org/example/x3dom_defUse.xhtml">https://examples.x3dom.org/example/x3dom_defUse.xhtml</a>. View-source
shows that it is used in the second 'Shape'. I suspect that the
second 'Shape' is removed from the DOM but kept in the scene graph.
<br>
<br>
This particular method breaks (2 - not all X3D nodes are in the
DOM). I believe Andreas describes Cobweb as doing essentially the
same thing.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67vwE_xKJt5Xx2iiQn7_oD6jOH3yV_KGFpeRjRf8CgZo1w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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"
moz-do-not-send="true">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>
</div>
</div>
</blockquote>
<br>
I have looked at the asset system in A-Frame, but not in sufficient
depth to determine whether <br>
1) It uses the data as a single copy inserted into the DOM in the
asset statement with the uses not appearing in the DOM<br>
2) It copies the information from the asset definition to the node
that 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, then it could very easily work like CSS by supplying a common
definition that other nodes just refer to (#3 above).<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67vwE_xKJt5Xx2iiQn7_oD6jOH3yV_KGFpeRjRf8CgZo1w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<br>
Shadow DOM is (sort-of) like regular DOM. You are right about not
allowing multiple parents. It allows you to expose elements to the
(page) renderer without them being directly visible in the DOM.
Since the scene graph is roughly parallel to the DOM, adding another
DOM seems to me to be increasing the complexity without necessarily
solving the problem. <br>
<br>
Even though it is 6 years old, this article provides a good basic
description of Shadow DOM -
<a class="moz-txt-link-freetext" href="https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/">https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/</a><br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67vwE_xKJt5Xx2iiQn7_oD6jOH3yV_KGFpeRjRf8CgZo1w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<div>I think SVG has DEF/USE as well. SVG then must define
some exceptions (?).</div>
</div>
</div>
</div>
</blockquote>
<br>
Not being an SVG expert, I had to look this up. I found this Stack
Overflow questions:
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/19246232/svg-reuse-a-line-node-with-def-and-use">https://stackoverflow.com/questions/19246232/svg-reuse-a-line-node-with-def-and-use</a><br>
<br>
It describes that the 'use' attribute does a deep clone and inserted
into the generated tree. Unfortunately, the answer did not provide a
reference, but it does look like it is quoting something important.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67vwE_xKJt5Xx2iiQn7_oD6jOH3yV_KGFpeRjRf8CgZo1w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<br>
Offering another possibility. Unreal (and I think Unity) create a
class for each object. If something is "copied", then it is
sub-classed from the original class. Changes to the parent propagate
to all subclasses; however, a sub-class can override any property
(which would then propagate to sub-sub-classes). I think that means
in "X3D"-speak, the "DEF" node defines the master class. Any node
that "USE"s it would create a subclass. A USE node could also
redefine fields for that subclass, and even make itself available
for subclassing by using a DEF statement. This would look something
like:<br>
<br>
<Transform DEF='Master' translation='1 2 3' rotation='0 1 0 0'
scale='1 1 1'>...</Transform><br>
<br>
<Transform USE='Master'>...</Transform> <!-- strict
subclass of Master --><br>
<Transform USE='Master' DEF='Alpha' rotation='1 0 0
1.57'>...</Transform> <!-- subclass of Master with a
change of rotation --><br>
<Transform USE='Master' DEF='Beta' rotation='0 0 1
1.57'>...</Transform> <!-- different subclass of Master
with a change of rotation --><br>
<Transform USE='alpha' scale='2 2 2'>...</Transform>
<!-- subclass of Alpha with a change of scale --><br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAKdk67vwE_xKJt5Xx2iiQn7_oD6jOH3yV_KGFpeRjRf8CgZo1w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">x3d-public@web3d.org</a><br>
>>> <a
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">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"
moz-do-not-send="true">x3d-public@web3d.org</a><br>
>> <a
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">Leonard.Daly@realism.com</a>><br>
To: <a href="mailto:x3d-public@web3d.org"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">x3d-public@web3d.org</a><br>
> <a
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">x3d-public@web3d.org</a><br>
<a
href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>