RE: [dita] inline elements in dita maps

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:] 
  
Sent: Monday, 2006 August 14 20:08
To: Grosso, 
  Paul
Cc: 
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