[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal 13115: Make DITAVAL aware of subject schemes
I've taken over for Michael on proposal 13115, and I'm hoping to knock it off easily as either "already specified" or "easy update". The proposal Michael was originally aiming towards would create an explicit connection between a DITAVAL and a Subject Scheme. The thought was that a new element in DITAVAL could link directly to the subject scheme in use to provide controlled values for that DITAVAL. I'm backing off of that a bit and hoping that we can more simply state that applications are allowed to make such a connection outside of the DITAVAL and Scheme. CURRENT STATE OF THE SPEC: http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/subjectSchema.html#subjectSchema There are a couple of portions of that topic relevant to this idea: 1. "Subject scheme maps use key definition to define a collection of controlled values rather than a collection of topics. The highest level of map that uses the set of controlled values must reference the subject scheme map in which those controlled values are defined. " 2. The therapist / novice example explains how including/excluding content with a DITAVAL should relate to the Subject Scheme. If a DITAVAL excludes the value "therapist" from your build, and the scheme defines "novice" as a subcategory of "therapist", then "novice" should be excluded in the absence of a specific rule for "novice". CONCERNS WITH THE CURRENT SPEC: 1. I would like to changethe "must reference" to "may reference", or preferably to remove that sentence entirely. The current language technically means that any DITA application with valid DITA content, and a valid scheme, cannot use those together unless every primary map explicitly references the subject scheme. I have seen many instances where a common scheme should always apply to content living in a system; for example, a company might wish to associate the same controlled value scheme with every DITA topic or map that they edit, and with every build they publish. The current "must" language technically means that an editor cannot use or enforce that connection unless the active map references the scheme. 2. There was originally a concern that the spec might not have a clear link already between filtering and scheme values, but I think that's explicit in the therapist/novice sample above. The only remaining question is whether the specification should be edited to make that more obvious. After finding the example, I could see how it might be nice to make it more obvious, but it's not an absolute requirement. I think those two changes cover all the goals we had with the original 13115 proposal. The suggested change #1 is a minor edit to make schemes more usable in a DITA system - I suspect many people are not even aware of this "must" language today, so it's probably not enforced everywhere. The second suggested change, if others think it worthwhile, is really a minor spec edit that makes no change to the spec meaning. If anybody else still wants to have a way to explicitly reference a scheme from within a DITAMAP, then they are free to take up proposal 13115 and write that up, but I do not believe it is critical to any of the goals that we have at this point. Thanks - Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]