[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Evaluation of the subject scheme review
I think key processing is different not just in the case of "enumerated values used to match to attribute values," but also in scenarios where one uses the <schemeref> element to extend the controlled values or taxonomic subjects defined in a subject scheme map.
We clearly state in both the 1.2 and draft 1.3 specs that "The <schemeref> element provides a reference to another scheme. Typically, the referenced scheme defines a base set of controlled values that are extended by the current scheme. The values in the referenced scheme are merged with the current scheme; the result is equivalent to specifying all of the values in a single subject scheme map."
I agree with Chris Nitchie's comment in DITAweb: ""That's not how keyref normally works. We definitely need normative language describing the expected processing of keyref in the context of a subject scheme. It's completely different from normal keyref behavior. Normally, a keyref is a reference to the content referenced by the key-defining topicref, not a reference to the topicref itself. And there's no transclusion or extension, as is implied here. So it's completely different processing rules for keys in a subject scheme, and it needs normative description."
Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 2/6/2015 1:43 PM, Eliot Kimber wrote:
There shouldn't be any issue with using key-based references to topics from subject definitions--the same rules for resolving keys (and not having circular key references) must still apply. Of course, since subject-defining topicrefs are resource-only, there's not a compelling reason to use keys for references to the defining resources unless the same resource is used by multiple subjects (which would call the sensibility of your taxonomy into question, since you'd expect a given definition to apply to exactly one subject). When a subject scheme is processed as a normal DITA map, the key processing is as it is for any other map. It is in the processing of a subject scheme as a set of enumerated values used to match to attribute values that the interpretations of the keys might be different. But the addressing-related rules for keys must be the same as for all other maps. And I will say that I did closely read the subject scheme topics for 1.2 and in the process of writing the chapter on subject schemes in DITA for Publishers. But it all made sense to me (I had questions about the design choices made but not questions about what the spec said the design meant). And we certainly didn't have the luxury of rethinking the writing for DITA 1.2. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com On 2/6/15, 12:11 PM, "Kristen James Eberlein" <kris@eberleinconsulting.com> wrote:It was very interesting to evaluate the comments made in the reviewof the subject scheme material. Several points became very clear:* It was the first time that most people had read thiscontent, and probably the first time that it has been reviewed.* The draft 1.3 topics contained some examples that illustrateprocessor behavior that is either not described normatively or described in inadequate detail. I'm working on this, but will definitely need help. There also are limits to what we can do and get DITA 1.3 out this year.* The draft 1.3 topics focus primarily on controlled valuesand do not discuss (much) what can be done with taxonomic subjects, especially in conjunction with the classification domain. I think we'll just need to accept this as a shortcoming for 1.3.* Keys and key references function differently in the contextof subjectScheme maps. This is especially evident in the following situations, and I think we must clarify our collective, TC stance about the expected processing of @keyref in the context of a subject scheme:* Using <schemeref> to extend an enumeration ofcontrolled values or to broaden subject categories* Using an addressing attribute to link to a detailedexplanation of a subject from a <subjectdef> element. Here I think one must use @href; using @keyref would open up the possibility of lots of circular processing.* If subject scheme maps have special rules for processing@keyref, do they also have special rules for key scopes? Are key scopes even valid for subject scheme maps?Back story:* There was one subjectScheme topic in the 1.2 ArchitecturalSpec, and then lots of material in the Language Reference examples. For 1.3, I broke the content into multiple topics, and moved material out of the (non-normative) examples in the Language Reference.* The original spec material had been taken from proposalsdrafted by Erik Hennum (IBM), who left IBM before 1.2 was released. Erik's tendency was to define through example, which is how so many of the rules and processor expectations ended up in the Language Reference examples.-- Best, KrisKristen James EberleinChair, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]