[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/26/09 11:38 AM, "john_hunt@us.ibm.com" <john_hunt@us.ibm.com> wrote: > Eliot, > > Thanks for bringing this up. > > The subcommittee had a lot of discussion about the structure of the > learning map elements. We ended up agreeing on a design restricts nesting > of these specialized learning topicrefs for at least two reasons. > > #1 - We wanted to explicitly use the Learning Map to support a learning > objects approach to structuring DITA topics into discrete, well-defined > collections of content that support specific learning objectives. > > #2 - We wanted to follow best practices for SCORM delivery, which requires > all content in leaf nodes and thus works best with a flat list of content > within a single learning object. See minutes of one of the discussions > here - > http://www.oasis-open.org/apps/org/workgroup/dita-learningspec/email/archives/ > 200801/msg00002.html > . What I'm finding that that we have course content where the learning object (if I'm using the term correctly) will be *rendered* as a single object (HTML page in this case) but has a hierarchy of content objects that need to be separate topics to enable re-use, for example, subordinate topics containing re-usable assessments or interactions or interactive course components. For example, we have one learning object that includes a terminology list, where each term is managed as a separate glossentry topic. By using the chunk= attribute on the root topicref of the learning object in the map, you ensure a single result component (satisfying the SCORM requirements (and the requirements of my client's proprietary LMS system). Because of chunk= there is no need to restrict nesting in the map simply to ensure satisfaction of a rendition target constraint. Without this restriction removed we cannot use *any* of the learning map group elements. I'm not sure that costs us anything unless there is, for example, some SCORM-generation business logic that keys off L&T-specific topicref types. If the purpose of the learning map is simply to make it easy to create maps that enforce a particular organizational scheme, that's fine, as long as there's no out-of-the-box L&T-specific processing that *requires* their use. 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]