Dita WikiForwarded by Don Day/Austin/IBM on 08/01/2006 10:03 AM
"Grosso, Paul" <pgrosso@ptc.com> 07/25/2006 04:12 PM
- To
<dita@lists.oasis-open.org> cc Subject RE: [dita] references to ditabases without an explicit topicid
>
Original Message
> From: Esrig, Bruce (Bruce) mailto:esrig@lucent.com > Sent: Friday, 2006 July 21 05:52 > To: 'Robert D Anderson'; Grosso, Paul > Cc: dita@lists.oasis-open.org > Subject: RE: [dita] references to ditabases without an > explicit topicid
After today's telcon, my colleagues and I did some more thinking about DITA references, as there are a variety of places such references can occur.
In all cases--other than a reference without an ID to a ditabase--a DITA reference (file, file#id, file#id1/id2, #id, #id1/id2) currently references a single element.
In the case of a reference without an ID to a ditabase, the reference is either to the single element or to a collection of one or more unnested topics. References to a single element always make sense. References to the <dita> element or multiple unnested elements sometimes make less sense or result in other problems.
In asking how to interpret a reference without a topic ID to a ditabase, we have:
- topicref/@href link/@href xref/@href lq/@href
where a reference to multiple topics could perhaps be made to work by treating the <dita> element as if it were a topic that contains one or more nested topics. The type and navtitle would either be specified on the topicref itself or taken from the first topic in the ditabase. You'd have a single entry in the TOC and all of the content in the output. Not sure you'd want to truly nest the topics in an implied topic as far as numbering goes, but if you don't then the numbering and TOC won't be consistent with some items missing from the TOC but numbered as if they were or at least should be in the TOC. The alternative is to treat the multiple topics as if they had been referenced from multiple topicref, link, or xref elements. That might work. Not sure it is what the user would expect. This latter multiple reference approach doesn't work for lq.
- @conref
where a reference to multiple topics or to a <dita> element never makes sense with a conref.
Therefore, it seems that for references to a ditabase when no id is given, we can make one of the following decisions:
1. Give up on the idea of being completely consistent and allow the
- behavior between conref and other references to be inconsistent with conref referencing the first topic in a ditabase and other references referencing all of the topics in a ditabase.
2. Have such references always reference the first topic.
3. Have such references result in an error when used with anything
- but conref and have them refer to just the first topic for conref.
4. Have such references result in an error when used with conref and
- have them refer to all the topics in the other cases.
5. Have such references result in an error in all cases.
paul