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