[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita-learningspec] Design of Learning Map Topicrefs: Why NoSubordinate Refs?
On 6/29/09 3:40 PM, "john_hunt@us.ibm.com" <john_hunt@us.ibm.com> wrote: > Hi Eliot, > > A few responses back to your comments. > >>> Allowing learningContentRef to nest recursively I think satisfies my > requirement to be able to compose learning objects from subordinate > topics. > << > > JH: Excellent! > >>> I think that all the currently leaf-level topicrefs should allow nested > learningContentRef so that, for example, I can have a pre- or > post-assessment that is composed of subordinate topics. Not sure how that > plays with SCORM but it certainly makes sense for printed tests, where > groups of questions can be organized into arbitrary hierarchies. > << > > JH: Are you suggesting the same model use learningContentRef? > > That is: > > a) set default of chunk="to-content" and > > b) allow zero or more child elements of same specialize ref type > > So, for example, for learningPreAssessmentRef: > <!ELEMENT learningPreAssessmentRef > ((%topicmeta;)?, (%learningPreAssessmentRef;)*) > > > and so on? I think so, although I haven't thought through that part deeply--would have to make sure everything made sense (for example, no unwanted type= values). > And after a wee bit more thought during the day about SCORM processing. > > a) if chunk="to-content", then we get the SCORM leaf nodes into the > chunked topic > b) if no chunk="to-content", then we need to get SCORM leaf nodes, so I > suggest we simply flatten all of the child topicrefs and make them > siblings of the parent in the SCO. Open to other thoughts. That would certainly serve to produce usable SCORM content, even if the presentation result didn't match author intent, but I don't see an obvious third option in this case. >>> And a reminder that DITA 1.2 constraint modules can re-impose > constraints > that are more relaxed in the base module, so that you can provide a > default > or example constraint module that reflects the original design. > << > > Thanks for this reminder! (And you very kind to call it a reminder, too.) > > This sounds like an excellent approach. Perhaps you can help with such > sample module. For DTDs it's really just redeclaring some content model parameter entities. For Schemas it's a little more involved, but pretty simple in both cases. The current review draft of the Architecture Spec describes the implementation design pattern in some detail. But defining such a constraint module for the L&T stuff would be a pretty good exercise so I can almost certainly help with that at some point. Cheers, E. ---- 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]