[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Inheritance of attributes through mapref
We don't need to provide a meaning for all possible combinations of all attribute values. And I will argue that it is better/simpler/more understandable if we don't.
So, for something like @scope we could say that when @format="ditamap" that the only meaningful value for @scope is "local", that in this case other @scope values are either 1. errors for which an implementation SHOULD report an error or warning message and MAY, but is NOT REQUIRED to, recover by assuming a value of "local" and continuing; or 2. that results are implantation specific and as a result values of @scope other than "local" SHOULD be used with caution since they may not produce the same results when used with different implementations.
-Jeff
> -----Original Message----- > From: Eliot Kimber [mailto:ekimber@reallysi.com] > Sent: Tuesday, April 14, 2009 9:59 AM > To: Robert D Anderson; Ogden, Jeff > Cc: dita > Subject: Re: [dita] Inheritance of attributes through mapref > > On 4/14/09 8:43 AM, "Robert D Anderson" <robander@us.ibm.com> wrote: > > > 2) What about the scope attribute? This is intended to describe the > scope > > of the target of the topicref. In the case of a normal topic reference, > > scope="peer" means the target is not part of the current set of > > information, and may not be available, but is part of my overall > > information set (I think of this as a reference from one Eclipse plug-in > to > > another). However, if I set @scope="peer" on a reference to a map - does > > that scope attribute describe the map (may not be available, part of > > another information set), or does the scope attribute cascade to the map, > > essentially resulting in a local map with full of peer topics? > > > > In the off-list discussion, Jeff Ogden has been pushing for the first > > behavior (@scope=peer means the map is outside of the current > information > > set). I now have an action to go back to my users in IBM who are > depending > > upon the second behavior, so we can see what impact this will have > and/or > > see if they have other good reasons to keep this behavior. > > What would the processing implications be for a reference to a map that is > not scope="local"? > > At the moment, the only well-defined meaning for a topicref to a map is > inclusion of the map's elements in the set of effective elements of the > resulting compound map. There is no notion of a navigational relationship > that I know of in the current spec, which is the only thing I can imagine > scope="peer" or scope="external" to mean (if it does not simply imply > value > propogation). > > The other possible behavior, that the @scope would propagate to the > referenced map seems reasonable in that from the standpoint of the > referenced map as authored, the topics it points to may be local but in > the > context of the referencing map they are peer or external, which would have > the effect of changing the nature of how the compound map is rendered > (depending on the details of how the processor using the map treats scope > differences). Establishing this behavior would not require changing > anything > about what the spec says in this case, since we would not be changing the > meaning of scope != local for topicrefs, whatever it means. > > If we accept Jeff's preference, then I think we would be obligated to say > explicitly what it means to point to a non-local map, and I would think it > establishes the non-local map as a root map to which a navigation > relationship is established (that is, treating the target map as the root > of > a separate unit of publication, rather than a component of a compound map). > At the moment, the only spec-defined behavior for topicref references to > maps is virtual inclusion on the map element's children. > > [NOTE: I think the DITA spec actually needs a way to explicitly create > map-to-map navigation relationships of the peer and external forms, but I > don't think we can reasonably do it in 1.2, any more than we can other > linking semantics recently discussed.] > > Cheers, > > Eliot > ---- > 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]