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" <> wrote:
> On 7/7/09 7:40 AM, "Ogden, Jeff" <> 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:]
>> 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: <mailto:>
>> 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: <mailto:>
> 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: <mailto:>
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>
