[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Learning and Training Proposal: Allow Topicrefs to Nest Themselves
[Eliot, we discussed this proposal somewhat on this Tuesday's TC telcon, and we plan to make decisions next Tuesday.] After understanding things better, I'm okay with Proposal B--I am not okay with Proposal A. I will not object to implementing proposal B in DITA 1.2. So you all can stop reading now--but... All these proposals to change DITA 1.2 at this point are somewhat problematic. They are coming in quite late in what was supposed to be the DITA 1.2 timeline, and some of us have already released products including draft versions of the DITA 1.2 DTDs and XSDs. However, after 20 years in the standards business, I understand that--given how long it always takes to get a given version of a standard--one hates to have to wait for the next version for something that seems like a small, safe, and worthwhile change. We included the draft DITA 1.2 DTDs and XSDs in our latest release with the understanding that they weren't final, and we've informed our customer base of that fact. We'll plan to update to the final DITA 1.2 DTDs and XSDs in a future release, but that of necessity won't be for a while. Meanwhile, we will get complaints by some that "Arbortext isn't DITA 1.2 compliant" because we don't distribute the latest DTDs. I hope at least the DITA TC members understand and appreciate the actual situation. paul > -----Original Message----- > From: Eliot Kimber [mailto:ekimber@reallysi.com] > Sent: Monday, 2009 July 27 12:34 > To: dita > Subject: [dita] 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> > > > --------------------------------------------------------------------- > 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]