John,
I'm certainly interested in any new L&T SC meetings.
Cheers,
E.
On 1/24/12 7:26 AM, "" <> wrote:
> Hi Eliot, Amber, JoAnn, and all -
>
> First, I appreciate the good active interest in these DITA Learning and
> Training question interaction types.
>
> As you know, the sub-committee has officially been in hiatus since the release
> of DITA 1.2.
>
> However, given the issues raised about the question interactions, and other
> issues that may have come up in other uses of the L&T specialization, I'm glad
> to facilitate a short series of focussed sub-committee meetings to discuss
> these question interaction issues and open the floor to other issues as well.
>
> Please get back to me if you have interest in participating in these meetings,
> and I'll look to arrange a mutually-good meeting time.
>
> Thanks.
>
> John
>
>
> John P. Hunt
> Senior Technical Content Architect
> IBM Collaboration Solutions | User Experience: Design and Information
> Excellence
> john_hunt at us.ibm.com
> Join our community
> <https://greenhouse.lotus.com/wikis/home?lang=en_US#/wiki/W6696b8ac7465_4a5f_9
> 327_94f1a5d82132> | Team blog
> <https://greenhouse.lotus.com/blogs/lotustechinfo/?lang=en_us> | Product
> Wikis <http://www.lotus.com/ldd/wikis>
> 550 King Street
> Littleton, MA 01460
> USA
>
>
>
>
> From: Eliot Kimber <>
> To: Amber Swope <>, JoAnn Hackos
> <>, dita <>
> Date: 01/23/2012 01:46 PM
> Subject: Re: [dita] Proposal for 1.3 specification on lcQuestion
> Sent by: <>
>
>
>
>
> Amber,
>
> That's useful feedback. Could you perhaps provide some guidance on how to
> interpret the QTI spec? I was having a hard time understanding how the
> components of the QTI interaction items corresponded to the parts of a
> question. For example, it wasn't clear if itemBody encompassed all the parts
> of the actual question (that is, the prompt and the possible responses) or
> just the possible responses.
>
> I'd be interested to see how you would change the current assessment markup
> to better match the QTI model--we could always propose a new set of
> assessment types for DITA 1.3. Unfortunately we couldn't specialize them
> from the current interactionBase type, so we'd have to create a parallel
> specialization hierarchy, but I think that's a minor issue relative to the
> value of having a more accommodating content model.
>
> I also agree that specializing from a base other than <fig> would be
> helpful. However, the current bodydiv/sectiondiv dichotomy (see my recent
> post on this problem) would make that problematic without a new more-generic
> div type.
>
> Cheers,
>
> E.
>
> On 1/20/12 11:02 AM, "Amber Swope" <> wrote:
>
>> Hi there,
>>
>> I have some experience with the L&T specializations and believe that the
>> QTI-issue is a bit misunderstood. QTI has a totally different structure and
>> the mapping from one element to its corresponding element in the other
>> specification can be ambiguous. That said, QTI does accommodate multiple
>> paragraph content, such as a stem and stimulus, for a single interaction,
>> and unfortunately, the DITA L&T specialization does not.
>>
>> For example, if you are mapping <lcQuestion> to <prompt>, then the single
>> paragraph limitation makes sense. However, QTI also supports additional
>> elements, such as <p>, within the <itembody> element. This is how you can
>> have multiple paragraph-level items in a single interaction. (and support
>> most open questions...)
>>
>> DITA also has additional limitations to have content only contain one
>> paragraph, including feedback information, which in QTI is structured with a
>> <feedbackBlock> element that allows multiple paragraphs.
>>
>> Another point is that all the interactions are specialized from <fig>, which
>> I believe was the only available element that met most of the requirements
>> in DITA 1.1. If the L&T team were to create the specialization today, they
>> would have been able to use the <*div> elements that are now available in
>> DITA 1.2.
>>
>> As Eliot notes below, you must extend the specializations with another
>> element that allows multiple paragraph-level elements. We did something
>> similar for a client to accommodate all the locations in a question where
>> you need to present multiple paragraph-level items. Given that QTI has a
>> structure for handling the multiple paragraph constructs, I think that the
>> requirement as it is currently presented to be a red herring.
>>
>> It seems to me that unless the DITA spec is updated to provide the necessary
>> support, each implementation will have to meet these requirements and teams
>> will do so in an inconsistent manner. How to address the situation is up to
>> the committee.
>>
>> A
>>
>> -----Original Message-----
>> From: [mailto:
>> <mailto:> ] On Behalf
>> Of Eliot Kimber
>> Sent: Thursday, January 19, 2012 5:43 PM
>> To: JoAnn Hackos; dita
>> Subject: Re: [dita] Proposal for 1.3 specification on lcQuestion
>>
>> The issue, as I understand it, is that IMS-QTI, which the learning
>> assessment markup tries to be consistent with as much as possible, does not
>> allow multiple paragraphs within the question prompt.
>>
>> The way I've worked around this to date is to create a wrapper element,
>> e.g., <question>, that contains whatever block-level elements you want and
>> then any specialization of lcQuestionBase you want, e.g.:
>>
>> <!ENTITY % question.content
>> "(%RSuiteMetadata;,
>> (p |
>> image |
>> table |
>> simpletable |
>> fig |
>> ol |
>> ul |
>> lq)*,
>> (%lcTrueFalse; |
>> %lcSingleSelect; |
>> %lcOpenQuestion;
>> )*,
>> (%lcFeedback;)*,
>> q_meta?
>> )
>> ">
>>
>> Whether or not the concern with IMS-QTI is still valid I don't know. If it's
>> not then I would agree with allowing blocks within lcQuestion as you
>> suggest.
>>
>> Maybe John Hunt can provide more insight into the design?
>>
>> Cheers,
>>
>> E.
>>
>> On 1/19/12 5:27 PM, "JoAnn Hackos" <> wrote:
>>
>>> Hi All,
>>> I would like to propose that we add to the list of elements available
>>> in the L&T specialization of the assessment, namely lcQuestion.
>>>
>>> lcQuestion needs to contain <p>, various lists, programming and
>>> software elements, etc. At present, lcQuestion primarily contains
>>> highlighting elements.
>>>
>>> The relevant examples are below:
>>>
>>> Regards,
>>> JoAnn
>>>
>>> JoAnn T. Hackos, PhD
>>> President
>>> Comtech Services Inc.
>>> 710 Kipling Street, Suite 400
>>> Denver, CO 80215
>>>
>>> skype joannhackos
>>>
>>>
>>> Here is an example from our book:
>>>
>>> We had to code the question as follows:
>>> <lcQuestion>What is wrong with the following code?
>>> <image href=²examplecode.jpg²></lcQuestion>
>>>
>>> We would have liked to have coded it:
>>> <lcQuestion>What is wrong with the following code?
>>> <codeblock><property>
>>> <prophead>
>>> <proptypehd>Character graphic</proptypehd>
>>> <propvaluehd>Code Point</propvaluehd>
>>> <propdeschd>Description</propdeschd>
>>> </prophead>
>>> <properties>
>>> <proptype>A</proptype>
>>> <propvalue>41</propvalue>
>>> <propdesc>A capital</propdesc>
>>> </properties>
>>> <properties>
>>> <proptype>a</proptype>
>>> <propvalue>61</propvalue>
>>> <propdesc>a small</propdesc>
>>> </properties>
>>> </property>
>>> </codeblock></lcQuestion>
>>>
>>> As another example, some questions might need a scenario set up where
>>> you want to have multiple paragraphs, which is also not allowed. For
>>> example,
>>>
>>> Jane is taller than Bob.
>>> Greg is shorter than Bob.
>>> Bill is shorter than Jane, but taller than Bob.
>>> Which of the following is true:
>>> a) Greg is taller than Jane.
>>>
>>> b) Bill is taller than Greg.
>>>
>>> c) Bob is the shortest person mentioned.
>>>
>>>
>>> You could not code this question to format as we¹ve shown. It would
>>> have to currently be one paragraph.
>>>
>>> <lcQuestion> Jane is taller than Bob. Greg is shorter than Bob. Bill
>>> is shorter than Jane, but taller than Bob. Which of the following is
>>> true:</lcQuestion>
>>>
>>> But we¹d rather be able to code:
>>> <lcQuestion><p> Jane is taller than Bob.</p> <p> Greg is shorter than
>>> Bob. </p> <p>Bill is shorter than Jane, but taller than Bob. </p>
>>> <p>Which of the following is true:<p></lcQuestion>
>>>
>>>
>>> Or you might have a list within the question, like a logic problem.
>>> There¹s no way to include any type of list.
>>> For example, how would you code the following without a list element
>>> in the question?
>>>
>>> Figure out the day of the week, first name, actor and cell phone for
>>> each person using the clues given. Below are all categories and
>>> options used in this puzzle.
>>> 1. Kevin Bacon's cousin is not Conor.
>>>
>>> 2. The person who arrived on Friday doesn't have a cell phone with
>>> Verizon.
>>>
>>> 3. The five individuals are the person who arrived on Wednesday,
>> Conor,
>>> the person who arrived on Friday, the person with the nTelos cell
>>> phone and John Travolta's cousin.
>>>
>>> 4. Kassidy arrived sometime before Danielle.
>>>
>>> 5. The person with the nTelos cell phone is not Danielle.
>>>
>>> 6. Neither Bruce Willis's cousin nor the person with the nTelos cell
>>> phone is Felix.
>>>
>>> 7. John Travolta's cousin arrived sometime before the person with the
>>> Verizon cell phone.
>>>
>>> 8. The person with the Cingular cell phone is not Felix.
>>>
>>> 9. Kassidy arrived the day after Conor.
>>>
>>> 10. Robert De Niro's cousin is not Kassidy.
>>>
>>> 11. Conor has always used Nextel.
>>>
>>> 12. Of Felix and Danny DeVito's cousin, one has always used nTelos
>>> and the other arrived on Monday.
>>>
>>> 13. The person who arrived on Tuesday isn't related to Robert De Niro.
>>>
>>>
>>>
>>
>> --
>> Eliot Kimber
>> Senior Solutions Architect
>> "Bringing Strategy, Content, and Technology Together"
>> Main: 512.554.9368
>> www.reallysi.com <www.reallysi.com>
>> www.rsuitecms.com <www.rsuitecms.com>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>>
>>
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com
