Re: [dita] Inheritance of attributes through mapref

[Eliot Kimber <ekimber@reallysi.com>]

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>