This is part of a multi-part post that explores some ideas for integrating X3D into HTML5 DOM. It explores various options and their implications. The primary post is "Integrating X3D into DOM - Issues".

This post examines the X3D and DOM issues with X3D's DEF/USE. The DEF/USE keywords define (DEF) a node sub-tree that can be reused (USE) anywhere in the same namescope. The USE nodes refer to the original DEF nodes. They are not a copy or subclass of the originals. This leads to the situation in the scene graph of some nodes having multiple parents. It allows for quick creation of the scene graph, especially when editing by hand; and reduces the memory requirements when storing the scene graph. It does not reduce the work load of the rendering system because each object needs to be rendered independently.

DOM explictly denies any element (DOM equivalent of an HTML tag) from having more or less than one parent. (Certain elements are their own parent.) If there is a need to have identical content in more than one place in the DOM tree, then it must be duplicated (cloned). This does not mean that external resources cannot be cached and reused, just that all of the DOM elements are unique. If you try to insert an existing element in the DOM tree into another location, it is removed from the existing location first.

This leads to the following conslusion. The following two requirements are inconsistent

1. All X3D nodes are represented in the DOM as DOM elements
2. X3D requires DEF/USE where X3D nodes that are USEd are references to the DEF nodes with the same DEF/USE name.

To avoid the inconsistency, it is necessary to relax one or both of the requirements. Relaxing (1) allows some X3D nodes to not be represented in the DOM as elements. This means that there is no means to access that X3D node using normal DOM techniques - by name, id, class, or walking the DOM tree. In that case an API defined and supplied by X3D must be used to access that node. Since the USE X3D node is not a separate entity in the scene graph, it can only be modified by changing the associated DEF node. There are well defined X3D and DOM means for doing that.

Relaxing (2) allows USE nodes to be copies of the associated DEF node. This means they can be changed independently of each other or that changes from the initial state of the DEF node do not change the USE nodes. If instead the USE nodes are "sub-classed" from the DEF node, then changes to the DEF node can be propigated to the USE nodes.

There is no "right" answer because these two requirements represent two different philosophies. Requirement (1) is the view of HTML5 where everything is in the DOM. There is current active work (in WhatWG) on incorporating hidden HTML stored in templates; however, this content does not render until it is inserted into the DOM. Once inserted into the DOM, it is unique - like all other DOM elements. Requirement (2) is the view of X3D. It is not used by other major rendering engines - Unity or Unreal. Both of those use sub-class mechanisms to handled reproduced content.