[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Request for TC feedback about @subjectrefs proposal
|
Forwarding. Kris From: Eliot Kimber <eliot.kimber@servicenow.com>
Here I’m only concerned about the key nature of @subjectrefs and subject scheme maps—either subject scheme maps are normal maps for the purpose of determining what keys they define and then resolving those
keys to some resource as bound in the subject scheme map or they are not. Either subject scheme maps are normal maps and all the key rules apply (and there are no special rules around keys defined in subject scheme maps) or subject scheme maps must be entirely
distinct (which I think we’ve already established should have been the case originally).
The key nature of subject scheme maps is orthogonal to the understanding of the subject scheme as a hierarchy or graph of subjects, that is, the hierarchy relevant to the definition of enumerated lists—that’s
entirely in the domain of subject scheme processing semantics, I think. The semantic processing of a subject scheme as a taxonomy or ontology is not dependent on the details of the key space constructed, except to the degree the key binding determines whatever
resources might be associated with a given subject name in a given processing context.
The only wrinkle I can think of is the implications when a key defined in a subject scheme map is overridden by the using map when a subject scheme map is used as a submap—does that affect the subject-scheme-defined
hierarchical position of that key or does it simply rebind that key, at that position in the hierarchy, to some other resource?
I would think that the latter behavior would be correct: The subject scheme defines a hierarchy of subjects (the key names) and those get bound to some resources. The resource binding can be overridden using
normal key mechanisms but the hierarchy definition is invariant (otherwise it would be very dangerous to include subject scheme maps as submaps for fear of accidently disrupting a subject hierarchy). That is, the markup of the subject scheme map defines the structure of the taxonomy and the names of the subjects and that is a function of the markup and has nothing to do with the key space that also results
from applying normal key space construction rules to the subject scheme map. This also suggests that using subject scheme maps as peer maps or as application-bound maps would be normal practice so that the subject scheme itself is completely isolated from any keys defined in the referencing
maps. It sounds like we’re in agreement on the normative processing requirements, just wanted to be sure. Cheers, E. _____________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 LinkedIn | Twitter | YouTube | Facebook From:
kris eberleinconsulting.com <kris@eberleinconsulting.com> [External Email] Some comments below. From:
dita@lists.oasis-open.org <dita@lists.oasis-open.org>
On Behalf Of Eliot Kimber Reading this draft I think we need to be very clear about how the subjectScheme map can or must be associated with the map that makes @subjectrefs references and what the implications are, if any, for unresolvable
keys. I think that the following cases need to be accounted for:
<kris>We clearly state that subject scheme maps either can be included as a processing resource in a main map – or provided by some sort of processor-specific means. I’m less sure
that I agree entirely that “The fact that the map happens to be a subjectScheme map is not relevant for the purposes of key space construction.” Yes, key space construction should happen according to one single set of rules – and part of why we decided to
remove the concept of extending subject scheme maps. But … There are some unique expectations around processing for subject scheme maps, as defined for controlled values. We expect that processors SHOULD understand the hierarchy
that is implicit in a subject scheme map when used to define controlled values. We have not talked about whether we would have any similar expectations for when a subject scheme maps is used to define subjects for use with @subjectrefs. Remember that we decided,
largely because of the late point in the timeline, to NOT specify processing expectations for @subjectrefs.</kris>
Note the implication that normal scoped key resolution rules apply: the same subject referenced in different scopes might resolve to different subjects in different subject scheme maps. <kris>In the DITA 1.3 time frame we decided to notcover @keyscopes in subject scheme. I remember arguing with Robert about this, as I kept running into use cases which I thought really required key scopes.
We may well still have wiggle language in the spec about subject scheme maps and key scopes.</kris> In all of these cases there is the question of whether or not DITA processors are required to attempt to resolve keys referenced from @subjectrefs. I think they should *not* be required to attempt to
resolve them, making @subjectrefs key resolution a MAY not a MUST. I think SHOULD would be too strong as a lot of processors will simply never care about @subjectrefs and shouldn’t be made to feel bad for not doing anything with them. <kris>Again, we’ve never used MUST statements regarding subject schemes. We make relatively few RFC-2119 statements about subject scheme. See rules 06-10.</kris> The way I would expect processors to work is to treat @subjectrefs values as first-and-foremost simple classification keyword values as though they had been specified using e.g., <data value=”ss1.subject-01”/>
or <data name=”ss1” value=”subject-01”/>: it’s metadata and who or what can make sense of it is a local concern. When the referenced key can be resolved then processors are free to do whatever they want with the resource bound to the key, if anything. With this approach it cannot be a DITA-defined error to not be able to resolve subjectrefs keys, although processors MAY treat it as an error if the processor depends on the subject being resolvable (i.e.,
an application that uses subjectrefs to construct some essential aspect of the result using the resources bound to the keys). This avoids requiring processors attempt to resolve subjectref keys when they otherwise don’t know anything about subject schemes. Cheers, E. _____________________________________________ Eliot Kimber Sr Staff Content Engineer O: 512 554 9368 M: 512 554 9368 LinkedIn | Twitter | YouTube | Facebook From:
dita@lists.oasis-open.org <dita@lists.oasis-open.org>
on behalf of kris eberleinconsulting.com <kris@eberleinconsulting.com> [External Email] I was expecting to send the stage three proposal to reviewers (Robert, Gershon, Carsten) last Friday, but ran into some glitches when considering how to update the example topics in the “Cascading metadata”
section of the spec. The technical requirements outlined in the stage two proposal called for adding @subjectrefs to <topicref> and specializations of <topicref>. Now I’m wondering if @subjectrefs should also be available on <map>. I don’t think setting @subjectrefs on <map> will be something that folks often do, but it would make it easier to explain how @subjectrefs cascades from a <mapref> element to the topics referenced in the submap. I was hoping to simply edit the following topic: “Example: How attributes cascade from one map to another” … Draft stage three proposal attached, as well as a PDF of the extant example topic. Kris |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]