Proposals for Refinements to Learning and Training Modules

[Eliot Kimber <ekimber@reallysi.com>]

In the course of client projects where we are using the L&T modules as the
basis for specialized document types and processing, I have identified the
need for four refinements to the Learning and Training design. These changes
have been discussed by the Learning Subcommittee and accepted in principle.

However, these changes must be approved by the DITA TC. Thus I am putting
those proposals forward formally in separate emails to follow this one.

The proposals, in increasing order of complexity are:

1. Update the learningBase module to make learningBasebody optional, making
it consistent with the general DITA topic model (body was made optional in
the DITA 1.1) and enabling title-only learning-specific topics.

2. Update the learning map domain to allow topicrefs of the same type to
nest and set the default for @chunk to "to-content" for learningContentRef.
This allows the creation of learning content structures from re-used
subordinate topics (for example, glossary entries, as in the case of my
client). Specifying @chunk as to-content ensures that learning content
output matches the current SCORM requirement that content be structured as
single HTML pages. Or, alternatively (to avoid unwanted implications of
nested chunk="to-content", declare a new topicref type for use only within
learningContentRef. Note also that the current SCORM structure requirements
may be lifted in future versions of the SCORM standard. If the current L&T
constraints were maintained, it would be difficult to relax those
constraints in the future to reflect a more relaxed SCORM design.

3. Update the learningDomain module to add a third subelement to
lcMatchingPair to hold pair-specific feedback. The current design provides
no mechanism for associating feedback with specific match pairs. My client
has existing match interactions that provide distinct feedback for each pair
of match items. 

4. Define a new base module, learningDomainBase, providing one element type,
lcInteractionBase, specialized from topic/fig. Update learningDomain module
to make lcInteractionBase the base type for lcTrueFalse, lcSingleSelect,
lcMultipleSelect, lcSequencing, lcMatching, lcHotspot, lcOpenQuestion. This
refinement provides a common Learning-defined base for all interactions,
enabling the creation of new interaction types that are still unambiguously
identified as being Learning interations. It also allows processors to apply
interaction-specific processing with a simple, invariant check, rather than
having to select on each of the built-in interaction types and, in the case
of specialization, locally-defined or future-defined interaction types.

All of these proposals are backward compatible with existing learning
documents. 

We are not aware of any existing processors that would either be affected by
these changes or for which adding support would be a burden (for example, we
know of no implementations that actually render match tables today).

In addition, the DITA 1.2 constraint facility can be used to configure uses
of the Learning modules such that they reflect the constraints imposed as of
today. If there is serious concern, these constraint modules can be provided
by the Learning SC itself.

The refinement to matching would require change to processors of documents
that used the new feedback container, but we are not aware of any such
processors.

Cheers,

Eliot 

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>