[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Issue: Map element IDs and references to them
But Rob's point (I believe) is what if the silly section had an xref to the note with the id="test"? After conreffing it into your topic, that xref will now link to something completely different than the author of the silly section intended. paul > -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Tuesday, 2009 August 18 16:30 > To: Rob Frankland > Cc: dita > Subject: Re: [dita] Issue: Map element IDs and references to them > > Hi Rob, > > More specifically, the issue is this one - say I have this topic: > <topic id="something"> > <title>Sample topic</title> > <body> > <p id="test">This is a sample</p> > <section conref="othertopic.dita#other/thing"/> > </body> > </topic> > > Now - what happens when the referenced section brings in an element that > has id="test"? If the owner of that other topic randomly adds id="test" to > a note within that section, I should not have to change the ID on my > paragraph in order to make my conref valid - I should be able to reuse > without fear of breaking my own topic. > > So, the second bullet in Michael's note is specifically talking about how > the processors work when that id="test" value gets pulled into the section > in this topic. The suggestion is that, if "test" already exists in this > topic, the ID somehow be mangled so that the original can still work. So, > the result after conref would be something like: > <topic id="something"> > <title>Sample topic</title> > <body> > <p id="test">This is a sample</p> > <section> > <title>This is a silly section</title> > <note id="test-gen1">note that IDs can be a problem</note> > </section> > </body> > </topic> > > Anybody already linking or conref'ing to the id "test" within this topic > will still be safe, and still get the item they expected. > > Does that make sense? > > Robert D Anderson > IBM Authoring Tools Development > Chief Architect, DITA Open Toolkit > > > > Rob Frankland > <robf@sockmonkeyc > onsult.com> To > Michael Priestley > 08/18/2009 05:19 <mpriestl@ca.ibm.com> > PM cc > dita <dita@lists.oasis-open.org> > Subject > Re: [dita] Issue: Map element IDs > and references to them > > > > > > > > > > > In the second bullet shouldn't it be the local ID that gets changed. If the > ID of the one being brought is changed, will cause problems in the original > use of the ID. Local author has the much safe ability to change value of > the ID. > > Rob > > -- > Rob Frankland > Sock Monkey Consulting, LLC > 12408 Kallgren RD NE > Bainbridge Island, WA 98110 > Landline: 206-780-8850 > Cell: 206-963-5541 > > > Michael Priestley wrote: > > OK, Robert talked some sense into me off-line. > > I now get Eliot's point during the call today that a link into the > substructures of a conref'd section (for example) is not reliable, if > only because it requires that link resolution be done as a second > pass, after conref resolution, where many processes may be resolving > both conrefs and links at the same time as part of a > resolve-references pass. > > I also get Jeff's point about the closest target being preferable to > the first target: for example, if I have an xref to a list item, both > in the same document, then I'd want it to continue working even after > I conref in something between them that introduces a duplicate id. > So in this case, same document=closer. > > That said, I still want our behaviors to be predictable, ie the same > across processors. But I don't want to make a backwards-incompatible > change either, if I can avoid it. > > So how about: > > - map documents, and individual topics, SHOULD NOT contain duplicate > ids on their elements (note should not, rather than must not) > - conrefs that bring in an element with an id that already exists in > the conreffing context SHOULD change the id of the element being > brought in, to avoid creating a collision (again note should not > rather than must not) > > That should give a rule similar to what Jeff described in the call > today, and makes it recommended but not required. > > Michael Priestley, Senior Technical Staff Member (STSM) > Lead IBM DITA Architect > mpriestl@ca.ibm.com > http://dita.xml.org/blog/25 > > > Eliot Kimber > <ekimber@reallysi.com> > > To > 07/06/2009 09:27 AM dita > <dita@lists.oasis-open.org> > cc > > Subject > [dita] Issue: Map element > IDs and references to them > > > > > > > > > > > > > There appears to be serious inconsistency between what at least I > understand > our decisions about addressing elements within maps to be and what > the arch > spec says. In addition, the arch spec as currently drafted is > inconsistent > on this matter. > > In particular, we have established that the fragment identifier for > elements > within maps is simply the @id attribute value, e.g. "#sometopicref". > > However, the draft arch spec says this under "Map IDs and element IDs > within > a map": > > "The id attributes for other elements in map are not of type ID and > are not > required to be unique." > > If this statement is true then a fragment identifier consisting of > just the > element ID is not sufficient to enable reliable addressing of > elements > within maps. > > So something has to give. I see the following possible solutions: > > A. Define a rule for resolving ambiguous references, e.g. "first > occurrence > in document order". This probably reflects current behavior of most > implementations. > > B. Require element IDs to be unique within map documents. Note that > because > of shared elements between topics and maps, it's not possible to > declare the > ID attribute for most elements to be of type ID, so this requirement > has to > be validated by processors. > > C. Make topicref IDs XML IDs and scope all other element IDs to the > nearest > ancestor with a specified @id attribute (or the map element, > whichever is > nearer). Allow two-part fragment identifiers. Single-part fragment > identifiers address the first occurrence in document order. > > Option (A) is the simplest to implement but the least complete. > Option C is > the most complete but changes current processing and address > resolution > behavior. > > As for use cases, references to topicrefs is the primary use case for > pointing to elements within maps, but certainly the current spec > doesn't > disallow other references and there could be reasons to, e.g., > data-about, > conref from "resource" maps, etc. > > Cheers, > > Eliot > ---- > Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. > email: ekimber@reallysi.com <mailto:ekimber@reallysi.com> > office: 610.631.6770 | cell: 512.554.9368 > 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 > www.reallysi.com <http://www.reallysi.com> | > http://blog.reallysi.com > <http://blog.reallysi.com> | www.rsuitecms.com > <http://www.rsuitecms.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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]