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: RE: [dita] references to ditabases without an explicit topicid



> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com] 
> Sent: Thursday, 2006 July 20 17:02
> To: Grosso, Paul
> Cc: dita@lists.oasis-open.org
> Subject: RE: [dita] references to ditabases without an 
> explicit topicid
> 
> As nobody else seems inclined to respond...
> 
> My personal expectation would be that if I reference a file 
> in the map, I
> expect that the whole file will show up in the XHTML / PDF / 
> etc unless I
> say otherwise. I think it would be a shock to reference a 
> DITA combination
> file, and find only the first topic in my output.

I tend to agree.  But we need to think beyond just topicrefs.

In all cases a DITA reference (file, file#id, file#id1/id2, #id, 
#id1/id2) other than a reference without an ID to a ditabase,  
is a reference to a single element. In the case of a reference 
without an ID to a ditabase, the reference is either to the 
single element <dita> 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.

Consider the following referencing attributes:

topicref/@href
link/@href
xref/@href
lq/@href

A reference to multiple topics can probably 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.

Now consider @conref:

A reference to multiple topics or to a <dita> element never 
makes sense with a conref.

So, it seems that for references to a ditabase when no id is 
given, we have the following choices:

1. Give up on the idea of being completely consistent and allow
   the behavior for conref versus other references to differ
   with conref referencing the first topic in a ditabase and
   other references referencing all of the topics in a ditabase.

2. Have all such references always reference the first topic.

3. Have all such references result in an error when used with
   anything but conref.

4. Have all such references result in an error when used with
   conref.

5. Have all such references result in an error in all cases.

Now whenever you make something an error, you open to door 
to annoying the user which in turn opens the door for an 
implementor to "recover from the error" by doing what the 
user would want anyway, which leads to loss of interoperability
and defacto "standard" behavior, so I really hate making something 
an error if there is a more user friendly thing to do.

I think that referencing an entire file with multiple topics 
and having this refer only to the first topic is ambiguous, 
confusing, and redundant (because if you want just the first 
topic, you can always use the id).

That leaves us with choice #1.  I don't mind the slight loss
in "consistency", so I think we should figure out what makes
the most sense in each of the above enumerated cases and make
it clear in the spec what happens in each case.

It sounds like we want topicref/@href to pick up the entire
ditabase--though there are questions (see above) about just
what this means--and we know @conref can only refer to a single
element.  I can live with any decision for

link/@href
xref/@href
lq/@href

but we need to make our decisions clear in the spec.

paul


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