RE: [dita] inline elements in dita maps

["Grosso, Paul" <pgrosso@ptc.com>]

Thanks, Erik, this is helpful.

 

I'm just a little confused, though, about both your and Robert's comments about <foreign>. As I posted a little earlier, you can get a simpletable into a map by putting it within note within desc within xref within q within shortdesc within topicmeta.

 

This doesn't seem to have anything to do with <foreign> or <data>. Instead, it appears to have to do with the fact that we allowed a lot more stuff in shortdesc.

 

So I'm not sure how your discussion below of <foreign> relates.

 

Specifically, regarding:

 

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

 

I'm left wondering if an editor tool should support practices for allowing the insertion of simpletable's in maps as I outline above, since this has nothing to do with editing of structured text within <foreign>.

 

paul

 

 

---

From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Monday, 2006 August 14 20:08
To: Grosso, Paul
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] inline elements in dita maps

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