Mapref resolution

[Robert D Anderson <robander@us.ibm.com>]

I've had an open item on this for a while, so hopefully this note will
close it out.

There was an open question of how the scope attribute is evaluated when set
on (or inherited on) a map reference. That is, what does it mean to say:
<topicref href="some.ditamap" scope="peer" format="ditamap"/>

Jeff was pushing for the scope attribute to be grouped together with format
and href -- that is, they all describe the target of the current topicref
element, not behaviors or values that can be pushed on to the target. This
means that scope="peer" on the map reference defines that target map as a
peer to the current information set. Following that logic, the map itself
is not available to access, so the scope value cannot cascade into that
map.

I know of some users in IBM who were doing something else with the
attribute, and had an action to go back to those users and discuss it. They
are willing to change their expectations based on the OASIS decision, so at
this point I am happy to go along with Jeff's suggestion, which I also feel
is more in keeping with the definition of the scope attribute.

In summary - the scope attribute should not cascade through a map
reference. Its presence on a map reference indicates the scope of that map.

The latest note I can find on @scope shows one other open item, about
cascading of multi-value attributes, but I think that discussion continued
on another thread:
http://markmail.org/message/aubiynwhxg5t7pax?q=scope
+list:org.oasis-open.lists.dita

Thanks -

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit