[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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]