OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Review #2 comment: Handling xrefs and conrefs within a conref


Test in question:

"When referenced content contains a content reference or cross reference, the effective target of the reference depends on the form of address that is used in the referenced content.

  • When the address used is a direct URI reference of any form other than a same-topic fragment identifier, processors MUST resolve it relative to the referenced content in its source location.
  • When the address is a same-topic fragment identifier or a key reference, processors MUST resolve it relative to the location of the content reference.
This means that the same content reference or cross reference can resolve to different targets in different use contexts because "same topic" references resolve to the topic containing the reference and key references are resolved in the context of the key scope in effect for each use of the topic containing the reference. In the case of "same topic" fragment identifiers, it is the responsibility of the author of the content reference to ensure that any element IDs specified in same-topic fragment identifiers in the referenced content are either in the referenced content or provided by elements in the referencing topic."


[Eliot Kimber]
There is also the use case of conref of content where the references are to IDs within the referenced content and referenced by a this-topic fragment ID and the referencing context also has an element with the same ID. What should the processor do in that case?

Options include:

A. Resolve to the first instance of the ID following conref resolution and report the duplicate ID. This is the current behavior for duplicate IDs generally.

B. Rewrite the IDs and references in the conreffed content so that the link resolves in the use context as it did in the source context.

Option A is reasonable but option B makes content more reusable when the re-used content is otherwise self contained. I would like to propose making option B required but I doubt the TC would be willing to impose that processing requirement at this point.

[Robert Anderson]

OK, I've got that use case clear in my mind, using an actual example here to clarify. Use case is something like this being reused:
<ol id="reuse">
? <li id="first">blahblah</li>
? <li>See <xref href=""/></li>

In the new topic, id="first" already exists before the conref. So, in the new topic that pulls in the list above, does "#./first" resolve to the "first" that existed already in the topic, or to the list item that's pulled in with the conref?


Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
+1 919 682-2290; kriseberlein (skype)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]