<div dir="ltr"><div>Leonard,<br><br></div>thanks for the background. This is very helpful. Let me see how I understand the background.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 24, 2016 at 11:37 AM, Leonard Daly <span dir="ltr"><<a href="mailto:web3d@realism.com" target="_blank">web3d@realism.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Andreas,<br>
<br>
When the XML encoding spec was written (about the turn of the
century now...) we anticipated the use of 'id' in nodes. It was
never used as a field name for that reason. [Note: I will use ID
instead of 'id' below.]<br></div></div></blockquote><div><br></div><div>Ok. it was anticipated that an additional id attribute was used in xml (xhtml) nodes defining a x3d scene ? So there should be a way to make such a scene spec. conforming ?<br></div><div><br><a href="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/definitions.html">http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/definitions.html</a><br><br></div><div>ID is the name of a data type.<br><br><a href="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax">http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax</a><br><br></div><div>DEF is an attribute of type ID.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
It is good practice not to reuse names that must be unique within
a namescope/namespace, even external to that scope. So while there
are no explicit provisions preventing it, DEF names and ID values
should not appear within the same scene; however, I don't think it
can be stated that it is never the case.<br></div></div></blockquote><div><br></div><div>Well, currently, conforming x3d scenes cannot have an ID value, right ? They can just have DEF values of type ID. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
<br>
DEF functions a little different than ID. DEF is name-scope
limited. Each X3D occurrence of a file defines its own name scope.
Also each PROTO or CreateX3dFromString/Url is its name scope. If
an X3D file contains DEF='foo' and it is Inlined multiple times,
each occurrence of 'foo' is different from any other occurrence of
'foo'. This is also a historical. Until X3DOM, X3D always ran in
it's own environment. In X3DOM, it is running in the DOM
environment. X3DOM takes care to prefix DEF names to prevent
collisions.<br></div></div></blockquote><div><br></div><div>Inlining the same file multiple times is a good case to consider. x3d has IMPORT/EXPORT to avoid collisions, and x3dom has namespacename. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
<br>
For ID, what is needed is globally (within the HTML page) unique
values, including any Inlined, generated, or inserted nodes. I
don't think it is possible to require that across all X3D code.
Even if there was some sort of international registry, it would
still fail if an X3D file was Inlined more than once. X3DOM avoids
the name conflict issue by requiring the developer to create a
prefix.<br></div></div></blockquote><div><br></div><div>It is necessary for ID to be unique on the web page (globally). Both x3d and x3dom have mechanisms to make this easy for scene or web page authors. In theorym x3dom could implement IMPORT/EXPORT instead of using namespacename. <br></div><div>It may a good idea to adopt namespacename in the x3d spec. as well.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
<br>
I think it would be good to only have a single node label. If you
have different values for DEF and ID, there is always the
confusion as to which one goes (or does) what. If they are the
same value, why have two labels.<br>
<br></div></div></blockquote><div><br></div><div>Completely agree. It does not make sense to have two labels for the same function.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
Perhaps DEF can be deprecated and ID be used going forward for all
encodings. If both are specified, then ID overrides DEF.<br>
<br></div></div></blockquote><div><br></div><div>Yes, this is the (big) question. If not for backward compatibility, I think simply stop using DEF and instead using ID would help a lot.<br></div><div>Perhaps, it is time take this fork in the road. The problem is it would make all x3d scenes which use DEF invalid. Replacing all occurrences of DEF with ID is not difficult, howevver.<br><br></div><div>Another interim solution may be to define an implicit ID attribute in the spec. which always has the value of the DEF field. <br><br></div><div>To make this discussion more concrete, here is a proposal:<br></div><div><br><a href="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#NodeAndFieldStatementSyntax">http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#NodeAndFieldStatementSyntax</a><br><br></div><div>could be amended by:<br><br>A node instance can be given a label using the
attribute DEF followed by an equals sign and the quoted name of the node, as provided by the DEF statement. In
addition, for DOM compatibility reasons, an additional attribute with the name ID is expressed implicitly which has the same value. This ID attribute is not part of the x3d scene graph but it is part of the fully parsed xml data structure and allows access to the element by the DOM API.<br></div><div> <br></div><div>Feel free to criticize this proposal. Hopefully, the process can be constructive. <br></div><div><br></div><div>-Andreas<br></div><div> </div></div></div></div>