[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]