OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: conref.dita editorial review


I have committed the overview topic titled "Use by reference" to SVN as a revision of conref.dita.
 
Four items need particular attention. They are indicated in XML comments.
 
1. The question after the following paragraph:
 
      If the referenced element has a conref attribute specified, the
      above rules should be applied recursively with the resolved element
      from one  referencing/referenced combination becoming  one of the
      two  elements participating in  the next referencing/referenced
      combination. The result should preserve without generalization all
      elements that are valid in the originating context, even if they
      are not valid in an intermediate context. For example, if topicA
      and topicC allow highlighting, and topicB does not, then a content
      reference chain of topicA>topicB->topicC should preserve any
      highlighting elements in the referenced content. The result is the
      same as if the conref pairs are resolved recursively starting from
      the referencing element.
      <!--What do you mean "as if"? There's been no mention of the
      converse. Should this say "the result is the same whether the
      recursive resolution of conref pairs starts from the referencing
      element or from the referenced element"?-->
 
2. The question embedded within the following paragraph:

      A key is bound to the resource addressed by the topicref or keyref
      in which it is defined, if it is provided.
      <!--What happens if  none is provided? It can't be resolved? -->
      The resource to which a key is bound may be a DITA map or topic, or it
      may be a non-DITA resource such as a graphic or an object specified
      by an external URI.
 
3. After the last of the related-links items, a note that I was unable to make a link that would take the reader appropriately to the submap because of my uncertainty about the organization of the content:
 
      <linktext
      conref="../common/complexattributedefinitions.dita">Complex
      attribute definitions</linktext>
      <!--Need to make link to this submap rather than to this stub topic.-->
 
4. Should there be changes to related-links reflecting Eliot's reorganization of linking and addressing?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]