[x3d-public] id attribute proposal

Wed Mar 30 07:32:09 PDT 2016

Don,

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.

It looks like you prefer option 2B .

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.

So let's think about events. How does introducing an ID attribute in itself
really affect the x3d event cascade ?
The main use of the ID attribute will be the DOM API function document.
getElementById() (
https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById)
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.

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.

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.

I will try to respond more specifically to most raised items as well.

Andreas

On Mar 29, 2016 11:43 PM, "Don Brutzman" <brutzman at nps.edu> wrote:

> An interesting relevant example in HTML4/HTML5 is the evolution of the
> Anchor tag <a>.
>
> In HTML4.01, both name and id attributes are allowed.
>
> ======================================================
>
> https://www.w3.org/TR/html4/struct/links.html#h-12.2.1
> 12.2.1 Syntax of anchor names
>
> 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:
>
>     Uniqueness: Anchor names must be unique within a document. Anchor
> names that differ only in case may not appear in the same document.
>     String matching: Comparisons between fragment identifiers and anchor
> names must be done by exact (case-sensitive) match.
>
> Thus, the following example is correct with respect to string matching and
> must be considered a match by user agents:
>
> <P><A href="#xxx">...</A>
> ...more document...
> <P><A name="xxx">...</A>
> ======================================================
>
> 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.
>
> A summary can be found here:
>
> ======================================================
>
> http://www.w3schools.com/tags/att_a_name.asp
>
> HTML <a> name Attribute
>
> The <a> name attribute is not supported in HTML5. Use the id attribute
> instead.
> ======================================================
> ======================================================
> http://www.w3schools.com/tags/tag_a.asp
>
> HTML <a> Tag
>
> Definition and Usage
>
> The <a> tag defines a hyperlink, which is used to link from one page to
> another.
>
> The most important attribute of the <a> element is the href attribute,
> which indicates the link's destination.
> ======================================================
>
> An anchor tag can also include the attribute rel='bookmark' which
> indicates that the relationship of the href is to link to a bookmark.
>
> HTML5 relative-link example:
> ======================================================
> http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_a_href_anchor
>
> <h2 id="top">Top of page!</h2>
> ...
> <a href="#top">Go to top</a>
> ======================================================
>
> 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.
>
> At this point it is beginning to seem like the following design goals
> might be defined and met:
>
> - 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.
> - Independence: The unique id attribute allows external HTML scripts up in
> the document DOM to operate independently of any internal X3D activity.
> - 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.
> - Separation: once an event is within an X3D scene graph, X3D semantics
> apply.
>
> Not sure the X3DOM rules do that precisely, but they might be adapted to
> support these goals of coexistence, independence and integration.
>
> For example, perhaps additions might state things like:
> - The DOM requires that all id values are unique.
> - 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.
> - 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.
> - 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.
> - For identical (internal) DEF and (likely external) id names, the DEF
> name takes precedence when routing X3D events.
>
> 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.
>
> Nevertheless we still have a ways to go, several tricky issues are still
> open:
>
> - How are SVG and MathML included and integrated within DOM?
> - How are HTML5 scripts and canvas objects integrated within DOM?
> - Need to list and illustrate all event-passing techniques from an
> external DOM tree into an X3D fragment.
> - Determine whether the X3D fragment needs a separate namespace, or can
> adequately be referenced via simple xpath expressions.
> - Determine whether the embedded "X3D namespaces" such as DEF/USE within a
> prototype or inline be unique, or ignored, or have specific prefixes.
>
> One more observation: isn't it interesting how a relatively "easy" id
> attribute proposal leads in all these many directions!  8)
>
> v/r Don
>
>
>
> On 3/23/2016 8:00 PM, Andreas Plesch wrote:
>
>> ad a.
>>
>> Statements such as ROUTE cannot have DEF fields, right ? What other
>> potential DOM elements cannot have a DEF field ?
>> Are these accessible by the SAI ?
>>
>> ad c.
>>
>> 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.
>>
>> 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.
>>
>> Andreas
>>
>> On Mar 20, 2016 11:53 PM, "Andreas Plesch" <andreasplesch at gmail.com
>> <mailto:andreasplesch at gmail.com>> wrote:
>>
>>     a.
>>
>>     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.
>>
>>     b.
>>
>>     The default value for an explicit id field if deemed required could
>> be the value of the DEF of the node.
>>
>>     c.
>>
>>     x3dom has both id and DEF attributes.
>>     If both id and DEF are set both attributes will have different values.
>>     If only DEF is given id is unset.
>>     If only id is given DEF and id will be set.
>>     http://examples.x3dom.org/example/x3dom_defUse.xhtml
>>
>>     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.
>>
>>     d.
>>
>>     Cobweb does not use the DOM for x3d.
>>
>>     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.
>>
>>     Before we think about class we need to deal with id I think.
>>
>
>
> On 3/20/2016 2:33 PM, Don Brutzman wrote:
>
>>     Obvious questions:
>>
>>     a. can DEF/USE simply be utilized instead?  First law of engineering:
>> "if it isn't broken, don't fix it."
>>
>>     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.
>>
>>     c. what does X3DOM currently do?
>>
>>     d. what does Cobweb currently do?
>>
>>
>>     On 3/20/2016 10:09 AM, John Carlson wrote:
>>
>>         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.
>>
>>         John
>>
>>         On Mar 20, 2016 11:23 AM, "Andreas Plesch" <
>> andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:
>> andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>> wrote:
>>
>>              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.
>>
>>              The reason is simply compatibility with the DOM on web pages
>> in the case where x3d nodes are interpreted as DOM elements.
>>
>>              Andreas
>>         [...]
>>
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160330/4d5e6584/attachment-0001.html>