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