But Rob's point (I believe) is what if the silly section had
an xref to the note with the id="test"? After conreffing it
into your topic, that xref will now link to something completely
different than the author of the silly section intended.
paul
> -----Original Message-----
> From: Robert D Anderson [mailto:]
> Sent: Tuesday, 2009 August 18 16:30
> To: Rob Frankland
> Cc: dita
> 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 <>
> PM
cc
> dita
<>
>
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
>
> http://dita.xml.org/blog/25
>
>
> Eliot Kimber
> <>
>
>
To
> 07/06/2009 09:27 AM dita
>
<>
>
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: <mailto:>
> 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
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
