[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Request for TC feedback about @subjectrefs proposal
Forwarding some e-mails that were inadvertently off-list. Kris From: kris eberleinconsulting.com
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]