[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
There's also option (D), which is the status quo, namely "If IDs are duplicated, behavior is implementation specific." Cheers, E. On 7/7/09 7:51 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote: > On 7/7/09 7:40 AM, "Ogden, Jeff" <jogden@ptc.com> wrote: > >> The statement >> >> The id attributes for other elements in map are not of type ID and are >> not required to be unique. >> >> is wrong or at least incomplete. I should read: >> >> The id attributes for other elements in map are not of type ID and are not >> required to be unique by the DTD or schema, but should be unique within the >> map. > > Note that saying "should" rather than "must" here requires that we define > the behavior in the case where IDs are duplicated. That is, as stated, the > above is my option A, not B. > >> I think this is Eliot's option "B". >> >> I don't think his options "A" or "C" are viable in DITA 1.2, certainly not >> this late in the cycle. >> >> -Jeff >> >> >> -----Original Message----- >> From: Eliot Kimber [mailto:ekimber@reallysi.com] >> Sent: Mon 7/6/2009 9:27 AM >> To: dita >> 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 >> >> > > ---- > 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 > ---- 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]