List of 1.1/2.0 considerations

["Yas Etessam" <yas.etessam@blastradius.com>]

As the TC puts together the list of 1.1 requirements, here are some issues that came up during our review of DITA 1.0.  

#1.  DITA re-use via fragment files.  DITA re-use presupposes that the re-usable components are part of a larger DITA document.  Our customer wants to store fragments of re-suable components within one large DITA file.
This was implemented using the "required-cleanup" element (which allows any type of content).  We considered this to be a hack.  One option is to specialize "required-cleanup" to create an element specifically for DITA re-usable fragments.  Is there a need for a formal "component" or "fragment" element or group of elements that are designed specifically as source content for conrefs without having to be part of a larger DITA topic?  

#2.   Conref's addressing mechanism isn't based on a  W3C standard XML addressing mechanism.     Would the TC consider having a discussion on this subject and asking whether there should be some consideration to moving to a standards-based addressing mechanism in the next time frame?
 
#3.   The fact that element id attributes use type "ID"  for certain elements and type "NMTOKEN" for others is by design in DITA 1.0.  The stated rationale is that this avoids naming collisions when aggregating topics.   This lack of unique ids could still  lead to problems because as a document could contain more than one element with the same "id"  NMTOKEN.   Due to the data model,  validating parsers will not catch this condition, even though this may break xrefs or possibly conrefs.    Would the TC consider having a discussion about enforcing uniqueness?  Paul Prescod advocated looking at possibly offering a side-by-side implementation of xml:id in the 1.1/2.0 timeframe.   

#4.  Should <refsyn> be moved to a domain, e.g. Programming or Software?  

#5.  For maps, consider providing optional title elements instead of storing title information in the navtitle attribute.  This particular issue is a "nice to have" as most software vendors can provide an interface to editing attributes. However, it would be more consistent with the main DITA topics where titles are stored as elements rather than attributes.


Regards,

Yas Etessam

yas@blastradius.com
www.xmetal.com