[x3d-public] [x3dom-users] DEF to ID mapping

[Roy Walmsley]

Andreas,

 

Discussion about the use of DEF or id in an HTML file is,  in the first instance, within the realm of an encoding. That is, it is specified in 19776 series specifications.

 

Also worth pointing out is that we discussed two candidate possibilities for the ‘integration’ of X3D in the DOM at the X3D working group meeting on Wednesday. Both these possibilities implied that some duplication of structures might be required. This is because in the DOM environment attributes are always strings (UTF-16, in fact). For X3D nodes that have numerical fields with potentially thousands of values, this is inefficient. Thus, X3D fields, at least, might be duplicated with DOM attributes.

 

So, having a further duplication of the X3D DEF with the DOM id is not such a big step. As you suggest, the id value could be the same as the DEF value.

 

In early April I plan to have another discussion in a X3D WG meeting to consider the issues arising on inserting an X3D file into an HTML page. You would be most welcome to join us if you are available. The meeting time is 0800 PDT (1500 UTC) on Wednesday mornings.

 

Regards,

 

Roy

 

From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of Andreas Plesch
Sent: 26 March 2016 18:29
To: Leonard Daly
Cc: x3dom mlist; X3D Graphics public mailing list
Subject: Re: [x3d-public] [x3dom-users] DEF to ID mapping

 

Leonard,

thanks for the background. This is very helpful. Let me see how I understand the background.

 

On Thu, Mar 24, 2016 at 11:37 AM, Leonard Daly <web3d at realism.com> wrote:

Andreas,

When the XML encoding spec was written (about the turn of the century now...) we anticipated the use of 'id' in nodes. It was never used as a field name for that reason. [Note: I will use ID instead of 'id' below.]

 

Ok. it was anticipated that an additional id attribute was used in xml (xhtml) nodes defining a x3d scene ? So there should be a way to make such a scene spec. conforming ?


http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/definitions.html

ID is the name of a data type.

http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax

DEF is an attribute of type ID.

 

It is good practice not to reuse names that must be unique within a namescope/namespace, even external to that scope. So while there are no explicit provisions preventing it, DEF names and ID values should not appear within the same scene; however, I don't think it can be stated that it is never the case.

 

Well, currently, conforming x3d scenes cannot have an ID value, right ? They can just have DEF values of type ID. 

 


DEF functions a little different than ID. DEF is name-scope limited. Each X3D occurrence of a file defines its own name scope. Also each PROTO or CreateX3dFromString/Url is its name scope. If an X3D file contains DEF='foo' and it is Inlined multiple times, each occurrence of 'foo' is different from any other occurrence of 'foo'. This is also a historical. Until X3DOM, X3D always ran in it's own environment. In X3DOM, it is running in the DOM environment. X3DOM takes care to prefix DEF names to prevent collisions.

 

Inlining the same file multiple times is a good case to consider. x3d has IMPORT/EXPORT to avoid collisions, and x3dom has namespacename. 

 


For ID, what is needed is globally (within the HTML page) unique values, including any Inlined, generated, or inserted nodes. I don't think it is possible to require that across all X3D code. Even if there was some sort of international registry, it would still fail if an X3D file was Inlined more than once. X3DOM avoids the name conflict issue by requiring the developer to create a prefix.

 

It is necessary for ID to be unique on the web page (globally). Both x3d and x3dom have mechanisms to make this easy for scene or web page authors. In theorym x3dom could implement IMPORT/EXPORT instead of using namespacename. 

It may a good idea to adopt namespacename in the x3d spec. as well.


I think it would be good to only have a single node label. If you have different values for DEF and ID, there is always the confusion as to which one goes (or does) what. If they are the same value, why have two labels.

 

Completely agree. It does not make sense to have two labels for the same function.

 

Perhaps DEF can be deprecated and ID be used going forward for all encodings. If both are specified, then ID overrides DEF.

 

Yes, this is the (big) question. If not for backward compatibility, I think simply stop using DEF and instead using ID would help a lot.

Perhaps, it is time take this fork in the road. The problem is it would make all x3d scenes which use DEF invalid. Replacing all occurrences of DEF with ID is not difficult, howevver.

Another interim solution may be to define an implicit ID attribute in the spec. which always has the value of the DEF field. 

To make this discussion more concrete, here is a proposal:


http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#NodeAndFieldStatementSyntax

could be amended by:

A node instance can be given a label using the attribute DEF followed by an equals sign and the quoted name of the node, as provided by the DEF statement. In addition, for DOM compatibility reasons, an additional attribute with the name ID is expressed implicitly which has the same value. This ID attribute is not part of the x3d scene graph but it is part of the fully parsed xml data structure and allows access to the element by the DOM API.

 

Feel free to criticize this proposal. Hopefully, the process can be constructive. 

 

-Andreas

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160326/3e3d9e8c/attachment.html>