[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Proposal 13115: Make DITAVAL aware of subject schemes
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]