[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
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]