OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [dita] Review #2 comment: Handling xrefs and conrefs within a conref


In thinking about this case more deeply, I agree with David that option
(1) is the better solution: any other rule I can think of would require
pretty complicated processing and would complicate or make impossible
control of IDs in referencing topic.

Essentially, in this case, it's up to the authors of the topics to
carefully manage their IDs to avoid conflicts. Because of the way
key-based ID references work, it's already the case that IDs have to be
carefully managed, so I don't think this materially changes the level of
care required by authors.

Cheers,

E.

—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 12/10/14, 11:02 AM, "Helfinstine, David" <dhelfinstine@ptc.com> wrote:

>Greetings,
> 
>The intent of the Same topic reference addition to DITA 1.3 is Option 1.
>There was a lot of discussion about this and verbiage in the proposal to
>show exactly
> the case below.
> 
>Note that If the <li> in Topic B:
>   <li>See <xref href="#./first"/></li>
>
>
>Is changed to:
>   <li>See <xref href="#concept/first"/></li>
>
>
>Then the xref would reference  topic-b.dita#concept/first
> 
>The two are treated differently.
> 
>Thanks.
> 
>-Dave H.
> 
>Dave Helfinstine
>dhelfinstine@ptc.com
>
> 
>From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org]
>On Behalf Of Kristen James Eberlein
>Sent: Wednesday, December 10, 2014 10:34 AM
>To: dita@lists.oasis-open.org
>Subject: Re: [dita] Review #2 comment: Handling xrefs and conrefs within
>a conref
>
>
> 
>I want to elaborate on the example that Robert provided:
>
>Topic A contains the following content:
>
><concept id="concept">
> <title>My topic</title>
> <conbody>
>  <p id="first">First paragraph</p>
>  <ul conref="topic-b.dita#1/reuse">
>   <li/>
>  </ul>
> </conbody>
></concept>
>
>Topic B contains the following content:
>
><concept id="concept">
> <title>My topic</title>
> <conbody>
>  <ul id="reuse">
>   <li id="first">Blah blah</li>
>   <li>See <xref href="#.first"/></li>
>  </ul>
> </conbody>
></concept>
>
>The question is what is the effective content of topic A after conref and
>xref resolution?
>
>
>Option #1
>The cross reference resolves to the first instance of an element with
>id="first"; processors should report that the topic contains a duplicate
>value for the @id attribute.
>
><concept id="concept">
> <title>My topic</title>
> <conbody>
>  <p id="first">First paragraph</p>
>  <ul id="reuse">
>   <li id="first">Blah blah</li>
>   <li>See First Paragraph</li>
>  </ul>
> </conbody>
></concept>
>
>Option #2
>The cross reference resolves to the first element with id="first" within
>the conrefed element. Either processors report the duplicate ID or
>rewrite the ID within the reused unordered list.
>
><concept id="concept">
> <title>My topic</title>
> <conbody>
>  <p id="first">First paragraph</p>
>  <ul id="reuse">
>   <li id="first">Blah blah</li>
>   <li>See Blah blah</li>
>  </ul>
> </conbody>
></concept>
>
>Given the current normative language in the draft 1.3 spec (quoted
>below), I think that the correct decision is option #1.
>
>"When the address is a same-topic fragment identifier ...processors MUST
>resolve it relative to the location of the content reference."
>
>I agree with Eliot that option #2, especially with having processors
>rewrite the value of the @id attribute in the conrefed <ul>, would
>improve content reuse -- but I think that we need to 1) Avoid changing
>content of approved DITA 1.3 proposals, and 2) Avoid
> imposing additional processing requirements.
>Best,
>Kris
>
>Kristen James Eberlein
>Chair, OASIS DITA Technical Committee
>Principal consultant, Eberlein Consulting
>www.eberleinconsulting.com <http://www.eberleinconsulting.com>
>+1 919 682-2290; kriseberlein (skype)
>
>On 12/8/2014 11:24 AM, Kristen James Eberlein wrote:
>
>
>DITAweb URL:
>https://ditaweb.com/oasis-dita/#/00074601-DA$00073575-DB$Handling%20xrefs%
>20and%20conrefs%20within%20a%20conref
>
>Test in question:
>"When referenced content contains a content reference or cross reference,
>the effective target of the reference depends on the form of address that
>is used in the referenced content.
>
>* 
>When the address used is a direct URI reference of any form other than a
>same-topic fragment identifier, processors
>MUST resolve it relative to the referenced content in its source location.
>
>* 
>When the address is a same-topic fragment identifier or a key reference,
>processors
>MUST resolve it relative to the location of the content reference.
>
>This means that the same content reference or cross reference can resolve
>to different targets in different use contexts because "same topic"
>references resolve to the topic containing the reference and key
>references
> are resolved in the context of the key scope in effect for each use of
>the topic containing the reference. In the case of "same topic" fragment
>identifiers, it is the responsibility of the author of the content
>reference to ensure that any element IDs specified
> in same-topic fragment identifiers in the referenced content are either
>in the referenced content or provided by elements in the referencing
>topic."
>
>Comments:
>
>
>[Eliot Kimber] 
>There is also the use case of conref of content where the references are
>to IDs within the referenced content and referenced by a this-topic
>fragment ID and the referencing context also has an element with the same
>ID. What should the processor do in that case?
>
>Options include:
>A. Resolve to the first instance of the ID following conref resolution
>and report the duplicate ID. This is the current behavior for duplicate
>IDs generally.
>
>B. Rewrite the IDs and references in the conreffed content so that the
>link resolves in the use context as it did in the source context.
>
>Option A is reasonable but option B makes content more reusable when the
>re-used content is otherwise self contained. I would like to propose
>making option B required but I doubt the TC would be willing to impose
>that processing requirement
> at this point.
>[Robert Anderson] 
>OK, I've got that use case clear in my mind, using an actual example here
>to clarify. Use case is something like this being reused:
><ol id="reuse">
>? <li id="first">blahblah</li>
>? <li>See <xref href="#./first"/></li>
></ol>
>In the new topic, id="first" already exists before the conref. So, in the
>new topic that pulls in the list above, does "#./first" resolve to the
>"first" that existed already in the topic, or to the list item that's
>pulled in with the conref?
> 
>-- 
>Best,
>Kris
>
>Kristen James Eberlein
>Chair, OASIS DITA Technical Committee
>Principal consultant, Eberlein Consulting
>www.eberleinconsulting.com <http://www.eberleinconsulting.com>
>+1 919 682-2290; kriseberlein (skype)
>
>--------------------------------------------------------------------- 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
><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
><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]