RE: [dita-learningspec] Design of Learning Map Topicrefs: Why No Subordinate Refs?

["Reuben Tozman" <reuben@edcetratraining.com>]

Hey Folks,

Many interesting points about this discussion. I will work backwards here to
try and make sense of it because at the end of the day not sure there is
right and wrong here.

Based on John's point of being able to process out to SCORM, really the only
potential conflict that as a committee we were trying to steer people away
from was creating links between one *sco* and another *sco* (since this
would break a fundamental philosophical rule about SCORM). So if in Eliot's
case, the end result of processing meets this criteria, objective achieved
so to speak.

However, here is where working with DITA versus working directly to a SCORM
output may bring about different practices. If you were to create individual
*terminology* items as separate SCO's so that they can be independently
managed that would be too much work for too little benefit, whereon the DITA
world this makes sense. The only reason you would do that in an HTML/SCORM
world is so that the list was available as whole to all parts of a learning
program. Typically, if you wanted to do this a terminology list would indeed
be its own SCO as a whole (and not an *aggregation* of scos). However,
learning theory would suggest that having a terminology list that had all
words of a course available within a single learning object, whether the
words appeared in the object or not is unnecessary. A learner should only
have available what they need to complete a single SCO (This is debatable,
but nonetheless very popular view). This raises the question about what we
should enable or push users towards, versus enabling all possible iterations
of what someone would do. As a committee I believe we chose the former,
which is to design something that steered people towards a best practice.

The other issue about reuse of content objects and creating them as separate
topics is something the committee discussed quite a bit. We dealt with the
equivalency of a learning object to a topic and decided that a learning
object would in most cases contain multiple topics. However, if you were
working in an HTML/SCORM environment directly you would want to equate a
learning object with the smallest piece of information that you wanted to
manage independently from everything else. This would mean that the use of a
learning object in a SCORM world isn't necessarily a learning object in the
DITA world. 

And lastly, Eliot you mention: "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."

I believe it was because we wanted to ensure that we didn't need any special
processing that we needed to guide people at the map level.

My point is that there really isn't right and wrong here. There isn't a one
to one relationship between learning technologies and DITA so I think this
becomes a question of whether we want to try and instill best practice
within the structure itself while maintaining flexibility.

Does this make sense to anybody but myself?  

 	
 	

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Friday, June 26, 2009 12:44 PM
To: john_hunt@us.ibm.com
Cc: dita-learningspec@lists.oasis-open.org
Subject: Re: [dita-learningspec] Design of Learning Map Topicrefs: Why No
Subordinate 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/archive
s/
> 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> 


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