OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Re: Problem With @id Values, This-Topic Fragment IDs, and Conref Range


Which tools currently implement conref range, and what has been their apparent interpretation of the wording? I'd be cautious of any wording change that could invalidate a majority consensus on implementation, just in case a popular interpretation could inform on whether any update is even warranted. Thinking particularly of DITA OT and ditac although there may be others on this road as well. I'm sure Jeremy would have had an opinion.
--
Don

On 12/12/2014 9:14 AM, Eliot Kimber wrote:
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" <dhelfinstine@ptc.com> 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
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=""/></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=""/>.</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



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





--
Don R. Day
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday   Twitter: @donrday
About.me: Don R. Day   Skype: don.r.day<
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot



This email has been checked for viruses by Avast antivirus software.
www.avast.com




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]