[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?
Good point, I'd forgotten about that case. I think that came up several
months ago, and we decided it was too late in DITA 1.2 to try and resolve
that specific issue, given that implementations likely resolve it
differently today. I know what we do for that particular case, but (as
others often point out) what the OT does is not particularly relevant in
determining what the spec should do.
I'm not sure how that affects the more general case though, in that the (to
me) obvious behavior seems to be technically invalid. Perhaps some wiggle
room around the href attribute, stating that attributes containing relative
URIs may be adjusted as conref is resolved?
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
"Ogden, Jeff"
<jogden@ptc.com>
To
11/09/2009 09:57 "dita" <dita@lists.oasis-open.org>
AM cc
Subject
RE: [dita] Conref of topicref to
topicref: are relative URIs
rewritten?
Does the DITA OT adjust all of the href values within conrefed content or
just the href values on the referenced element?
Does the DITA OT adjust referencing attribute values beyond @href? An
example would be @conref and there are others.
Where does the following case fall in this discussion?
File: t1.dita
<topic id="t1">
...
<p id="p1">Para1 in t1</p>
<p id="p2">
<xref href="#t1/p1" />
...</p>
</topic>
File: t2.dita
<topic id="t2">
...
<p id="p1">Para1 in t2</p>
<p conref="t1.dita#t1/p2" />
...
</topic>
When topic t2 is processed:
1. is the xref in error because the id "t1" doesn't exist in topic
t2?
2. or is the xref a link to p1 in t1?
3. or should the href value be rewritten to give a link to p1 in t2?
All I'm saying is that there are a number of cases to consider once you
start down the road of adjusting things and I worry about approaching this
piecemeal for DITA 1.2 in a rush at the last minute without a formal
proposal and with only a short time for discussion (unless we slip the DITA
1.2 deadlines further and perhaps that is what we should do given all of
the questions that have been raised recently).
-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]