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)

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

* 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

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

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.


Eliot Kimber, Owner
Contrext, LLC

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 Nitchie
>(734) 330-2978
> <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
>>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
>>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
>>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.
>>Eliot Kimber, Owner
>>Contrext, LLC
>>On 11/28/14, 11:41 AM, "Kristen James Eberlein"
>><kris@eberleinconsulting.com> wrote:
>>>    DITAweb URL:
>>>    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:
>>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:
>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:

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