OASIS Darwin Information Typing Architecture (DITA) TC

Here's what I was trying to communicate on today's call and my proposal for subjectScheme processing. * There are two processing contexts that apply to subject schemes: normal key space construction/key resolution and attribute value validation/classification. * Key processing must be normal for subject schemes (that is, in this processing context they are just maps like any other). * Attribute value validation can have its own rules and probably should. These rules should apply whether the subject scheme is literally included into a root map or used as a separate configuration file by a processor. In reviewing the 1.2 language reference for subject schemes, I'm not seeing any discussion of *how* a processor comes to know about a subject scheme and no examples of literally including a subject scheme map into a larger map: have I missed something elsewhere in the spec? If there is no explicit mention of it, that suggests that the design always assumed that subject schemes were associated with processors and separate from the publication maps being processed, which would make a lot of sense and would explain the lack of discussion of the case of multiple subject schemes being literally included in a map. At the same time, the 1.2 language for subject schemes and the examples make it pretty clear that the intent was that normal key rules apply within the subject scheme itself--the example for schemaref shows how to construct the entries in the referencing schema so as not to override the subject key names in the referenced schema. So that's evidence that the original intent was that subject schemes be treated as normal maps for the purpose of processing the keys within the subject scheme map (that is, you'd apply normal map processing to determine the set of keys and then use that to understand the subjects and enumerations defined). I think then that a useful way to approach subject schemes would be as follows: 1. When literally included in normal maps subject schemes contribute to the normal-map's key spaces in exactly the same way any other normal map would. 2. For the purposes of doing attribute value validation or other classification processing, subject schemes referenced from non-subjectScheme maps are treated as being standalone even if they are associated with a key space in the referencing map (or define their own key space on the subjectScheme element). Thus, references to values defined in subjectScheme maps are not affected by the use of key scopes in referencing maps. 3. Within a root subjectScheme map, key scopes *are* applied normally, meaning that you can use key scopes to create scope-qualified keys within the subject scheme and normal key scope handling rules apply to the subjectScheme map processed in isolation. In the case where a subjectScheme map defines key scopes, references to subjects in those scopes from outside the subjectScheme map must be fully qualified (as though the subjectScheme map was processed to expand all key definitions to reflect the scope names and create a single, unscoped key space) [This is also the normal implication of key scopes, since you'd never have a reference to a subjectScheme key from within the subjectScheme's own scope, if we treat an attribute value governed by a subject scheme as a key reference.]. This allows, for example, the integration of multiple subjectSchemes that would otherwise have conflicting subject names within a single root subjecScheme. 4. In the case where a normal map includes multiple subjectScheme maps, the relationship between the subjectSchemes for the purposes of validation and classification is processor dependent [WEK: This is the coward's way of saying "don't do that".] The general principle of rules (2) and (3) is that a given root subjectScheme defines a standalone set of subjects and values, independent of any non-subjectScheme maps it might be referenced from. The validation and classification processing result should thus be the same whether the subjectScheme is literally referenced from a normal map or used as a processing parameter, while providing the utility of key scopes within the subjectScheme map itself. It might also be useful to define a specialization of <data> to use to reference subjectSchemes without using topicref, so that map authors can conveniently indicate the taxonomies they want to use with the map without polluting their key space. That would be consistent with semantic of subject schemes as fundamentally metadata, not content. Cheers, Eliot ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 12/8/14, 2:44 PM, "Chris Nitchie" <chris.nitchie@oberontech.com> wrote: >My assumption was that all subject scheme maps follow your scenario #2 - >as a configuration file for enumeration values. I'm unfamiliar with >subject scheme maps contributing directly to the structure of a >publication. If that's an actual usage scenario that's used by real >people, then you're right, we must treat keys in subject schemes the same >as other keys. > >My assumption had been that keys in subject schemes name texonomies and >enumerated values, but don't provide indirect linking capabilities for >content. That is, I'd assumed that they were two completely different >things that just happened to use the same markup. If that's not the case, >I retract my statement about wanting them treated differently. > >Chris > > >Chris Nitchie >(734) 330-2978 >chris.nitchie@oberontech.com >www.oberontech.com > < http://www.oberontech.com/ > >Follow us: > < https://www.facebook.com/oberontech > > < https://twitter.com/oberontech > > < http://www.linkedin.com/company/oberon-technologies > > > > > > > > > >On 11/29/14, 8:45 AM, "Eliot Kimber" <ekimber@contrext.com> wrote: > >>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%20schem >>>e >>>% >>>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 >>> >>> >> >> >> >>--------------------------------------------------------------------- >>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 >> > > >--------------------------------------------------------------------- >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 > >

I agree with all of this. Best, Chris > On Jan 20, 2015, at 12:43 PM, Eliot Kimber <ekimber@contrext.com> wrote: > > Here's what I was trying to communicate on today's call and my proposal > for subjectScheme processing. > > * There are two processing contexts that apply to subject schemes: normal > key space construction/key resolution and attribute value > validation/classification. > > * Key processing must be normal for subject schemes (that is, in this > processing context they are just maps like any other). > > * Attribute value validation can have its own rules and probably should. > These rules should apply whether the subject scheme is literally included > into a root map or used as a separate configuration file by a processor. > > In reviewing the 1.2 language reference for subject schemes, I'm not > seeing any discussion of *how* a processor comes to know about a subject > scheme and no examples of literally including a subject scheme map into a > larger map: have I missed something elsewhere in the spec? If there is no > explicit mention of it, that suggests that the design always assumed that > subject schemes were associated with processors and separate from the > publication maps being processed, which would make a lot of sense and > would explain the lack of discussion of the case of multiple subject > schemes being literally included in a map. > > At the same time, the 1.2 language for subject schemes and the examples > make it pretty clear that the intent was that normal key rules apply > within the subject scheme itself--the example for schemaref shows how to > construct the entries in the referencing schema so as not to override the > subject key names in the referenced schema. So that's evidence that the > original intent was that subject schemes be treated as normal maps for the > purpose of processing the keys within the subject scheme map (that is, > you'd apply normal map processing to determine the set of keys and then > use that to understand the subjects and enumerations defined). > > I think then that a useful way to approach subject schemes would be as > follows: > > 1. When literally included in normal maps subject schemes contribute to > the normal-map's key spaces in exactly the same way any other normal map > would. > > 2. For the purposes of doing attribute value validation or other > classification processing, subject schemes referenced from > non-subjectScheme maps are treated as being standalone even if they are > associated with a key space in the referencing map (or define their own > key space on the subjectScheme element). Thus, references to values > defined in subjectScheme maps are not affected by the use of key scopes in > referencing maps. > > 3. Within a root subjectScheme map, key scopes *are* applied normally, > meaning that you can use key scopes to create scope-qualified keys within > the subject scheme and normal key scope handling rules apply to the > subjectScheme map processed in isolation. In the case where a > subjectScheme map defines key scopes, references to subjects in those > scopes from outside the subjectScheme map must be fully qualified (as > though the subjectScheme map was processed to expand all key definitions > to reflect the scope names and create a single, unscoped key space) [This > is also the normal implication of key scopes, since you'd never have a > reference to a subjectScheme key from within the subjectScheme's own > scope, if we treat an attribute value governed by a subject scheme as a > key reference.]. This allows, for example, the integration of multiple > subjectSchemes that would otherwise have conflicting subject names within > a single root subjecScheme. > > 4. In the case where a normal map includes multiple subjectScheme maps, > the relationship between the subjectSchemes for the purposes of validation > and classification is processor dependent [WEK: This is the coward's way > of saying "don't do that".] > > The general principle of rules (2) and (3) is that a given root > subjectScheme defines a standalone set of subjects and values, independent > of any non-subjectScheme maps it might be referenced from. The validation > and classification processing result should thus be the same whether the > subjectScheme is literally referenced from a normal map or used as a > processing parameter, while providing the utility of key scopes within the > subjectScheme map itself. > > It might also be useful to define a specialization of <data> to use to > reference subjectSchemes without using topicref, so that map authors can > conveniently indicate the taxonomies they want to use with the map without > polluting their key space. That would be consistent with semantic of > subject schemes as fundamentally metadata, not content. > > Cheers, > > Eliot > ————— > Eliot Kimber, Owner > Contrext, LLC > http://contrext.com > > > > >> On 12/8/14, 2:44 PM, "Chris Nitchie" <chris.nitchie@oberontech.com> wrote: >> >> My assumption was that all subject scheme maps follow your scenario #2 - >> as a configuration file for enumeration values. I'm unfamiliar with >> subject scheme maps contributing directly to the structure of a >> publication. If that's an actual usage scenario that's used by real >> people, then you're right, we must treat keys in subject schemes the same >> as other keys. >> >> My assumption had been that keys in subject schemes name texonomies and >> enumerated values, but don't provide indirect linking capabilities for >> content. That is, I'd assumed that they were two completely different >> things that just happened to use the same markup. If that's not the case, >> I retract my statement about wanting them treated differently. >> >> Chris >> >> >> Chris Nitchie >> (734) 330-2978 >> chris.nitchie@oberontech.com >> www.oberontech.com >> < http://www.oberontech.com/ > >> Follow us: >> < https://www.facebook.com/oberontech > >> < https://twitter.com/oberontech > >> < http://www.linkedin.com/company/oberon-technologies > >> >> >> >> >> >> >> >> >>> On 11/29/14, 8:45 AM, "Eliot Kimber" <ekimber@contrext.com> wrote: >>> >>> 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%20schem >>>> e >>>> % >>>> 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 >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> >> >> --------------------------------------------------------------------- >> 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 > > > > --------------------------------------------------------------------- > 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 >

I agree with Eliot. I figured out that keys are really "identifiers" not "names" and that attribute values are also identifiers - so they are key like although they key into a ditaval item. Because we want human readable XML we often use english names as these identifier values - guids in this context would be offensive :). It seems that combined with navtitle you could internationalize a subject scheme without upsetting these identifiers and their corresponding references. I was also wondering what other topic meta data elements could be used in subjectdef and what their use meant - but did not make any progress there. cheers Jim >
Original Message----- > From: dita@lists.oasis-open.org [ mailto:dita@lists.oasis-open.org ] On Behalf > Of Eliot Kimber > Sent: January-20-15 9:43 AM > To: dita > Subject: Re: [dita] Implications of key scopes for subject scheme maps (was > Review #2 comment for TC consideration: Subject scheme) > > Here's what I was trying to communicate on today's call and my proposal for > subjectScheme processing. > > * There are two processing contexts that apply to subject schemes: normal > key space construction/key resolution and attribute value > validation/classification. > > * Key processing must be normal for subject schemes (that is, in this > processing context they are just maps like any other). > > * Attribute value validation can have its own rules and probably should. > These rules should apply whether the subject scheme is literally included into > a root map or used as a separate configuration file by a processor. > > In reviewing the 1.2 language reference for subject schemes, I'm not seeing > any discussion of *how* a processor comes to know about a subject scheme > and no examples of literally including a subject scheme map into a larger > map: have I missed something elsewhere in the spec? If there is no explicit > mention of it, that suggests that the design always assumed that subject > schemes were associated with processors and separate from the publication > maps being processed, which would make a lot of sense and would explain > the lack of discussion of the case of multiple subject schemes being literally > included in a map. > > At the same time, the 1.2 language for subject schemes and the examples > make it pretty clear that the intent was that normal key rules apply within the > subject scheme itself--the example for schemaref shows how to construct > the entries in the referencing schema so as not to override the subject key > names in the referenced schema. So that's evidence that the original intent > was that subject schemes be treated as normal maps for the purpose of > processing the keys within the subject scheme map (that is, you'd apply > normal map processing to determine the set of keys and then use that to > understand the subjects and enumerations defined). > > I think then that a useful way to approach subject schemes would be as > follows: > > 1. When literally included in normal maps subject schemes contribute to the > normal-map's key spaces in exactly the same way any other normal map > would. > > 2. For the purposes of doing attribute value validation or other classification > processing, subject schemes referenced from non-subjectScheme maps are > treated as being standalone even if they are associated with a key space in > the referencing map (or define their own key space on the subjectScheme > element). Thus, references to values defined in subjectScheme maps are not > affected by the use of key scopes in referencing maps. > > 3. Within a root subjectScheme map, key scopes *are* applied normally, > meaning that you can use key scopes to create scope-qualified keys within > the subject scheme and normal key scope handling rules apply to the > subjectScheme map processed in isolation. In the case where a > subjectScheme map defines key scopes, references to subjects in those > scopes from outside the subjectScheme map must be fully qualified (as > though the subjectScheme map was processed to expand all key definitions > to reflect the scope names and create a single, unscoped key space) [This is > also the normal implication of key scopes, since you'd never have a reference > to a subjectScheme key from within the subjectScheme's own scope, if we > treat an attribute value governed by a subject scheme as a key reference.]. > This allows, for example, the integration of multiple subjectSchemes that > would otherwise have conflicting subject names within a single root > subjecScheme. > > 4. In the case where a normal map includes multiple subjectScheme maps, > the relationship between the subjectSchemes for the purposes of validation > and classification is processor dependent [WEK: This is the coward's way of > saying "don't do that".] > > The general principle of rules (2) and (3) is that a given root subjectScheme > defines a standalone set of subjects and values, independent of any non- > subjectScheme maps it might be referenced from. The validation and > classification processing result should thus be the same whether the > subjectScheme is literally referenced from a normal map or used as a > processing parameter, while providing the utility of key scopes within the > subjectScheme map itself. > > It might also be useful to define a specialization of <data> to use to reference > subjectSchemes without using topicref, so that map authors can conveniently > indicate the taxonomies they want to use with the map without polluting > their key space. That would be consistent with semantic of subject schemes > as fundamentally metadata, not content. > > Cheers, > > Eliot > ————— > Eliot Kimber, Owner > Contrext, LLC > http://contrext.com > > > > > On 12/8/14, 2:44 PM, "Chris Nitchie" <chris.nitchie@oberontech.com> > wrote: > > >My assumption was that all subject scheme maps follow your scenario #2 > >- as a configuration file for enumeration values. I'm unfamiliar with > >subject scheme maps contributing directly to the structure of a > >publication. If that's an actual usage scenario that's used by real > >people, then you're right, we must treat keys in subject schemes the > >same as other keys. > > > >My assumption had been that keys in subject schemes name texonomies > and > >enumerated values, but don't provide indirect linking capabilities for > >content. That is, I'd assumed that they were two completely different > >things that just happened to use the same markup. If that's not the > >case, I retract my statement about wanting them treated differently. > > > >Chris > > > > > >Chris Nitchie > >(734) 330-2978 > >chris.nitchie@oberontech.com > >www.oberontech.com > > < http://www.oberontech.com/ > > >Follow us: > > < https://www.facebook.com/oberontech > > > < https://twitter.com/oberontech > > > < http://www.linkedin.com/company/oberon-technologies > > > > > > > > > > > > > > > > > > >On 11/29/14, 8:45 AM, "Eliot Kimber" <ekimber@contrext.com> wrote: > > > >>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%20sc > >>>hem > >>>e > >>>% > >>>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.ph > >>>p > >>> > >>> > >> > >> > >> > >>--------------------------------------------------------------------- > >>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 > >> > > > > > >--------------------------------------------------------------------- > >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 > > > > > > > > --------------------------------------------------------------------- > 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