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

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>

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

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.

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.

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.

-Jeff

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

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

> Sent: Saturday, November 07, 2009 7:19 AM

> To: dita

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

> rewritten?

> Given a root map and a subordinate map in a subdirectory under the root

> map,

> where the subordinate map contains a topicref that specifies @href to a

> topic, e.g., in the sub map:

> <topicref id="tr-01"

> href=""../topics/topic-01.dita"

> processsing-role="resource-only"

> />

> In the root map you then conref the topicref in the sub map:

> <topicref

> conref="submaps/submap-01.ditamap#tr-01"

> />

> What is the effective value of the @href after conref resolution?

> A. "../topics/topic-01.dita"

> B. "topics/topic-01.dita"?

> Obviously, answer (A) is the wrong answer from a "it should work"

> standpoint, since, in the context of the root map, the URL doesn't

> point to

> a resource (or it points to a different topic-01.dita than the one

> pointed

> to by the sub map).

> In my tests, the 1.5 M22 Toolkit does the right thing, in that it

> rewrites

> the value of the href so it reflects the location of the resolved

> topicref,

> not the location of the referenced topicref.

> I think this behavior needs to be required by the spec, but the current

> language for attribute merging doesn't mention rewriting of pointers.

> I think the language would be something like:

> "When the referenced element specifies @href and the attribute is the

> effective version of the @href attribute after attribute merging, if

> the

> value of the @href attribute is a relative URI reference, the value

> must be

> rewritten to reflect the relative location of @href attribute following

> content reference resolution."

> And then give the example above.

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

> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail. Follow this link to all your TCs in OASIS at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

dita message