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

The first issue is handling Inline code and the associated IMPORT/EXPORT statements. Inline nodes load X3D code from external files into the current scene graph. It is a way to manage complex scenes and improves content management. All content in an external file is in a separate namescope and is generally unavailable to a parent or sibling. The IMPORT and EXPORT statements provide a means to cross the namescope barrier. The developer must identify the Inline node (by DEF name) and the internal (Inline namescope) name. Optionally a local name may be provided.

The DOM has only one namescope - document. All HTML elements added to the DOM are fully available to any other node or code in the DOM. There is no need for IMPORT / EXPORT statements as there is no namescope barrier to cross. Suppose you have the X3D file (tree.x3d)

<X3D...>
<Scene>
    <Transform DEF='Maple' translation=...>
        <Shape...></Shape>
    </Transform>
</Scene>

This creates a single tree (all details removed) that is called 'Maple'. To get a maple forest you could create another X3D file (forest.x3d)

<X3D...>
<Scene>
    <Transform translation=...>
        <Inline url='tree.x3d'></Inline>
    </Transform>
    <Transform translation=...>
        <Inline url='tree.x3d'></Inline>
    </Transform>
    <Transform translation=...>
        <Inline url='tree.x3d'></Inline>
    </Transform>
    <Transform translation=...>
        <Inline url='tree.x3d'></Inline>
    </Transform>
    <Transform translation=...>
        <Inline url='tree.x3d'></Inline>
    </Transform>
            :
            :
</Scene>
 

that is comprised of many 'Maple' trees. In X3D each individual tree is a complete separate entity and unavailable from forest.x3d or any other maple.x3d. In HTML this would all be in the DOM and fully accessible. This is one of the significant differences between the two. In order to resolve this difference, it is necessary to have all of the nodes in the DOM, but prevent access from one namescope to another. HTML has no concept of namescope, so it must be built into the browser.

The DOM is a very flexible structure. Additional properties and objects can be added. In particular each X3D node can have a namescope attribute that all X3D API operations use to limit attribute that is DOM defined. X3D would be allowed to supply its own definition.

A definition like this would allow X3D to limit scope of a ROUTE statement to those nodes within the same namescope while allowed HTML-style references to access all similar nodes in a single call. For example to access all of the Transform nodes that have DEF='Maple' using jQuery a simple selector such as $("Transform [def=Maple]"). This returns a list of all Transform nodes that have the DEF value of 'Maple'.

This solution is rather simple and does not restrain the operation of either DOM or X3D.

IMPORT / EXPORT still plays a role in making the nodes in the Inlined file visible to the parent by providing the proper namespace and node DEF name translation when crossing namespaces.

The solution defined here works for creating namescopes; however, there are issues regarding attribute values that must be unique in HTML. This is discussed in "Integrating X3D into DOM - Unique Values".