RE: [dita] references to ditabases without an explicit topicid

["Grosso, Paul" <pgrosso@ptc.com>]

> -----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