[x3d-public] id attribute proposal

[Andreas Plesch]

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> 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.
> 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>> 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/20160323/6229ddef/attachment.html>