OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]