[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
Hi Rob,
More specifically, the issue is this one - say I have this topic:
<topic id="something">
<title>Sample topic</title>
<body>
<p id="test">This is a sample</p>
<section conref="othertopic.dita#other/thing"/>
</body>
</topic>
Now - what happens when the referenced section brings in an element that
has id="test"? If the owner of that other topic randomly adds id="test" to
a note within that section, I should not have to change the ID on my
paragraph in order to make my conref valid - I should be able to reuse
without fear of breaking my own topic.
So, the second bullet in Michael's note is specifically talking about how
the processors work when that id="test" value gets pulled into the section
in this topic. The suggestion is that, if "test" already exists in this
topic, the ID somehow be mangled so that the original can still work. So,
the result after conref would be something like:
<topic id="something">
<title>Sample topic</title>
<body>
<p id="test">This is a sample</p>
<section>
<title>This is a silly section</title>
<note id="test-gen1">note that IDs can be a problem</note>
</section>
</body>
</topic>
Anybody already linking or conref'ing to the id "test" within this topic
will still be safe, and still get the item they expected.
Does that make sense?
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
Rob Frankland
<robf@sockmonkeyc
onsult.com> To
Michael Priestley
08/18/2009 05:19 <mpriestl@ca.ibm.com>
PM cc
dita <dita@lists.oasis-open.org>
Subject
Re: [dita] Issue: Map element IDs
and references to them
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.
Rob
--
Rob Frankland
Sock Monkey Consulting, LLC
12408 Kallgren RD NE
Bainbridge Island, WA 98110
Landline: 206-780-8850
Cell: 206-963-5541
Michael Priestley wrote:
OK, Robert talked some sense into me off-line.
I now get Eliot's point during the call today that a link into the
substructures of a conref'd section (for example) is not reliable, if
only because it requires that link resolution be done 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
resolve-references pass.
I also get Jeff's point about the closest 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 continue 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 behaviors to be predictable, ie the same
across processors. But I don't want to make a backwards-incompatible
change either, if I can avoid it.
So how about:
- map documents, and individual topics, SHOULD NOT contain duplicate
ids on their elements (note should not, rather than must not)
- conrefs that bring in an element with an id that already exists in
the conreffing context SHOULD change the id of the element being
brought in, to avoid creating a collision (again note should not
rather than must not)
That should give a rule similar to what Jeff described in the call
today, and makes it recommended but not required.
Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
Eliot Kimber
<ekimber@reallysi.com>
To
07/06/2009 09:27 AM dita
<dita@lists.oasis-open.org>
cc
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]