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=""/></li>
</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=""/></li>
</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