<p dir="ltr">a.</p>
<p dir="ltr">It may work to just declare in the spec. that the DEF value becomes the value of the id attribute when the node is interpreted as a DOM element. This way it may not be required to add an explicit id field to each node. However, it does seem narrow minded if simply adding an id attribute invalidates a x3d file.</p>
<p dir="ltr">b.</p>
<p dir="ltr">The default value for an explicit id field if deemed required could be the value of the DEF of the node.</p>
<p dir="ltr">c.</p>
<p dir="ltr">x3dom has both id and DEF attributes.<br>
If both id and DEF are set both attributes will have different values.<br>
If only DEF is given id is unset.<br>
If only id is given DEF and id will be set.<br>
<a href="http://examples.x3dom.org/example/x3dom_defUse.xhtml">http://examples.x3dom.org/example/x3dom_defUse.xhtml</a></p>
<p dir="ltr">In addition, to allow working with valid x3d files, x3dom has an attribute for inline nodes MapDEFtoID which generates the ID value from the DEF value.</p>
<p dir="ltr">d.</p>
<p dir="ltr">Cobweb does not use the DOM for x3d.</p>
<p dir="ltr">id is important for DOM compatibility and needs to be addressed in some way if x3d nodes are to be integrated in the DOM. If not, there needs to be clarification as well that x3d is not intended to be compatible with DOM use which would be a missed opportunity in my view.</p>
<p dir="ltr">Before we think about class we need to deal with id I think.</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Obvious questions:<br>
<br>
a. can DEF/USE simply be utilized instead?  First law of engineering: "if it isn't broken, don't fix it."<br>
<br>
b. if DEF/USE cannot or ought not to be utilized, then how is is backwards compatibility handled?  This includes Inline content loaded into a parent scene.<br>
<br>
c. what does X3DOM currently do?<br>
<br>
d. what does Cobweb currently do?<br>
<br>
<br>
On 3/20/2016 10:09 AM, John Carlson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'll second the proposal.  Also I'd like to propose adding CSS selectors for values of the fromNode and toNode attributes on ROUTEs if not already in the standard.  Thus if you have a node with id="foo"  you could use a route with toNode="#foo".  Class attributes would work similarly for fan in fan out.<br>
<br>
John<br>
<br>
On Mar 20, 2016 11:23 AM, "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a> <mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>>> wrote:<br>
<br>
    Since Don mentioned that nobody has proposed introducing an 'id' attribute, let me then propose adding an 'id' SFString attribute to all nodes for x3d 4.0.<br>
<br>
    The reason is simply compatibility with the DOM on web pages in the case where x3d nodes are interpreted as DOM elements.<br>
<br>
    Andreas<br>
[...]<br>
</blockquote>
<br>
all the best, Don<br>
-- <br>
Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   <a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
</div>