Re: [dita] Proposal 13115: Make DITAVAL aware of subject schemes

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

One update - as Kris pointed out to me, in the last paragrah, DITAMAP
should have been DITAVAL:
> If anybody else still wants to have a way to explicitly reference a
scheme
> from within a DITAVAL, 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 Kris -

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)

<dita@lists.oasis-open.org> wrote on 03/05/2013 17:05:15:

> From: Robert D Anderson/Rochester/IBM@IBMUS
> To: dita <dita@lists.oasis-open.org>,
> Date: 03/05/2013 17:11
> Subject: [dita] Proposal 13115: Make DITAVAL aware of subject schemes
> Sent by: <dita@lists.oasis-open.org>
>
>
> 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/)
>
>
> ---------------------------------------------------------------------
> 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
>