Main post that lists the major issues for integration.

The previous post ("Integrating X3D Into DOM - Inline") developed a solution for namescoped nodes, specifically Inline. This post looks at implications of that solution.

The method of defining a namescope and having all nodes in the DOM depended on adding a new property to each node that defined the namescope of that node. It allowed DOM mechanisms to access the data in a traditional DOM manner while allowing X3D to control access through its own mechanism - namescope. This worked because the property is not required to be unique in DOM - in fact it is not even defined in DOM.

The situation is a little different for data that must be unique in DOM. This applies to the ID value. It is required to be unique throughout the entire HTML document. Now. HTML being what it is, this requirement is generally not enforced; however, it is strictly enforced in XHTML. The solution of stating that the ID values belong to different namescopes does not work because there are no namescopes in HTML.

The only ways to deal with the non-uniqueness of ID names is to either

1. Eliminate ID as an allowed X3D attribute
2. Modify the ID value of any node in an Inline

The discussion started with Inline nodes, but this conflict applies to all nodes that are externally included.

Both of the above solutions cause problems and move away from a nice-HTML integration. Eliminating ID attribute in X3D removes an important means for uniquely identiftying a node. Modifying the value (potentially with a developer-specified modifier) still allows for unique IDs within the DOM, but the originally defined ID value is not necessarily what shows up in the scene. It is encumbant upon the X3D software to appropriately modify the ID value so that the value remains unique in the scene, and the developer knows (if desired) what the value will be.

Since X3D does not use the value of the ID attribute, changing it does not cause a problem with anything currently defined in the X3D specification.