[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Key scopes and topicsetref
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]