This is the first of a multi-part post that examines the issues preventing easy integration of X3D into DOM. This post lists the specific issues and provides some background. It links to other posts that discuss the issue in more detail and in some cases provide possible solutions.

If it were easy to integrate X3D into HTML / DOM, then the work would have been done. People have been actively working on this for at least three years without complete solutions. So to be clear, what I mean by the statement "integrate X3D into HTML / DOM" is creating a solution where there are

1. no conflicts between the two languages
2. no new requirements on HTML or DOM to allow X3D to operate; IOW, X3D must function in the environment defined by DOM
3. X3D must remain declarative

It is important to note that this discussion is about integrating X3D into HTML/DOM not merging (with) vice versa. HTML is much larger environment in terms of use and it is entirely unreasonable for HTML to change to accommodate X3D (or any 3D language).

The issues that need to be addressed are listed below. In most cases these are HTML/XHTML issues, though the solutions may be slightly different between HTML and XHTML because of the nature of the languages.

1. No duplicate node names
2. Case insensitivity of node names (tags in HTML) and fields (attributes in HTML)
3. Including content from external files (HTML does not have this capability)
4. X3D allows multiple parents via USE - DOM explicitly denies this
5. Differences between HTML and X3D events
6. Differences between scripting in X3D and HTML

These issues will be explored in subsequent posts with links added when the posts are ready. This list comes from several years working on the problems. If any additional items are discovered, they will be added to the list.