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] Key scopes and topicsetref


The <topicsetref> element is really nothing more than a specialized topicref that defaults format="ditamap". The expectation is that it will refer to a <topicset> element, though any processing I've encountered would work exactly the same if it referred to any other <topicref>. [This was a commonly used element in IBM when Erik Hennum proposed it for DITA 1.2; it's still used today but most of the tools that explicitly looked for it have disappeared.]

Because it's just a slightly special topicref with a defaulted format="ditamap", <topicsetref> should work the same as it would here:
<topicref href="" format="ditamap" keyscope="topicrefScope"/>

Which could be broadened further to the more familiar case of:
<topicref href="" format="ditamap" keyscope="someScope"/>

I think this means I'm of the same opinion as Chris - how the topicsetref is "resolved" might vary based on what you're doing with it, but all the key scopes and references are determined before that happens.

Regards,

Robert D. Anderson
DITA-OT lead and Co-editor DITA 1.3 specification,
Digital Services Group


E-mail: robander@us.ibm.com
Digital Services Group
11501 BURNET RD,, TX, 78758-3400, AUSTIN, USA


Inactive hide details for Chris Nitchie ---04/13/2016 08:09:29 PM---My assumption is that any topicsetref resolution should occChris Nitchie ---04/13/2016 08:09:29 PM---My assumption is that any topicsetref resolution should occur *after* keyref resolution, and the top

From: Chris Nitchie <chris.nitchie@oberontech.com>
To: Eliot Kimber <ekimber@contrext.com>, dita <dita@lists.oasis-open.org>
Date: 04/13/2016 08:09 PM
Subject: Re: [dita] Key scopes and topicsetref
Sent by: <dita@lists.oasis-open.org>





My assumption is that any topicsetref resolution should occur *after* keyref resolution, and the topicsetref functions as a reference to the topicset as contextualized at its location. If that's the case, then whether either or both elements specify @keyscope doesn't matter, because the topicsetref's resolution occurs after all keyrefs have been resolved at both locations.

Chris




On 4/13/16, 9:08 PM, "dita@lists.oasis-open.org on behalf of Eliot Kimber" <dita@lists.oasis-open.org on behalf of ekimber@contrext.com> wrote:

>In the case of topicsetref and topicset, the 1.3 did not add any language
>to define what the behavior should be when either or both of the
>topicsetref and topicset specify a value for @keyscope.
>
>There are four possible cases:
>
>1. No key scopes. This is the 1.2 case and nothing is changed
>2. Key scope on topicsetref but not on topicset
>3. Key scope on topicset but not on topicsetref
>4. Key scope on both topicsetref and topicset
>
>In cases (2) and (3) I think the correct behavior can only be that there
>is one effective scope reflecting the scope name specified. While
>topicsetref is defined as a use-by-reference of the topicset I don't think
>just throwing away a keyscope specified on it would ever be
>appropriate--it's not a literal replacement but an application-managed
>relationship between the navigation point in the referencing map and the
>navigation structure defined by the topicset and that definitely argues
>for maintaining the keyscope.
>
>In case (4) there are four possible behaviors:
>
>1. The two scope names are merged as for map-to-map references, resulting
>in one key scope with two names.
>2. The topicsetref's scope becomes the parent scope of the topicset's key
>scope
>3. The topicsetref's key scope is ignored
>4. The topicset's key scope is ignored
>
>Option (1) is consistent with the explicit rules for map-to-map references
>and is my preference since it has the least surprise.
>
>Option (2) is logical but surprising and seems inconsistent with the
>semantic of topicsetref as a use-by-reference.
>
>Options (3) and (4) are conref-type behaviors and in a real conref would
>be controllable via the -use-conref-target keyword in the attribute value.
>That option is not available here so I think we can discard these options,
>especially since the writeup of topicsetref explicitly says it's not a
>content reference.
>
>I don't recall ever discussing the implications of key scopes for
>topicsetref. Did we?
>
>Based on my informal survey on DITA Users it doesn't appear that anyone
>much uses topicsetref.
>
>But probably good for us to decide what the right answer is or explicitly
>defer a decision to DITA 2.0.
>
>
>
>----
>Eliot Kimber, Owner
>Contrext, LLC
>
http://contrext.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]