[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
Paul got my point exactly. This is really difficult, you cannot assure
that an ID is unique and any fix will almost assuredly make a bad
reference now or in the future. The crux of the matter is that
currently DITA encourages reuse of this type without any way to check
validity before processing - correct? Rob Grosso, Paul wrote: CF83BAA719FD2C439D25CBB1C9D1D3021089C743@HQ-MAIL4.ptcnet.ptc.com" type="cite">-----Original Message----- From: Robert D Anderson [mailto:robander@us.ibm.com] Sent: Tuesday, 2009 August 18 17:00 To: Grosso, Paul Cc: dita Subject: RE: [dita] Issue: Map element IDs and references to them Possibly - but to get the inside-section link to work, additional work would still be required. Unless your topic IDs are all identical --you'llhave this section: <section id="thing"> <title>This is a silly section</title> <note id="test">note that IDs can be a problem</note> <p>Look at that note: <xref href="#other/test"/> </section> If that is pulled unchanged into another topic with no modification,youwill end up with a reference to "#other/test" ... meaning you willmostlikely have a broken link, because the new topic doesn't haveid="other". Right, but that's a problem we already know we need to fix (and we know how to fix it); see DITA 1.3 proposal 13001 at http://wiki.oasis-open.org/dita/DITA_1.3_ProposalsIf the referencing topic, as in the sample below, has id="something",andthe target topic has id="other", then for the link to remain valid asalink, you'll have to do one of these: 1) Change the value to #other/test -- but if "test" is now duplicated,youhave the problem we've been trying to resolve. 2) Change the value to point to the original target - othertopic.dita#other/test - but this takes you out of the file, whichI'dguess is never the desired or expected result 3) Change the note to "test-gen1" and change the reference to "#something/test-gen1" - this is what my code does now, because (tome) itseemed closest to the author's and reader's intent. That is, withinthatblock, the link stays valid and it stays local to that block.Once we've implemented proposal 13001, you won't have to do anything if the referencing topic doesn't have id="test" anywhere--and having to do nothing to make this work is as it should be. If the referencing topic does have id="test", that's the problem we're discussing where Rob suggests having some kind of "fixup" of the ids in the referencing document instead of in the referenced document. Not that that's necessarily the best solution either. Which is why it isn't clear we should be defining a particular solution for DITA 1.2. Whether Michael's "shoulds" are optional enough to be acceptable is open for question. RFC 2119 says SHOULD means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." I'm not sure we, ourselves, understand the full implications yet.My view on that is - if one of my other topics links to "test" withintopic"something", then I have created that link because I want to go to the element I've defined in there with id="test". Likewise, if somebodyelsehas linked to "test" within my topic, then they're linking to theelementthat actually exists there with id="test". I also want that link to be reliable, regardless of what other IDs people add within section I'm reusing. If we go the other way, we also run in to the equivalent problem overintopic "other". What happens when we have this, and the conref pulls inaphrase with id="test": <section id="thing"> <title>This is a silly section</title> <note id="test">note that IDs can be a problem</note> <p>Look at that note: <xref href="#other/test"/> <p conref="a.dita#nother/thing"/> </section> If we have to modify the original, then the local xref is brokenbecause itnow goes to a phrase instead of the note.Right, id fixup--regardless of where you do it--always implies fixing up both ids and idrefs. This is not an easy issue--which is why I don't think we should be defining specific processing for DITA 1.2. This will take a lot more thought; we should tackle this much more deliberately in DITA 1.3. paulThoughts? Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit "Grosso, Paul" <pgrosso@ptc.com>To08/18/2009 05:34 "dita"<dita@lists.oasis-open.org>PMccSubjectRE: [dita] Issue: Map elementIDsand 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 elementthathas id="test"? If the owner of that other topic randomly addsid="test" toa 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 toreusewithout fear of breaking my own topic. So, the second bullet in Michael's note is specifically talkingabouthowthe processors work when that id="test" value gets pulled into thesectionin this topic. The suggestion is that, if "test" already exists inthistopic, the ID somehow be mangled so that the original can stillwork.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 thistopicwill 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>ToMichael Priestley 08/18/2009 05:19 <mpriestl@ca.ibm.com> PMccdita<dita@lists.oasis-open.org>SubjectRe: [dita] Issue: Map elementIDsand references to them In the second bullet shouldn't it be the local ID that gets changed.If theID of the one being brought is changed, will cause problems in theoriginaluse of the ID. Local author has the much safe ability to changevalueofthe 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 intothesubstructures of a conref'd section (for example) is notreliable, ifonly because it requires that link resolution be done as asecondpass, after conref resolution, where many processes may beresolvingboth conrefs and links at the same time as part of a resolve-references pass. I also get Jeff's point about the closest target beingpreferable tothe first target: for example, if I have an xref to a listitem,bothin the same document, then I'd want it to continue workingevenafterI conref in something between them that introduces a duplicateid.So in this case, same document=closer. That said, I still want our behaviors to be predictable, iethesameacross processors. But I don't want to make abackwards-incompatiblechange either, if I can avoid it. So how about: - map documents, and individual topics, SHOULD NOT containduplicateids on their elements (note should not, rather than must not) - conrefs that bring in an element with an id that alreadyexists inthe conreffing context SHOULD change the id of the elementbeingbrought in, to avoid creating a collision (again note shouldnotrather than must not) That should give a rule similar to what Jeff described in thecalltoday, 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>To07/06/2009 09:27 AM dita<dita@lists.oasis-open.org>ccSubject[dita] Issue: MapelementIDs and references tothemThere appears to be serious inconsistency between what atleastIunderstand our decisions about addressing elements within maps to be andwhatthe arch spec says. In addition, the arch spec as currently drafted is inconsistent on this matter. In particular, we have established that the fragmentidentifierforelements within maps is simply the @id attribute value, e.g."#sometopicref".However, the draft arch spec says this under "Map IDs andelement IDswithin a map": "The id attributes for other elements in map are not of typeIDandare not required to be unique." If this statement is true then a fragment identifierconsistingofjust the element ID is not sufficient to enable reliable addressing of elements within maps. So something has to give. I see the following possiblesolutions:A. Define a rule for resolving ambiguous references, e.g."firstoccurrence in document order". This probably reflects current behavior ofmostimplementations. B. Require element IDs to be unique within map documents. Notethatbecause of shared elements between topics and maps, it's not possibletodeclare the ID attribute for most elements to be of type ID, so thisrequirementhas to be validated by processors. C. Make topicref IDs XML IDs and scope all other element IDstothenearest ancestor with a specified @id attribute (or the map element, whichever is nearer). Allow two-part fragment identifiers. Single-partfragmentidentifiers address the first occurrence in document order. Option (A) is the simplest to implement but the leastcomplete.Option C is the most complete but changes current processing and address resolution behavior. As for use cases, references to topicrefs is the primary usecase forpointing to elements within maps, but certainly the currentspecdoesn'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 OASISTCthatgenerates this mail. Follow this link to all your TCs inOASISat: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--------------------------------------------------------------------- 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 -- Rob Frankland Sock Monkey Consulting, LLC 12408 Kallgren RD NE Bainbridge Island, WA 98110 Landline: 206-780-8850 Cell: 206-963-5541 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]