RE: [dita] inline elements in dita maps

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Paul:

Regarding:

> Did we know we were doing this, or was this an unintended consequence of other decisions.

As Robert pointed out, the TC did discuss the potential for tag abuse with the <foreign> element. We decided that the benefits of extensible inclusion of standard vocabularies like LOM, MathML, SVG, XForms, ChemML, ebXML, and so on outweighed the risks.

Ideally, we would constrain the <foreign> element to exclude every DITA element (and specialization) except fallbacks like <desc>, <object>, <image>, and <foreign> while allowing any non-DITA element. The write-up:

http://www.oasis-open.org/apps/org/workgroup/dita/download.php/19115/IssueNumber35.htm

For that reason, it would seem a waste of investment for an editor tool to support practices that the scheme would exclude if possible -- for instance, editing of structured text within <foreign>. Instead, I would think that an editor tool might do better to concentrate on functions like:

• Separate panes for a treeview of the topicref hierarchy and for the properties of a selected node within the tree.
• A property editor that can handle not only attributes but <data> structures.
• A pane or dialog for editing a <foreign> object as raw XML -- whether in a map or topic context.
• Pluggability of pane or property editing for the instances of a specialized <foreign> element -- possibly even extra-cost plugins for key standard vocabularies.
• A consistent pane or dialog for editing one <object> and its <desc> -- whether as a value within a property structure or at a position within a discourse flow.

To provide more precise definitions in the future, maybe we need a formal definition of DITA constraints that isn't limited to the validation capabilities of the least capable schema language.  (Not just with <foreign> but with a single <title> element at the start of <section> and so on.)  


Erik Hennum
ehennum@us.ibm.com