[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Learning and Training Proposal: Allow Topicrefs to NestThemselves
My apologies for missing Tuesday's meeting: I blame vacation amnesia--I was on the West coast and the meeting had already happened before I remembered it. I will be on the 8/11 call. Cheers, Eliot On 8/5/09 2:58 PM, "Grosso, Paul" <pgrosso@ptc.com> wrote: > [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 > > > --------------------------------------------------------------------- > 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 > ---- 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]