RE: [dita] Conref of topicref to topicref: are relative URIs rewritten?

Eliot asked:

> Are there any vendors who implement @conref who *don't* do what the Toolkit does?

Arbortext Editor probably gets the same result as the Toolkit, but not in the same way. Arbortext Editor uses a path list to resolve relative references. For DITA linking elements (conref, xref, link, topicref, …) it is the ditapath list. For graphic referendes (image) it is the graphicspath list. The list usually consists of:

1. the base URI for the referencing element (for conrefed elements this is the directory for the document that contains the referenced element)

2. the document directory for the referencing element, if this is different from the base URI

3. zero or more additional paths to directories

We look for the referenced file starting with the first location on the list and work our way down the list until we find the file or we run out of locations to check.

Users can change what is on the list or the order of the paths on the list.

So in Eliot’s example, we’d get the same result as the OT, if the file exists at that location. If the file doesn’t exist at that location, we might be able to continue if the file exists at one of several other locations. Otherwise we report an error.

This approach avoids the issue that Eliot raised without having to “rewrite URIs”. It works for a relative href on the referenced element and for relative href values on markup within the referenced element.

-Jeff

> -----Original Message-----

> From: ekimber [mailto:ekimber@reallysi.com]

> Sent: Monday, November 09, 2009 8:53 AM

> To: Ogden, Jeff; dita

> Subject: Re: [dita] Conref of topicref to topicref: are relative URIs

> rewritten?

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

dita message