Meeting minutes 2013 04 02

Subject Scheme Discussion

Attendees: Robert, Eliot, George, Radu, Kris, Eric

Fixing up our code (cleanup of inefficient / poorly written sections)

1. Jarno working to separate Subject Scheme processing from current gen-list and debug-filter processing so that SS processing is an additional processing step that can be switched off. This way people who don't use SS don't have pay for the extra processing time that's required for SS. Also, a separate step is easier to write tests for.

Specification-defined items that are missing in our implementation, and/or bugs

1. Kris opened bug: we currently require type="subjectScheme" to process schemes
2. Kris opened bug: not processing schemeref element

Need clarification from specification

Each of these items we consider to be unspecified or underspecified in the specification. Each item should probably get input from the OASIS DITA Technical Committee before we implement a long-term solution to the question.

1. George points out: specification does not give a lot of information on maps that specify multiple schemes. Current language says top-level map "MUST" refer to controlled value scheme. What if scheme is specified on sub-map, and there is a conflict? Scheme in top-level map says values X/Y are valid, scheme in sub-map says Y/Z are valid, what values are valid in a topic in that sub-map?
2. Kris adds: but what happens if root map references two incompatible schemes?
3. What happens if a topic is in 2 maps, with different active schemes in each map?
4. Maybe higher level question to ask: can you specify different schemes with one set of information? Can you have a primary input map, with 3 maps, and each sub-map has its own scoped scheme?
5. What happens if you use a value "linux" -- that could mean one thing in one scheme / sub-map, and another thing in another scheme / sub-map

George has some ideas related to RelaxNG that could help enable scheme scoping; maybe some concepts to consider for DITA 1.3. Would like to discuss further (planned to discuss with Eliot at recent conference but had no time). Eliot finds this similar to the scoped keys discussion already under discussion (using keys from another map, combining maps with their own key spaces into one deliverable).

Consensus on this call - would be best to keep things simple. To that end we generally favor a global SS scope, and first (highest priority, as with other keys) definition wins when it comes to enumerations. Kris will send a note to the TC to continue discussion on this item.

New features unrelated to specification

1. Jarno plans to add support for schemes that can be specified with a plug-in, and possibly for schemes specified with a command line option. Need to document priority order, such as command-line first, then plug-in, then scheme in map; also, what happens if 2 specified as plug-ins?