Re: [dita] Conref of topicref to topicref: are relative URIsrewritten?

[ekimber <ekimber@reallysi.com>]

On 11/8/09 7:59 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> Isn't this just a specific example of the same problem that comes up in
> many contexts with conref?  For example using the same setup as in the
> original example, but with somewhat more content:

>   <topicref id="tr-01" href="../topics/topic-01.dita" >
>       <topicref href="../topics/topic-01.dita" />
>   </topicref>

> If tr-01 is conrefed, should the two @href values reference to the same
> file or not?

Good question--unless all the pointers are rewritten, the conreffed result
will be broken. 

> I assume that the presence or absence of processing-role="resource-only"
> doesn't make any difference here, but if I've missed something, please
> let me know.

It doesn't--that only controls whether or not the topic referenced is
included in the navigation hierarchy by the topicref--it wouldn't affect the
result of conreffing that topicref into another context.

> Unless I've misunderstood something, I just don't think that this is an
> issue that we can take on at this late stage of the DITA 1.2 cycle.

That's for the TC to decide. I'm simply raising the issue as a place in the
spec where essential behavior is underspecified and strict reading of the
spec will result in non-working results.

Are there any vendors who implement @conref who *don't* do what the Toolkit
does? If so, then we have an interoperation problem. If not, then we can
probably safely codify the Toolkit behavior by adding a specific statement
about @href.

> Note that if this were a key definition (it isn't), then the answer
> would be clear because the draft DITA 1.2 specification says:
> 
> A relative URI in an href attribute on a key definition is resolved
> relative to the location of the key definition rather than relative to
> the location of the key reference.

This is sensible because @keyref is not content reference but indirection.
That is, for a topicref that points to another topicref by @keyref, you're
not transcluding the referenced topicref, but simply indirecting through it.
So the effective location of the topicref that specifies @href isn't
changed.

With @conref, the location *is* changed, because content reference changes
the effective value of the *reference* and the current rules as stated, if
interpreted strictly, mean that the Toolkit's behavior is *non conforming*.

Cheers,

Eliot

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>