[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Implications of key scopes for subject scheme maps (was Review #2 comment for TC consideration: Subject scheme)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]