[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Review #2 comment for TC consideration: Subject scheme
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%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 >> >> > > > >--------------------------------------------------------------------- >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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]