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

["Helfinstine, David" <dhelfinstine@ptc.com>]

Greetings,

That is not the way I have ever read the DITA 1.2 spec. The DITA 1.2 spec says that the referenced element will not preserve the id, but will keep the id of the referencing element. This does NOT apply to subelements at all. Note that it says referenced element, singular, not plural. Subelements are not subject to that rule as I have ever read that.

In your example the subelements would retain their ids.

If you want to use the same id as the conrefed element, then you would also have to supply that on the conref element. That usually is not an issue as you usually want to use your own id, which I think is why the rule is there.

Hope this helps. 

-Dave H.

Dave Helfinstine
dhelfinstine@ptc.com

-----Original Message-----
From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Eliot Kimber
Sent: Friday, December 12, 2014 6:59 AM
To: dita
Subject: [dita] Problem With @id Values, This-Topic Fragment IDs, and Conref Range

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




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