Re: [dita-users] Interaction between multiple subjectSchemes in a root map

I am forwarding this e-mail from the
      dita-users list, since it raises questions that we need to
      consider:

      
        
How should processors handle multiple subjectScheme maps
          that are referenced by a root map or its children maps?

        
How should processors handle subjectScheme maps that are
          referenced from within a key scope?

      
      
The spec is clear about how subjectScheme maps that are
        referenced using a <schemeref> element should be used to
        extend enumerations of controlled values; see
http://docs.oasis-open.org/dita/dita/v1.3/os/part1-base/archSpec/base/extending-a-subject-scheme.html#concept_bxc_hmj_zq
        (normative topic),
http://docs.oasis-open.org/dita/dita/v1.3/os/part1-base/archSpec/base/example-subjectScheme-extension.html
        (non-normative example), and
http://docs.oasis-open.org/dita/dita/v1.3/os/part1-base/archSpec/base/example-subjectScheme-extension-upwards.dita.html
        (non-normative example).

      
However, the spec does not explicitly address address the
        question of whether subjectScheme maps that are referenced by
        regular <topicref> elements or specializations thereof
        extend enumerations in a similar fashion. Is this scenario
        covered by default expectations about how processors simply
        handle keys?

      

      Best,

      Kris

      

      Kristen James Eberlein

      Chair, OASIS DITA Technical Committee

      Principal consultant, Eberlein Consulting

      www.eberleinconsulting.com

      +1 919 682-2290; kriseberlein (skype)

      

    

    
On 7/5/2016 6:05 PM,
       [dita-users] wrote:

    

      
      
      

        

          
          

            
Hi all,

            

              

            
I've been doing some testing and was wondering what
                the recommendation is when there are multiple
                subjectSchemes in a map...what values are made available
                for the defined attributes. My finding, in one
                particular XML editor, is that the editor looks first
                for a subjectScheme referenced by the root map. If one
                exists, the values enumerated there are made available
                to the editor's value picklist for that attribute. If
                more than one exists, and each enumerates different
                values for, say @audience, then only the @audience
                values enumerated in the first one are made available to
                the editor:

                

                MapA

                |_MapB

                |_MapC

                |_subjectSchemeW <-- these values used for @audience
                throughout root map

                |_subjectSchemeX <-- these values ignored for
                @audience throughout root map

                

                If the second subjectScheme also enumerates values for a
                different attribute, then those are made available to
                the editor as well. 

                

                MapA

                |_MapB

                |_MapC

                |_subjectSchemeW <-- these values used for @audience
                throughout root map

                |_subjectSchemeX <-- these values used for @product
                throughout root map

                

                

                If, in addition, there are subjectSchemes referenced by
                any child maps of the root map those are all ignored:

                

                MapA

                |_MapB

                  |_subjectSchemeW <-- these values ignored for
                @audience throughout root map

                |_MapC

                  |_subjectSchemeX <-- these values ignored for
                @audience throughout root map

                |_subjectSchemeY <-- these values used for @audience
                throughout root map

                

                If there is no subjectScheme referenced by the root map,
                but there are subjectSchemes referenced by one or more
                of the child maps, the first subjectScheme encountered
                is used and the others are ignored:

                

                MapA

                |_MapB

                  |_subjectSchemeW <-- these values used for
                @audience throughout root map

                |_MapC

                  |_subjectSchemeX <-- these values ignored for
                @audience throughout root map

                

                It seems in all these respects that subjectdef in a
                subjectScheme behaves more or less like DITA 1.2
                keys...first in wins. Is this the expected behavior?

                

                Going further, it seems that if a subjectScheme is
                referenced within a child map that in turn is referenced
                by a

                root map, and the child mapref has @keyscope defined,
                that subjectScheme is ignored altogether by this
                particular editor, even if it otherwise should be used
                for value enumeration:

                

                MapA

                |_MapB keyscope="B"

                  |_subjectSchemeW <-- these values ignored for
                @audience throughout root map

                |_MapC

                  |_subjectSchemeX <-- these values used for
                @audience throughout root map

                

                This is not at all what I'd expect. I'd expect keyscope
                to have no effect whatsoever on subjectScheme value
                enumeration, since nothing is defined on this point in
                the spec that I can find. It would be *nice* if, say, an
                editor could recognize the keyspace of an open topic and
                only present attribute values in the picklist that are
                enumerated in the effective subjectScheme that is
                referenced in the same keyspace as the open topic, but
                again, the spec does not outline this requirement or
                recommendation.

                

                But again, is the "collision" between @keyscope and
                subjectScheme expected? I've asked this question of the
                editor's support as well, but thought I would throw it
                out here to see what the non-editor-specific feedback
                might be.

                

                Thanks for any clarification,

                Leigh

                
              

            

              

          

          
          
__._,_.___

          
 

          

             Posted by:
            
             

          
 

          
            
              

                 Reply
                    via web post 
                •
                 
                    Reply to sender  
                •
                  Reply
                    to group  
                •
                 Start
                    a New Topic 
                •
                 Messages
                    in this topic (1) 
              

            
          
          

            
            

              

                

                  

                  
 Have you tried the
                        highest rated email app?
                    
With
                      4.5 stars in iTunes, the Yahoo Mail app is the
                      highest rated email app on the market. What are
                      you waiting for? Now you can access all your
                      inboxes (Gmail, Outlook, AOL and more) in one
                      place. Never delete an email again with 1000GB of
                      free cloud storage.

                  

                

              

            

            
          

          
          
          
          
          
 Visit Your Group
            
              
 New Members
                4 

            
          

          
 
            
 • Privacy • Unsubscribe • Terms of Use 

          

          

           

        
        
        
        

          
          
 

           

        
        
.

      

       

      
      
__,_._,___