[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Problem With @id Values, This-Topic Fragment IDs, and Conref Range
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="#./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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]