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

[Eliot Kimber <ekimber@reallysi.com>]

On 8/18/09 2:35 PM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> - 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)

I think this is good. I agree with Michael that predictable is good, even if
the result is not what you might have wanted it to be--at least you can
predict what it will be.

In some future release we need to think about ways to address things through
use contexts. This is essentially the same issue I raised in another thread
about being able to address through keyrefs to peer maps.

That is, given that you conref element "conreffed-01" into a topic and you'd
like the author a link to the conreffed element, you need to specify both
the conref context (that is, the element making the conref) and the
location, *as authored* of the target element.

Given that information the address is completely unambiguous and a processor
can reliably rewrite both IDs and pointers so the address is still correct
following conref resolution or output processing.

But that's definitely for 1.3 or 2.x. I suspect this is a very much an edge
case in practice.

Cheers,

E.

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