OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-learningspec message

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