In the second bullet shouldn't it be the local ID that gets changed. If
the ID of the one being brought is changed, will cause problems in the
original use of the ID. Local author has the much safe ability to
change value of the ID.|
Sock Monkey Consulting, LLC
12408 Kallgren RD NE
Bainbridge Island, WA 98110
Michael Priestley wrote:
OK, Robert talked some sense into me
I now get Eliot's point during the
today that a link into the substructures of a conref'd section (for
is not reliable, if only because it requires that link resolution be
as a second pass, after conref resolution, where many processes may be
resolving both conrefs and links at the same time as part of a
I also get Jeff's point about the
target being preferable to the first target: for example, if I have an
xref to a list item, both in the same document, then I'd want it to
working even after I conref in something between them that introduces a
duplicate id. So in this case, same document=closer.
That said, I still want our
to be predictable, ie the same across processors. But I don't want to
a backwards-incompatible change either, if I can avoid it.
So how about:
- map documents, and individual
SHOULD NOT contain duplicate ids on their elements (note should not,
than must not)
- conrefs that bring in an element
an id that already exists in the conreffing context SHOULD change the
of the element being brought in, to avoid creating a collision (again
should not rather than must not)
That should give a rule similar to
Jeff described in the call today, and makes it recommended but not
Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect
There appears to be serious inconsistency between
what at least I understand
our decisions about addressing elements within maps to be and what the
spec says. In addition, the arch spec as currently drafted is
on this matter.
In particular, we have established that the fragment identifier for
within maps is simply the @id attribute value, e.g. "#sometopicref".
However, the draft arch spec says this under "Map IDs and element
"The id attributes for other elements in map are not of type ID and
required to be unique."
If this statement is true then a fragment identifier consisting of just
element ID is not sufficient to enable reliable addressing of elements
So something has to give. I see the following possible solutions:
A. Define a rule for resolving ambiguous references, e.g. "first
in document order". This probably reflects current behavior of most
B. Require element IDs to be unique within map documents. Note that
of shared elements between topics and maps, it's not possible to
ID attribute for most elements to be of type ID, so this requirement
be validated by processors.
C. Make topicref IDs XML IDs and scope all other element IDs to the
ancestor with a specified @id attribute (or the map element, whichever
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
the most complete but changes current processing and address resolution
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.,
conref from "resource" maps, etc.
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email: firstname.lastname@example.org <mailto:email@example.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> | 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: