[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
The OT behaves as I describe: @ids are not preserved. Note I'm not suggesting any wording change or change to the rules, just an additional note highlighting this specific case and the workarounds. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 12/12/14, 10:19 AM, "Don R. Day" <donday@donrday.com> wrote: > > > > > > 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> ><mailto: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 > > > > >--------------------------------------------------------------------- >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 <mailto:donday@donrday.com> > Founding Chair, OASIS > DITA Technical Committee ><http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita> > LinkedIn: donrday <http://www.linkedin.com/in/donrday> Twitter: > @donrday <http://twitter.com/in/donrday> > About.me: Don R. Day <http://about.me/donrday> 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 > > > > > >________________________________________ > > > > > <http://www.avast.com/> > > > > This email has been checked for viruses by Avast antivirus software. > >www.avast.com <http://www.avast.com/> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]