[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Conref of topicref to topicref: are relative URIsrewritten?
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]