Proposal 13115: Make DITAVAL aware of subject schemes

[Robert D Anderson <robander@us.ibm.com>]

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/)