|Subject:||RE: [dita] references to ditabases without an explicit topicid|
|From:||Grosso, Paul (pgro...@ptc.com)|
|Date:||Aug 8, 2006 10:35:10 am|
-----Original Message----- From: Robert D Anderson [mailto:roba...@us.ibm.com] Sent: Thursday, 2006 July 20 17:02 To: Grosso, Paul Cc: di...@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.