OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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 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 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]