[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]