Re: [dita] Issue: Map element IDs and references to them

[Eliot Kimber <ekimber@reallysi.com>]

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>