Wrapper Tags Considered Harmful

Don Brutzman, 6 February 2000

Problem statement

Tags in the x3d-draft.dtd map VRML nodes to XML tags. Parent-child relationships among VRML nodes correspond to parent-child relationships among XML tags. "Wrapper tags" inserts an explicit tag for labeling each field name. This means that the wrapper tags create new nodes in the scene graph when instantiated as an object model.

Here is an implemented WrapperTagsExample.xml and a VRML translation to show the nodes used.

A link to the opposing arguments will be added when provided.

Implementation and evaluation background

This technical analysis of wrapper tags is based on implementing and evaluating X3D using multiple languages and representations: DTD tagset definitions and XML tags, closely observing development of Xj3D browser written in Java3D, scene graph visualization using the X3D-Edit authoring tool, using half a dozen (of 27+ available) XML parsers, Extensible Stylesheet Language (XSL) parsing & translation from XML to VRML/HTML, and (perhaps most importantly) the VRML source which results from translation

Reasons why wrapper tags are harmful

  1. Wrapper tags do not fix any real problem. Solutions are demonstrated for all examples that have been proposed.
  2. Wrapper tags add no information to a scene. Example: the fixed-pair tagset <appearance><Appearance>...</Appearance></appearance> is functionally identical to the tagset <Appearance>...</Appearance>, as search/replace using any text editor quickly shows. Evidence: the X3D->VRML stylesheet translates the full VRML scene graph satisfactorily and identically, with or without wrappers, by trapping and immediately discarding wrapper tags whenever found.
  3. Unnecessarily verbose. Adding superfluous wrapper tags make X3D scene graph files harder to read, harder to author, and thus more error prone. These problems harm X3D deployment.
  4. Wrapper tags bloat every scene subgraph and increase all file sizes. To date, three estimates have been made on the severity of this problem. Given tokenization capabilities of compression tools, wrapper tags are not expected to make significant difference in compressed scenes.
  5. No valid counterexamples have been proposed or demonstrated. A wide variety of valid examples have been demonstrated in equivalent VRML and X3D without wrappers. Next step is to translate every example in the VRML 97 specification. There is no problem case made for wrapper tags.
  6. Disambiguation of children nodes without wrapper tags has been demonstrated. Detecting and disambiguating children takes 2-3 case statements with ~15 cases, all of which are needed anyway when building a VRML 97 scene graph.
  7. Making multiple children into multiple grandchildren doesn't solve node disambiguation. Case statements matching node names disambiguates nodes.
  8. Future extensions are not a lurking problem. The number of case statements needed for disambiguation is bounded to match VRML 97 semantics. Future X3D extensions must map node types to VRML, and thus must explicitly define contained nodes just as PROTO declarations do. PROTO examples are already demonstrated to work without wrapper tags.
  9. Working alternative to wrapper tags implemented and demonstrated. WrapperTagsExample shows four separate solutions - be sure to view the VRML result PROTO declarations using PROTO tags and new native XML tags have each been demonstrated to perform equivalently and interoperably. Thus there are no downstream problems for new X3D extensions when we choose to avoid wrapper tags.
  10. VRML 97 nodes strictly map to XML tags in x3d-draft.dtd. Scene graph relationships are unambiguously preserved with a one-to-one correspondence by tag relationships. Wrappers insert relationship labels as nodes/tags, which is incorrect semantics and incorrect topology for graph instances that are reflecting VRML 97 scene graphs. Incorrect topology is a major indicator of incompatibility problems. Related note: traversing a 'this-grandchild-is-one-of-this-parents-children' wrapper doesn't render.
  11. Mixed, mismatched semantics are error-prone representations. Errors occurring in such designs are typically subtle and difficult to debug.
  12. A scene graph with wrapper tags has a different topology than the VRML 97 scene graph. This means that tree algorithms must be modified prior to being able run on X3D-based scene graphs. This opposes requirements to map X3D to VRML 97.
  13. Parser testing. All X3D parsers originally placed under public scrutiny have worked. The Blendo parser needs to be tested. This was made available 4 February 2000 following a long-standing claim that it was unable to parse X3D without wrapper tags. Further scrutiny regarding its capabilities is now warranted.
  14. Numerous tests satisfactory without wrapper tags. About a dozen public XML parsers have been tested out of 27+ available. All work satisfactorily without wrapper tags. Smallest parsers to date include XPAT (44 KB Windows executable) and Internet Explorer 5.01 (0 KB). Parser instances smaller than 44 KB are likely soon, using customized Java or C++ classes autogenerated directly from the DTD.
  15. Demonstrated validity without wrapper tags. Translating VRML -> X3D -> VRML correctly and exhaustively has demonstrated DTD validity for all VRML 97 nodes without wrapper tags.
  16. Routing events to/from wrapper tags produces a VRML error. This is because such tags perform no function, and the events needed to be routed to the intended scene node regardless. Such new errors are eliminated when wrapper tags are eliminated. Examples have shown that routing to child nodes (such as sending an Appearance node as an event to a Shape's SFNode appearance field) occurs using identical syntax in X3D and VRML.
  17. Creation of nonfunctional classes in autogenerated code. Wrapper tags add a significant number of wrapper classes which must be instantiated and supported. This is because a DTD is not a suggestion about how to interpret a tagset - a DTD directly and strictly instantiates classes and functionality in software. Thus wrapper tags also cause code bloat, increased code complexity for implementers, and increased possibility of run-time error for developers.
  18. Performance reductions on every render cycle. Because they have no functionality, adding intermediate wrapper classes only reduces run-time performance by a tiny amount. However this performance reduction occurs on every traversal of every parent-child- relationship during every rendering cycle of every scene graph, forever. To avoid this, browsers must be hand modified ignore the classes defined by wrapper tags.
  19. Unwrapping/rewrapping required. Implementations that do manually re-optimize the scene graph by collapsing intermediate wrapper classes are no longer compliant with the DOM API for the X3D DTD. Left that way, they will not be able to receive events from the web browser's Document Object Model (DOM) or from a remote/networked SMIL event stream. Thus they would have to further remap DOM events to internal classes, rather than sending them directly in the first place. Rephrase: browsers must rewrap a wrapper API around the unwrapped internal classes to correct mismatches produced from optimizing the performance reduction of wrapper-tag classes
  20. Wrappers are a different scene graph, untested and unverified. Changing the VRML scene graph and corresponding class hierarchy to include nonfunctional wrapper-relationship nodes may well prevent the forthcoming Script Authoring Interface (SAI) from compatibly reconciling Java/ECMAScript JSAI, EAI and DOM APIs. This is because a DTD allows no interpretation variations, it is strict. Thus authors will need different algorithms when traversing wrapped X3D scene graphs. This problem also makes translation of existing scripts into DOM-compatible versions more error prone.
  21. Wrappers for repeating values unnecessary. Allowing wrapper tags to appear multiple times as siblings to preserve a permitted VRML ambiguity is of questionable value, is not a unique capability of wrapper tags, weakens XML type-checking strengths, enables logical errors in content that are otherwise flagged for authors, and provides no difference in the resulting scene graph (since excess-identical-sibling definitions are ignored anyway by VRML 97 rules).
  22. Further testing of implementations is possible. The x3d-draft.dtd is extensible to interoperably permit children tags as an alternative encoding. Such an approach enables further testing of content with respect to wrapper-tag pros and cons, if desired. Demonstrating results is a necessary prerequisite for making an informed, grounded evaluation about DTD alternatives.
  23. Wrappers remain redundant. The fact that the multi-profile X3D DTD is further modifiable to compatibly enable or ignore wrapper tags (as indicated by a simple authoring flag in scenes) is in itself further evidence that the DTD is already complete and correct without needing the addition of wrapper tags.
  24. Wrappers permit writing a context-free parser. Producing a context-free parser (i.e. a special class of finite state machine) is not an identified X3D requirement. Whether or not a formally context-free parser can even parse the full semantic complexities VRML 97 is of questionable merit and has not been demonstrated. Multiple fast and small parsers (e.g. 44K Windows executable, zero bytes when in browser, others available) are already suitable for support of small-footprint core-profile browsers.
  25. Naming collisions threaten extensibility. Having duplicate names like <appearance> <Appearance> prevents generation of uniquely named accessor methods (e.g. getAppearance), setAppearance) for component classes generated from the DTD. Precluding the component interface model precludes implementing extensibility - this wrapper-ambiguity problem must be resolved.

    26. In conclusion:

  26. Overwhelming evidence against wrapper tags without demonstrated counterexamples. The large number of strong technical arguments against wrapper tags, combined with the large number of undemonstrated implementation questions, makes wrapper tag incorporation into the X3D DTD inadvisable and harmful. Failing to make such a major decision, without implementation evidence regarding most of these points, rejects the "implement and evaluate" requirements of the X3D process.