<div dir="ltr"><p dir="ltr">Don,</p>
<p dir="ltr">thanks for your thorough exploration of what design may be required for introducing an ID attribute. I think the design goals capture nicely what was discussed so far and will help in guiding us to a good solution.<br></p>
<p dir="ltr">It looks like you prefer option 2B .</p>
<p dir="ltr">To be honest, my first reaction is how can we narrow the design goals to avoid having to handle a full specification of how x3d integrates within a DOM since I think it is very important to manifest some progress in this regard rather sooner than later. Baby steps.<br></p>
<p dir="ltr">So let's think about events. How does introducing an ID attribute in itself really affect the x3d event cascade ?<br>
The main use of the ID attribute will be the DOM API function document. getElementById() (<a href="https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById" target="_blank">https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById</a>) and it's jquery equivalent.
>From then on it is up to the author and the DOM x3d browser implementation what to do with the element and it's fields. This is unrelated to having an ID attribute.<br></p><p dir="ltr">Another way to think about what changes with introducing an ID attribute is to recognize that there are many other DOM functions to "get" or create a DOM element such as getElementsByTagName(). ById is merely the most useful and used method. This suggests that it will be necessary to separate questions which arise from the DOM having the ability manipulate x3d nodes (pass events into the x3d scenegraph) from questions which arise from merely introducing an ID attribute for convenient access to the x3d nodes from the DOM.</p><p>My hope is that (for now) we can leave the question of how the x3d scene graph and event cascade should respond to being manipulated by an outside DOM script unanswered and up to browser implementations. This is rather unsatisfactory but perhaps possible and would help in being able to focus on a smaller problem.</p><p>I will try to respond more specifically to most raised items as well.</p><p>Andreas<br></p><p dir="ltr"><br></p>
<div class="gmail_quote">On Mar 29, 2016 11:43 PM, "Don Brutzman" <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">An interesting relevant example in HTML4/HTML5 is the evolution of the Anchor tag <a>.<br>
<br>
In HTML4.01, both name and id attributes are allowed.<br>
<br>
======================================================<br>
<br>
<a href="https://www.w3.org/TR/html4/struct/links.html#h-12.2.1" rel="noreferrer" target="_blank">https://www.w3.org/TR/html4/struct/links.html#h-12.2.1</a><br>
12.2.1 Syntax of anchor names<br>
<br>
An anchor name is the value of either the name or id attribute when used in the context of anchors. Anchor names must observe the following rules:<br>
<br>
Uniqueness: Anchor names must be unique within a document. Anchor names that differ only in case may not appear in the same document.<br>
String matching: Comparisons between fragment identifiers and anchor names must be done by exact (case-sensitive) match.<br>
<br>
Thus, the following example is correct with respect to string matching and must be considered a match by user agents:<br>
<br>
<P><A href="#xxx">...</A><br>
...more document...<br>
<P><A name="xxx">...</A><br>
======================================================<br>
<br>
Looking in HTML5 specification, the "name" attribute is not mentioned. Further it is quite difficult to find where a URL bookmark ending in #bookmarkName is defined for the anchor tag - there is a lot of dense prose, but still haven't found where it is specified.<br>
<br>
A summary can be found here:<br>
<br>
======================================================<br>
<br>
<a href="http://www.w3schools.com/tags/att_a_name.asp" rel="noreferrer" target="_blank">http://www.w3schools.com/tags/att_a_name.asp</a><br>
<br>
HTML <a> name Attribute<br>
<br>
The <a> name attribute is not supported in HTML5. Use the id attribute instead.<br>
======================================================<br>
======================================================<br>
<a href="http://www.w3schools.com/tags/tag_a.asp" rel="noreferrer" target="_blank">http://www.w3schools.com/tags/tag_a.asp</a><br>
<br>
HTML <a> Tag<br>
<br>
Definition and Usage<br>
<br>
The <a> tag defines a hyperlink, which is used to link from one page to another.<br>
<br>
The most important attribute of the <a> element is the href attribute, which indicates the link's destination.<br>
======================================================<br>
<br>
An anchor tag can also include the attribute rel='bookmark' which indicates that the relationship of the href is to link to a bookmark.<br>
<br>
HTML5 relative-link example:<br>
======================================================<br>
<a href="http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_a_href_anchor" rel="noreferrer" target="_blank">http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_a_href_anchor</a><br>
<br>
<h2 id="top">Top of page!</h2><br>
...<br>
<a href="#top">Go to top</a><br>
======================================================<br>
<br>
Looking over all of the interesting information which is being collected, carefully keeping DEF and id as separate but intertwined/correlated concept definitions might have a number of advantages.<br>
<br>
At this point it is beginning to seem like the following design goals might be defined and met:<br>
<br>
- Coexistence: DEF/USE syntax and semantics remain perfectly OK for ROUTE and Script usage within an X3D scene graph that itself is a DOM fragment.<br>
- Independence: The unique id attribute allows external HTML scripts up in the document DOM to operate independently of any internal X3D activity.<br>
- Integration: Conceivably, fallback rules for correlating id/DEF might allow for graceful integration: loading a legacy X3D v3 scene into DOM doesn't require authors to perform intentional addition of duplicative id attributes before passing events.<br>
- Separation: once an event is within an X3D scene graph, X3D semantics apply.<br>
<br>
Not sure the X3DOM rules do that precisely, but they might be adapted to support these goals of coexistence, independence and integration.<br>
<br>
For example, perhaps additions might state things like:<br>
- The DOM requires that all id values are unique.<br>
- If a DOM event is passed from the DOM to an X3D scene that does not have a matching target id attribute, then the matching DEF attribute identifies the target node instead.<br>
- A DOM event cannot be passed from the DOM to an X3D scene fragment that does not have a matching id or DEF attribute; it is ignored.<br>
- An X3D event can be passed within the X3D scene graph or externally to the DOM, if no matching X3D DEF is present and a matching id is found.<br>
- For identical (internal) DEF and (likely external) id names, the DEF name takes precedence when routing X3D events.<br>
<br>
Encouraging design progress and dialog so far... examples and alternatives certainly help inform our understanding. To further increase clarity, we might build specific examples to illustrate each potential rule.<br>
<br>
Nevertheless we still have a ways to go, several tricky issues are still open:<br>
<br>
- How are SVG and MathML included and integrated within DOM?<br>
- How are HTML5 scripts and canvas objects integrated within DOM?<br>
- Need to list and illustrate all event-passing techniques from an external DOM tree into an X3D fragment.<br>
- Determine whether the X3D fragment needs a separate namespace, or can adequately be referenced via simple xpath expressions.<br>
- Determine whether the embedded "X3D namespaces" such as DEF/USE within a prototype or inline be unique, or ignored, or have specific prefixes.<br>
<br>
One more observation: isn't it interesting how a relatively "easy" id attribute proposal leads in all these many directions! 8)<br>
<br>
v/r Don<br>
<br>
<br>
<br>
On 3/23/2016 8:00 PM, Andreas Plesch wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
ad a.<br>
<br>
Statements such as ROUTE cannot have DEF fields, right ? What other potential DOM elements cannot have a DEF field ?<br>
Are these accessible by the SAI ?<br>
<br>
ad c.<br>
<br>
Although I cannot speak for Behr et al., I believe the x3dom rules meant to make it possible to separate x3d naming from DOM naming and keep x3d naming from interfering with DOM naming outside of x3d if so desired.<br>
<br>
I think, in practice this desire almost never materializes since the point of x3dom is to integrate x3d into the DOM. So the rule most often has the effect that it becomes necessary to assign DEF and id identical values.<br>
<br>
Andreas<br>
<br>
On Mar 20, 2016 11:53 PM, "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>
a.<br>
<br>
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.<br>
<br>
b.<br>
<br>
The default value for an explicit id field if deemed required could be the value of the DEF of the node.<br>
<br>
c.<br>
<br>
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" rel="noreferrer" target="_blank">http://examples.x3dom.org/example/x3dom_defUse.xhtml</a><br>
<br>
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.<br>
<br>
d.<br>
<br>
Cobweb does not use the DOM for x3d.<br>
<br>
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.<br>
<br>
Before we think about class we need to deal with id I think.<br>
</blockquote>
<br>
<br>
On 3/20/2016 2:33 PM, Don Brutzman wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
<br>
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>> <mailto:<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>
</blockquote></div>
</div>