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] Proposal: New Base Class for all L&TInteraction Elements


On 7/17/09 12:09 PM, "john_hunt@us.ibm.com" <john_hunt@us.ibm.com> wrote:

> So, if we go the route of including commonly used elements in the base,
> then we might consider these:
> 
> lcQuestion
> lcAsset
> lcFeedbackIncorrect
> lcFeedbackCorrect
> lcCorrectResponse
> lcFeedback
> 
> John
> 
> 
> 
> 
> From:
> Eliot Kimber <ekimber@reallysi.com>
> To:
> <john_hunt@us.ibm.com>
> Cc:
> "dita-learningspec@lists.oasis-open.org"
> <dita-learningspec@lists.oasis-open.org>
> Date:
> 07/17/2009 11:58 AM
> Subject:
> Re: [dita-learningspec] Proposal: New Base Class for all L&T Interaction
> Elements
> 
> 
> 
> On 7/17/09 10:35 AM, "john_hunt@us.ibm.com" <john_hunt@us.ibm.com> wrote:
> 
>> Hi Eliot,
>> 
>> I think the proposal has good merit, and can see the need for a common
>> base for additional interaction specializers.
>> 
>> If I understand correctly:
>> 
>> * Specializers could add entire new interactions from this base, while
>> keeping the interactions within the global set defined by
>> lcInteractionBase.
>> 
>> * Specializers could also specialize from learningDomain if they want to
>> use elements already defined there, such as lcFeedback, etc.
> 
> Your understanding is correct.
>  
>> Do I correctly conclude that there is no need to include elements such
> as
>> ldFeedback in the base?
> 
> Ah, are you saying push the feedback types down into base since they are
> common across the interaction types?
> 
> Yes, that makes sense--should have thought of that.

That would be the list.

However, thinking about it more, the problem with doing this is that it
*does* change the class specs for those types because they would no longer
be part of learningDomain. That change would not be backward compatible with
any existing processing that handles those types.
 
So that would be an argument to keep them where they are.

The alternative would be to define base types of each of those from which
the elements in learningDomain are then specialized, e.g. "lcFeedbackBase".

I'll have to review the 1.2 specialization rules to make sure my
understanding of the possible relationships between domain modules is
correct--it may be that there's a third option I haven't considered.

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]