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&T InteractionElements
- From: john_hunt@us.ibm.com
- Date: Fri, 17 Jul 2009 14:22:28 -0400
now sorry I brought up the common elements
in base...
Maybe we keep it simple.
sounds like the real issue gets addressed
by the single new base element for grouping the interactions. then if you
specialize from the learningDomain, you get those common elements and each
of the 7 interactions, too.
if you want to branch off into your
own set from that base, you can do that freely without any incumberances
from the common elements
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 01:18 PM
|
Subject:
| Re: [dita-learningspec] Proposal: New
Base Class for all L&T Interaction 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>
---------------------------------------------------------------------
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]