[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Learning and Training Proposal: Allow Topicrefs to Nest Themselves
The current learningMapDomain does not allow the *Ref topicref types to nest. This does not allow the creation of learning content structures that incorporate content from nested topics using map-based references. For example, it does not allow the creation of a learning content component that incorporates glossary entries managed as reusable components. I have at least one client that has exactly this requirement. The motivation for this constraint with the SCORM requirement that all content be structured as single artifacts (e.g., single HTML pages). However, the @chunk facility allows the SCORM requirement to be satisfied without the need to restrict topicref nesting. I also observe that the architectural spec actually assumed that the L&T design reflected this proposal, with this language from the Chunk topic: " Identification of a set of topics as a unit A curriculum developer wants to compose a lesson for a SCORM LMS (Learning Management System) from a set of topics without constraining reuse of those topics. The LMS can save and restore the learner's progress through the lesson if the lesson is identified as a referenceable unit. The curriculum developer defines the collection of topics with a DITA map, using the chunk attribute to identify the learning module as a unit before generating the SCORM manifest." This proposal satisfies both the original SCORM requirement and the map-based reuse requirement. I have presented two proposals, contingent on a decision on the implications of @chunk="to-content" specified on multiple levels of a topicref tree (see earlier note to this list asking for clarification). I have tested the 1.5M17 Toolkit and verified that specifying chunk="to-content" on multiple levels in a branch results in a new chunk at each level, not a single chunk. On the possibility that this behavior is either correct or allowed, I have provided an alternative proposal that accommodates this behavior. -------------------------------------------------------------- Proposal A. Allow *Ref types to nest, set default for @chunk on learningContentRef to "to-content". Content model changes: 1. Change learningPlanRef content to: <!ENTITY % learningPlanRef.content "((%topicmeta;)?, (%learningPlanRef;)*)" > 2. Change learningOverviewRef content to: <!ENTITY % learningOverviewRef.content "((%topicmeta;)?, (% learningOverviewRef;)*)" > 3. Change learningSummaryRef content to: <!ENTITY % learningSummaryRef.content "((%topicmeta;)?, (% learningSummaryRef;)*)" > 4. Change learningContentRef content to: <!ENTITY % learningContentRef.content "((%topicmeta;)?, (% learningContentRef;)*)" > 5. Add @chunk with default of "to-content" to learningContentRef: <!ENTITY % learningContentRef.attributes "type CDATA #IMPLIED format CDATA 'dita'" navtitle CDATA #IMPLIED id ID #IMPLIED href CDATA #IMPLIED keyref CDATA #IMPLIED keys CDATA #IMPLIED query CDATA #IMPLIED %conref-atts; copy-to CDATA #IMPLIED outputclass CDATA #IMPLIED scope (external | local | peer | -dita-use-conref-target) #IMPLIED processing-role (normal | resource-only | -dita-use-conref-target) #IMPLIED linking (targetonly| sourceonly| normal| none | -dita-use-conref-target) #IMPLIED locktitle (yes| no | -dita-use-conref-target) #IMPLIED toc (yes| no | -dita-use-conref-target) #IMPLIED print (yes| no | -dita-use-conref-target) #IMPLIED search (yes| no | -dita-use-conref-target) #IMPLIED chunk CDATA "to-content" %select-atts; %localization-atts;" > Specification Changes: - Update reference entries to reflect new content models Processor Changes: - Processors that do not currently support @chunk would need to support it. ------------------------------------------------------- Proposal B: Provide new topicref type learningContentComponentRef, Set default for @chunk on learningContentRef to "to-content" The learningContentComponentRef topicref type enables references to subcomponent of Learning Content nodes in a map tree without also setting the default for @chunk to "to-content". Content model changes: 1. Declare new topicref type learningContentComponentRef: <!ENTITY % learningContentComponentRef.content "((%topicmeta;)?, (% learningContentComponentRef;)*)" > <!ENTITY % learningContentComponentRef.attributes "%learningDomain-topicref-atts; type CDATA #IMPLIED format CDATA 'dita'" > <!ELEMENT learningContentComponentRef % learningContentComponentRef.content;> <!ATTLIST learningContentComponentRef % learningContentComponentRef.attributes;> <!ATTLIST learningContentComponentRef %global-atts; class CDATA "+ map/topicref learningmap-d/ learningContentComponentRef "> 2. Set default for @chunk on learningContentRef as in Proposal A above. Specification changes: - Document new element type learningContentComponentRef - Update documentation for learningContentRef to reflect default value for @chunk. Processor Changes - Processors that do not currently support @chunk would need to support it. No change for new topicref type assuming all processors are specialization-aware. ---- 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]