Review #2 comment: How to treat a keyscope with multiple names

DITAweb URL:

https://ditaweb.com/oasis-dita/#/00074601-DA$00074397-DB$Core%20concepts%20for%20working%20with%20keys

    

    Text in question

    "The @keyscope
      attribute declares a name or names for the scope. If @keyscope is specified both on the root
      element in a map and on a <topicref>
      element that references that map, only one scope is introduced;
      its names are the union of the names that are specified by both @keyscope attributes."

      

    Comments

    
      
[Jarno Elovirta] I find it a bit backwards that if a
        @keyscope defines multiple names, it's treated as a single scope
        with multiple names. Instead, i would expect each name to create
        a separate scope with a single name, but the key spaces would be
        identical. Just like if you define @keys with multiple key
        names, it doesn't create a single key with multiple names, but
        rather multiple keys with a single name each.

      
[Eliot Kimber] 

        
Thinking about it now, I think that the only
          sensible interpretation is that there is a single scope that
          has key definitions reflecting all the scope names. That is,
          the important unit is the scope, in that the definition of a
          scope, with N names, establishes a single key resolution
          context. 

        
Thus, if you have a scope with two names, there
          will be two qualified key definitions for each descendant key
          defined in the scope. For example, given a scope with the
          @scopename value "A B" and the key "foo", the key space would
          be: foo, A.foo, B.foo 

        
If this wasn't the case, then for a given scope
          you would have N resolution contexts, each with different
          qualified keys (reflecting the different scope names) and
          that's clearly not sensible. 

      

      
[Robert Anderson] Referring to TC just to get a
        double-check on this and make sure others understand it. From
        Eliot's comment I'm pretty sure he's defending the current
        language as accurate, so not expecting a change, just want to be
        sure. 

    
    

    
-- 

      Best,

      Kris

      

      Kristen James Eberlein

      Chair, OASIS DITA Technical Committee

      Principal consultant, Eberlein Consulting

      www.eberleinconsulting.com

      +1 919 682-2290; kriseberlein (skype)