Problem With @id Values, This-Topic Fragment IDs, and Conref Range

[Eliot Kimber <ekimber@contrext.com>]

In DITA 1.2 the conref rules are explicit that @id attributes are never
retained for elements used by content reference:

<lq>
The attribute specifications on the resolved element can be drawn from
both the referencing element and the
referenced element, according to the following priority:
1.  All attributes as specified on the referencing element, except for
attributes which specify the value "-dita-useconref-
target". (The term "target" here refers to the referenced element.)
2.  All attributes as specified on the referenced element except:
a.  The id attribute
...
</lq>


The problem is in the context of using conref range: in that case the @id
attributes of the referenced elements are not preserved *and there is no
way to set them* in the referencing element, as opposed to a reference to
a single element, where the referencing element can specify and @id
attribute and that will be the effective ID of the resolved element.

Consider the case where you have a set of sections to be used by crossref:

<task id="x">
 <title>Warehouse of steps</title>
 <taskbody>
   <steps>
    <step id="s1">...</step>
    <step id="s2">
     <cmd>..</cmd>
     <info>Repeat <xref href="#./s1"/></info>
    </step>
 </taskbody>
</task>

And then a conref to both steps:

<task id="using-01">
  <title>Content Topic</title>
  <taskbody>
    <context>You can start with <xref href="#./s1"/>.</p>
    <steps>
     <step><cmd>Do stuff</cmd>
     <step conref="warehouse-01.dita#x/s1"
           conrefend="warehouse-01.dita#x/s2"/>
    </steps>
  </body>
</topic>

In the resolved version of topic "using-01", the two step elements have no
@id attributes, meaning that both the xref in step s2 and the xref in the
using topic will be unresolvable, with no direct way to make them
resolvable.


This is obviously a problem that was in DITA 1.2 and we never caught it.

The only workaround is to not use conref range and to put the same @id
value on each referencing element as on the referenced element.

I can't think of any way to correct this that wouldn't potentially make
things worse, especially in the context of the discussion we just had on
how to resolve the case where a referencing topic and the referenced
content have the same @id value and there is a this-topic fragment
identifier.

Thus, I think we need to add a note to the Conref section that highlights
this case and says that the workaround is to not use conref range or,
where possible, to put an appropriate wrapper around the elements to be
reused and reference that (e.g., div, bodydiv, sectiondiv).

I discovered this in the context of a client's content where they are
using conref range to include sections into a topic want to be able to
generate or author links to those sections. Without IDs my code to
generate links failed (because it expected sections with titles to also
have @id attributes, which they need to have in order to be generally
linkable).

Cheers,

E.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com