Public Comment

[comment-form@oasis-open.org]

Comment from: yas.etessam@blastradius.com

As discussed in last weeks meeting, here are some more comments for consideration for the 1.1/2.0 triage.  These are duplicates of Blast Radius' comments sent to the TC list a few weeks ago:

 
<sthead>
  <stentry>Issue number</stentry> 
  <stentry>Formal "component" or "fragment" element specially designed as source content for CONREF.  Determine DITA best practice re-use via fragment files.  DITA re-use presupposes that the re-usable components are part of a larger topic document.  One implementation method uses the "required-cleanup" element (which allows any type of content).   Is there a need for a formal "component" or "fragment" element or group of elements that are designed specifically as source content for conrefs?  </stentry>
  <stentry>Enhancement, or possibly "best practice" if using the "required-cleanup" element is the right way to solve this problem.</stentry> 
  <stentry>Keep?</stentry> <!-- record our first "triage" cut -->
  <stentry>Rank</stentry> <!-- record our second pass prioritization --> </sthead>

<sthead>
  <stentry>Issue number</stentry> 
  <stentry>Side-by-side implementation of xml:id?   Id attributes use type "ID"  for certain elements and type "NMTOKEN" for others; this is by design in DITA 1.0.  This avoids naming collisions when aggregating topics but lack of unique ids could still  lead to problems.  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. </stentry>
  <stentry>Design</stentry>   
  <stentry>Keep?</stentry>
  <stentry>Rank</stentry></sthead>

<sthead>
  <stentry>Issue number</stentry> 
  <stentry>Should <refsyn> be moved to a domain, e.g. Programming or Software?</stentry>
  <stentry></stentry>   
  <stentry>Keep?</stentry>
  <stentry>Rank</stentry></sthead>
 
In addition to the above unique comments, we've got duplicate comments regarding:

A.  Need to use W3C standard based addressing for conref. Seems to be closely related to Eliot Kimber's comment regarding Xinclude.


B.  For maps, consider providing optional title elements instead of storing title information in the navtitle attribute. Looks like duplicate of Michael Priestley's comment regarding "free text" in attributes should be replaced by elements.