OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
Back to discussions
Expand all | Collapse all

Clarification needed wrt nested references from maps to maps to topics

  • 1.  Clarification needed wrt nested references from maps to maps to topics

    Posted 05-15-2007 12:51 
    I think the DITA TC still needs to make some decisions to
clarify in the DITA 1.2 spec certain issues on topic references.

Don asked that I send this to the list for 1.2 consideration.

Consider a case such as the following:

     Bookmap
        Part to map

     Map
       Topicref to topic1
          Topicref to topic2
       Topicref to topic3

It seems the above should result in:

     Part (topic1)
         Topicref (topic2)
     Part (topic3)

What's still not clear is what happens to topicrefs or 
specializations other than the top level topicrefs in the 
referenced maps (topicref to topic2 in the example).  I
believe we need to clarify what happens to the 2nd and 
deeper levels.

Here are some other questions that don't seem answered
by the latest spec:

1. If there is a topicref within a part in a bookmap that 
   references another bookmap that includes a chapter at 
   the top level, is the chapter changed into a topicref 
   or does the chapter remain a chapter because we only make
   changes for specialized topicref elements?   

2. If someone references a map from a part in a bookmap and
   the map has a single top level topicref and several lower
   level topicrefs nested within the top level topicref,
   the top level topicref becomes a part.  What, if anything,
   do the nested topicrefs become?  chapters?  Or do they
   just remain topicrefs?  Can a high level map author override
   the element type for just the top level element or is there
   a way to override the type of nested elements as well?           

3. Again regarding referencing a map, what do we do when the
   referenced map content is out of context after it has been
   referenced from a higher level map no matter what element
   type changes we do. Our choices would seem to be
     (i) put the burden on the map author and if they produce
     something that doesn't make sense, produce an error message;
     (ii) provide rules for how we'll implicitly change element
     types based on the map coding and the context so that things
     remain legal; 
     (iii) some combination of (i) and (ii) that would change
     common cases and treat the rest as errors, or;
     (iv) leave this up to the implementation.  

paul


Related Content