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] DITA 1.3 Draft Proposal 13089 - Add learningObjectMapRef and learningObjectMap


I think it's useful to have a learningObjectMap map type, but that map type
can be a very simple integration of the learningMapDomain types with
constrained content models.

Likewise, I think we should have a learningGroupMap and learningGroupMapRef
element.

That then makes everything symetrical and relects a general practice that
I've adopted of having a corresponding map type and map ref for each major
semantic topicref type in a given map domain. You can see this model
reflected in the D4P publication map domain.

In D4P I actually have a separate domain just for map refs, which makes it
easy to allow or not allow the maprefs. That might be appropriate here,
although I'm not sure that level of additional configurability is
warranted--probably better to keep things a little simpler.

Cheers,

E.

On 7/5/12 9:56 AM, "john_hunt@us.ibm.com" <john_hunt@us.ibm.com> wrote:

> Hi Mark and learning sc -
> 
> Below are my initial comments before the discussion at the meeting last week.
> 
> Here's where I am at this point -
> 
> 1) I support adding a learningObjectMapRef element to the learning map domain,
> either by itself or as part of learningGroup.
> 
> a) this content model by itself (in other words, you can only supply a flat
> list of learningObjectMapRef elements in a map -
> 
>         ( (topicmeta) (optional)
> 
> b) this content model when used in a learningGroup -
> 
> ( (topicmeta) (optional) then (learningPlanRef) (optional) then (
> (learningOverviewRef) or (learningPreAssessmentRef) ) (any number) then (
> (learningObject) or (learningGroup) or learingObjectMapRef) (any number) then
> ( (learningPostAssessmentRef) or (learningSummaryRef) ) (any number) )
> 
> 2) We loosen the content model for learningObject, to make all elements in it
> optional, including learningContentRef.
> 
> 3) If we do #2, then I still question the need for new map and bookmap types
> for learningObjectMap - I prefer keeping the learning map elements in the
> domain and integrating the domain into map, bookmap, or other specialized map
> as desired. 
> 
> Thanks to Mark for the good thought he's put into the proposal.
> 
> John Hunt, IBM 
> 
> -------------- 
> Here's my earlier comments on the proposal.
> 
> First, you can do what you want today, using a learningObject href to a
> ditamap, with the issue being you need to include an empty learningContentRef
> to keep it valid.
> 
> For example, this map with href's to separate maps for each learning object -
> 
> <map title="Sample DITA 1.2 learning content" collection-type="sequence">
> <title>Sample DITA 1.2 learning content</title>
> <learningObject href="lc_spec_overviewassump.ditamap" format="ditamap">
>    <learningContentRef/>
> </learningObject>
> <learningObject href="lc_spec_ProbUnstructuredTop.ditamap" format="ditamap">
>    <learningContentRef/>
> </learningObject>
> </map> 
> 
> And this in the lc_spec_overviewassump.ditamap -
> 
> <map title="Sample DITA 1.2 learning content" collection-type="sequence">
> <title>Sample DITA 1.2 learning content</title>
> <learningObject href="lc_spec_overviewassump.dita">
>   <learningContentRef href="lc_spec_overview.dita"/>
>   <learningContentRef href="lc_spec_assumptions.dita"/>
> </learningObject>
> </map> 
> 
> So, I see two options -
> 
> 1) We make learningContentRef optional in learningObject, which would mean you
> could do this - 
> 
> <learningObject href="lc_spec_overviewassump.ditamap" format="ditamap"/>
> <learningObject href="lc_spec_ProbUnstructuredTop.ditamap" format="ditamap"/>
> 
> 2) We add a new learningObjectMapRef to the learning map domain, and make this
> element available by itself, or as a member of learningGroup, like this -
> 
> ( (topicmeta) (optional) then (learningPlanRef) (optional) then (
> (learningOverviewRef) or (learningPreAssessmentRef) ) (any number) then (
> (learningObject) or (learningGroup) or learingObjectMapRef) (any number) then
> ( (learningPostAssessmentRef) or (learningSummaryRef) ) (any number) )
> 
> 
> We may actually want to do #1 anyway.
> 
> Then, #2 makes this option more explicit, but do we really need it? Plus, I'm
> not sure there's a way to constrain the learningObjectMapRef to *just* point
> to a valid learningObject. I just did a couple of quick experiments with DITA
> OT, and found that the learningObject href can actually point to any map
> structure at all - including any random map with topicref's - so when using
> these map references, I wonder what validity rules we expect should apply?
> 
> Finally, I'm not sure I sure any reason that we would want to add a
> learningObjectMap element. First, this would imply a new map type. Right now,
> we don't actually have a learning map type, per se - we just have variations
> of map and bookmap that include the learning map domain.
> 

-- 
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]