Note that my case is not about subelements: I agree that subelement @ids
are retained.
The case is about conref range: you're referencing 1 or more elements as a
range: the top-level elements in that range do not retain their IDs.
In my example, the conref range is referencing 2 <step> elements, both of
which have @id attributes. If each step was conreffed individually, their
@id attributes would not be retained, even when the referencing step
element does not itself have an @id attribute. So it follows that if both
are referenced as a range, the @id attributes are again not retained.
The difference is that in the individual reference case, the referencing
element can specify an @id attribute and that will be the effective ID of
the resolve result. In the conref range case, there's no way to specify
any @id attributes for the referenced elements.
Cheers,
E.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com
On 12/12/14, 8:56 AM, "Helfinstine, David" <> wrote:
>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
>
>
>-----Original Message-----
>From: [mailto:] 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
>
