Greetings,
The intent of the Same topic reference addition to DITA 1.3 is Option 1. There was a lot of discussion about this and verbiage in the proposal to show exactly
the case below.
Note that If the <li> in Topic B:
<li>See <xref href= >
Is changed to:
<li>See <xref href= >
Then the xref would reference topic-b.dita#concept/first
The two are treated differently.
Thanks.
-Dave H.
Dave Helfinstine
dhelfinstine@ptc.com From:
dita@lists.oasis-open.org [mailto:
dita@lists.oasis-open.org]
On Behalf Of Kristen James Eberlein
Sent: Wednesday, December 10, 2014 10:34 AM
To:
dita@lists.oasis-open.org Subject: Re: [dita] Review #2 comment: Handling xrefs and conrefs within a conref
I want to elaborate on the example that Robert provided:
Topic A contains the following content:
<concept id="concept">
<title>My topic</title>
<conbody>
<p id="first">First paragraph</p>
<ul conref="topic-b.dita#1/reuse">
<li/>
</ul>
</conbody>
</concept>
Topic B contains the following content:
<concept id="concept">
<title>My topic</title>
<conbody>
<ul id="reuse">
<li id="first">Blah blah</li>
<li>See <xref href= >
</ul>
</conbody>
</concept>
The question is what is the effective content of topic A after conref and xref resolution?
Option #1
The cross reference resolves to the first instance of an element with id="first"; processors should report that the topic contains a duplicate value for the @id attribute.
<concept id="concept">
<title>My topic</title>
<conbody>
<p id="first">First paragraph</p>
<ul id="reuse">
<li id="first">Blah blah</li>
<li>See First Paragraph </li>
</ul>
</conbody>
</concept>
Option #2
The cross reference resolves to the first element with id="first" within the conrefed element . Either processors report the duplicate ID or rewrite the ID within the reused unordered list.
<concept id="concept">
<title>My topic</title>
<conbody>
<p id="first">First paragraph</p>
<ul id="reuse">
<li id="first">Blah blah</li>
<li>See Blah blah </li>
</ul>
</conbody>
</concept>
Given the current normative language in the draft 1.3 spec (quoted below), I think that the correct decision is option #1.
"When the address is a same-topic fragment identifier ...processors MUST resolve it relative to the location of the content reference."
I agree with Eliot that option #2, especially with having processors rewrite the value of the @id attribute in the conrefed <ul>, would improve content reuse -- but I think that we need to 1) Avoid changing content of approved DITA 1.3 proposals, and 2) Avoid
imposing additional processing requirements.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype)
On 12/8/2014 11:24 AM, Kristen James Eberlein wrote:
DITAweb URL:
https://ditaweb.com/oasis-dita/#/00074601-DA$00073575-DB$Handling%20xrefs%20and%20conrefs%20within%20a%20conref 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."
Comments:
[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= >
</ol>
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?
--
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype)
--------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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