<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I read the message below yesterday and
I don't see how it answers the issue of USE statements. Perhaps it
is my lack of understanding of something here. Can it the answer
please be restated. To help things along I am summarizing my
points.<br>
<br>
1) The X3D specification requires nodes to have more than one
parent in the case of DEF/USE.<br>
2) For V4, there are statements that all X3D nodes will be in the
DOM.<br>
3) For V4, there are statements that it will be backward
compatible (as 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 (though it is possible to petition for a change). It
is possible to change the X3D specification (1). It is also
possible to relax the statements in (2) and (3).<br>
<br>
There are inconsistent requirements if DEF/USE means a reference
to the DEF node and all nodes are in the DOM.<br>
There are consistent requirements if DEF/USE means a copy of the
node tree originating at the DEF node (drop #1&3)<br>
There are consistent requirements if not all X3D nodes are in the
DOM (drop #2)<br>
<br>
I would be interested in hearing anyone else's ideas on how the
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
specifications, it makes no sense to allow 'class' in a node as
the USE attribute indicates that what appears in this position in
the scene graph is a reference to a node defined elsewhere. There
is no provision for this DEF node to be anything other than a
reference.<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:8891a278-92be-3731-97aa-d8243363b736@nps.edu">Primary is
getting to clarity on best possible USE definition for X3D per
se. We discussed Thursday on spec teleconference.
<br>
<br>
It would seem that allowing different 'class' attributes on USE in
the XML Encoding is over-generous and should be tightened to not
be allowed. We were able to come up with examples that showed
diverse class+USE is problematic (e.g. cannot style a Material
node to be a class='somethingBlue' while styling a USE version of
the same node to be class='somethingRed').
<br>
<br>
Next will be considering if 'class' attribute can be advanced to
abstract spec and hence all encodings; currently it is only
reserved/defined in XML Encoding.
<br>
<br>
Regarding DOM tree and X3D tree, they do not have to be considered
as necessarily identical all of the time. If event models are
decoupled and handing off in tandem, then synchronization would
occur after each respective update. There are different ways for
implementations to accomplish this - all worth considering, with
HTML5/DOM Recommendations being authoritative regarding
functionality.
<br>
<br>
So, step by step. If we can define semantics that work
consistently/coherently, and can be implemented, we then refine
iteratively for use in each X3D encoding.
<br>
<br>
<br>
<br>
On 6/15/2017 10:58 AM, Leonard Daly wrote:
<br>
<blockquote type="cite">The original purpose (and still used in
this manner) of the 'USE' attribute is to indicate that another
node should also appear in place of the node declaring 'USE'. In
fact the specification states (4.4.3 -
<a class="moz-txt-link-freetext" href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#DEFL_USESemantics</a>)
that "the same node is inserted into the scene graph a second
time, resulting in the node having multiple parents".
<br>
<br>
This requirement is not allowed in DOM (see
<a class="moz-txt-link-freetext" href="https://www.w3.org/TR/dom/#concept-node-tree">https://www.w3.org/TR/dom/#concept-node-tree</a> for the standard,
<a class="moz-txt-link-freetext" href="https://www.w3.org/wiki/Traversing_the_DOM#Nodes">https://www.w3.org/wiki/Traversing_the_DOM#Nodes</a> for the
explanation). A DOM element is allowed to have at most one
parent. It is possible to create a (deep) copy of the node and
insert it into 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 one branch (e.g., Transform). C is the 'DEF'ed node with a
child of D. E is a separate child of A (e.g., a different
Transform) CC is the 'USE' version of C. Since HTML does not
allow multiple parents ('B' and 'E'), a copy of 'C' needs to be
made. This needs to be a deep 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 element is self-referential (it refers to it's parent, which
refers to it...)
<br>
<br>
It seems to me that there is a conflict in requirements between
X3D's statement on DEF/USE and the requirement to put all X3D
nodes in the 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
determines how X3D operates in the HTML/DOM environment.
<br>
<br>
<br>
Leonard Daly
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">Hi all,
<br>
<br>
Recently we updated the DTD/schemas to make the “name” field
of nodes like MetadataBoolean, or FloatVertexAttribute a
required field. However, we then realised that when any of
these nodes has the “USE” attribute, the “name” field must not
be set. Hence the changes needed to be revisited.
<br>
<br>
I started to look at the JSON schema for the MetadataBoolean
node, to try to implement this stricter validation
requirement. With some online assistance I found that I could
easily make either one or the 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 node has the “USE” attribute set, what other
fields/attributes are permitted?
<br>
<br>
As a test case, I concentrated on the MetadataBoolean node. I
came up with a JSON schema that might illustrate this better.
I have attached a snapshot image for this fragment of the JSON
schema.
<br>
<br>
The validation of the MetadataBoolean node begins with a “one
of” operator (shown immediately to the right of the
MetadataBoolean box. This operator requires that one, and only
one, of the two subschemas be valid. For the first subschema
(the upper of the two) I simply removed the “@USE” property,
making the “@name” field required (to meet the original
requirement). For the second subschema (the lower of the two)
I made the “@USE” property required, and only added the “IS”
property. Note that both subschemas only permit those
properties listed (i.e. additional properties are disallowed).
<br>
<br>
In principle, there should be no difficulty applying this
validation methodology within the JSON schema to all nodes.
<br>
<br>
Some questions:
<br>
<br>
1. Is this validation methodology correctly aligned with the
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, e.g. Schematron, and also consider whether the XML
schema or the DTD have sufficient expressive power too.
<br>
<br>
All comments appreciated,
<br>
<br>
All the best,
<br>
<br>
Roy
<br>
<br>
<br>
<br>
_______________________________________________
<br>
x3d-public mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<br>
<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>
<br>
</blockquote>
<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>
_______________________________________________
<br>
x3d-public mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<br>
<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>
<br>
<br>
</blockquote>
<br>
<br>
all the best, Don
<br>
</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>