[x3d-public] id attribute proposal

[Andreas Plesch]

On Tue, Mar 29, 2016 at 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.
>

Yes, "name" is not used anymore (except for forms, I believe).

Here is where URL syntax is defined:
https://url.spec.whatwg.org/#url-syntax
http://tools.ietf.org/html/rfc3986#section-3.5
It allows "#" followed by a fragment identifier.

https://www.w3.org/TR/html5/dom.html#the-id-attribute
has a note that id can be used as a fragment identifier. It is not much to
go by. Perhaps the DOM spec. has more on this.


> ...
>
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.
>

Yes, this is certainly an option especially if complete backward
compatibility is high on the list of requirements.


> 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.
>

ok for route usage. It is rather difficult to reconcile how X3D scripts
could coexist with DOM scripts in a DOM tree where a X3D scene 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.
>

The id attribute is actually not necessary to allow external scripts to
operate on x3d nodes. As soon as a x3d scene becomes a DOM fragment and
part of the DOM tree, each x3d node becomes a DOM element and can be
accessed or created, even without an id attribute. So there is potential
for cross-over of external manipulation and internal x3d activity. For
example, it is possible to change a field by ROUTE internally and in
parallel change the same field by external access. Perhaps it possible to
avoid addressing this potential by delegating it to authors' and browser
implementations' responsibility.


> - 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.
>

Yes, this is what x3dom's mapDEFtoID option for inline accomplishes.
However, x3dom's default mapping is DOM centric and does not assign an
identical ID attribute since it assumes that the ID may be used elsewhere,
outside the scene. This assumption may be overly cautious.


> - Separation: once an event is within an X3D scene graph, X3D semantics
> apply.
>

Yes, DOM X3D browser implementations need to apply X3D semantics to
interpret events. A complete separation of event handling seems difficult,
since the DOM houses the x3d scene and can thus take over essentially
anything if it so wishes.


> Not sure the X3DOM rules do that precisely, but they might be adapted to
> support these goals of coexistence, independence and integration.
>

It sounds like the X3D centric mapping rules would best support these goals.

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.
>

Or perhaps give each x3d node with a DEF attribute, an identical id
attribute in the first place, even if only implied, in order to avoid
entanglement with events.


> - 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.
>

yes. This may not have to be spelled out since the DOM would not be able to
get a reference to a x3d node by using a non existing id value.


> - 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.
>

hm. This means mapping id to DEF while also mapping DEF to id (see above).
Not sure.


> - For identical (internal) DEF and (likely external) id names, the DEF
> name takes precedence when routing X3D events.
>

Ok. This is the case where there is a DEF name which is also used by an
external id. It may be best to not allow this, eg. leaving the behaviour
undefined in case x3d centric rules are used. I was asking for example apps
which do this but did get anything back. Probably need to check all x3dom
examples but I do not think there is one which would do that.

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.
>

Examples are good. Should we have a place to collect such examples ?


> Nevertheless we still have a ways to go, several tricky issues are still
> open:
>
> - How are SVG and MathML included and integrated within DOM?
>

https://developer.mozilla.org/en-US/docs/Web/SVG
https://developer.mozilla.org/en-US/docs/SVG_In_HTML_Introduction
https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model#SVG_interfaces
A SVG element is a DOM element. As such svg elements can be manipulated
using the DOM API.
SVG has animation through an animate element which  can modify parent
attributes, in a way similar to ROUTEs. I could not find a specification on
what is supposed to happen if an animate element modifies an attribute
internally while the same attribute is also modified by the DOM externally.
I suspect behaviour is left undefined eg. there is some kind of fight going
on.

x3dom is partially inspired by SVG. The FHG publications have more on its
DOM integration, I expect.

https://www.w3.org/TR/MathML2/chapter8.html

has the DOM part of the spec. which is actually then here
https://www.w3.org/TR/MathML2/appendixd.html

Interestingly, the latest spec. MathML3

https://www.w3.org/TR/2014/REC-MathML3-20140410/
https://www.w3.org/TR/2014/REC-MathML3-20140410/chapter6.html

does not have a DOM spec. anymore. Perhaps it was never used since it is
rare that you would want to animate, or programmatically construct math
equations.

BTW, should we start to use MathML in the x3d spec. for equations ?
Currently, x3d equations seem to be hand-crafted by HTML font styling.

- How are HTML5 scripts and canvas objects integrated within DOM?
>

By HTML5 scripts, I assume you refer to the HTML5 script element ? It is a
regular DOM element. It is actually quite common to create and access a
script element (set the src attribute) from another script in order to
inject/import functionality into a page.

Canvas is a regular DOM element. In fact, you need to use the DOM to
populate a canvas element with graphical content. As such, the canvas
element has many DOM methods specific to it. The canvas element has no
internal animation capability. Animation needs to be driven by external DOM
access creating frames. This is what x3dom does. Canvas access,
manipulation and rendering is very efficient in modern web browsers.

- Need to list and illustrate all event-passing techniques from an external
> DOM tree into an X3D fragment.
>

There is .setAttribute . x3dom has additional techniques:
http://doc.x3dom.org/tutorials/basics/fields/
What other events need to be passed ?


> - Determine whether the X3D fragment needs a separate namespace, or can
> adequately be referenced via simple xpath expressions.
>

Could you expand ? With the json encoding it will be easy to put two x3d
scenes on the same page, in a single DOM tree.


> - Determine whether the embedded "X3D namespaces" such as DEF/USE within a
> prototype or inline be unique, or ignored, or have specific prefixes.
>

It should be possible to rely on the existing IMPORT/EXPORT semantics for
DEF/USE. It could be adopted for ID as well, for simplicity. x3dom will
keep the namespacename option which is more staightforward. Do we need IDs
in a prototype ? Is it currently possible via SAI to access specific nodes
in a specific prototype instance ?


> One more observation: isn't it interesting how a relatively "easy" id
> attribute proposal leads in all these many directions!  8)
>

Oh yes. Let's be very focussed on keeping it to as few directions as
possible (but as many as absolutely necessary).

Andreas

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
>



-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160330/d035badc/attachment-0001.html>