Re: [dita] Review #2 comment for TC consideration: Subject scheme

[Eliot Kimber <ekimber@contrext.com>]

I don't think there's any reason to have any special rules for subject
scheme maps when they are processed as maps, either as root maps or
included in other maps using normal map references. That is, they simply
contribute their keys as any other map would.

I think it is appropriate and reasonable to indicate that processors MAY
use subject scheme maps for validation of enumerated lists or for
interpreting DITAVAL configurations by using the subject scheme map as
separate input to the process, meaning that processors are free to provide
ways of specifying subject scheme maps at processing time separate from
the main maps being processed. But processors *always* have that option
since the standard doesn't (and wouldn't) preclude it (by the principle
that anything not explicitly disallowed is implicitly allowed). It was, I
think, always intended that subject schemes could be used in this way so
there's no reason not to make that intent clear in the spec.

But this processor-specific way of using subject scheme maps *must not*
affect the key spaces constructed from the input maps for the purpose of
normal key resolution, whether the subject scheme map is used as part of a
larger map or used standalone for configuration and validation.

That is, there are two completely separate domains of use for subject
scheme maps:

1. As a normal map contributing to a larger map tree. In this context,
there is nothing special about subject scheme maps with regard to the keys
they define or how those keys contribute to the key spaces constructed
from the root map.

2. As stand-alone configuration for enumerated values and conditional
attribute value interpretation. In this context the specific semantics of
the subject scheme element types are used (e.g., the enumeration and
taxonomic implications of the subjects defined). But even here, the key
space construction must be normal: the same precedence rules must apply.

Cheers,

E.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 11/28/14, 11:41 AM, "Kristen James Eberlein"
<kris@eberleinconsulting.com> wrote:

>
>  
>
>    
>  
>  
>    DITAweb URL:
>https://ditaweb.com/oasis-dita/#/00074601-DA$00074138-DB$Subject%20scheme%
>20maps%20and%20their%20usage
>    
>    Topic:
>    Subject scheme maps and their usage
>    
>    Thread:
>    
>      
>* [Chris Nitchie] This section never describes how you associate
>        a subject scheme map with a "narrative" map, Maybe that's
>        intentional, but a simple sentence somewhere saying that you
>        associate a subject scheme with a map via a normal DITA map
>        reference would be helpful, I think. [Eberlein: Done]
>        
>        Somewhat relatedly, the spec never discusses the key space
>        implications of referencing a subject scheme map, with all its
>        keydefs, from another map with its more structural key
>        definitions. I'm pretty sure that the keydefs from the subject
>        scheme map get added to the key scope where they're included
>        just based on the key space rules - i.e. subject schemes are not
>        a special case vis-a-vis key definitions (which I'm not happy
>        about but c'est la vie) - but that should probably be called out
>        specifically.
>        
>      
>      
>* [Eliot Kimber] Yes, there is nothing special about subject
>        scheme maps with regard to how the keys they define are
>        processed.
>        
>        I would probably make having a subject scheme map define a clear
>        scope name standard practice. Or not, if the key names are
>        already sufficiently distinct, which is often the case if the
>        subject scheme reflects an existing taxonomy where the keys
>        reflect (or are identical to) the existing taxonomy's subject
>        IDs.
>        
>      
>      
>* [Jarno Elovirta] The association description should NOT forbid
>        associating a subject scheme map without a map reference. It
>        should be possible to process a single topic and provide the
>        subject scheme to the processor separately, just like you can
>        provide a DITAVAL filter file.
>        
>      
>      
>* [Kris Eberlein] Chris, the TC has not yet decided whether
>        subject schemes are a special case or not. That's an open
>        question for the TC to resolve. I think that there are many
>        reasons why subject schemes need to be handled differently ...
>    
>
>    
>    -- 
>      Best,
>      Kris
>      
>      Kristen James Eberlein
>      Chair, OASIS DITA Technical Committee
>      Principal consultant, Eberlein Consulting
>      www.eberleinconsulting.com <http://www.eberleinconsulting.com>
>      +1 919 682-2290; kriseberlein (skype)
>      
>    
>  
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>