[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Proposal for 1.3 specification on lcQuestion
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" <amberswope@gmail.com> 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: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] 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" <joann.hackos@comtech-serv.com> 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 >> joann.hackos@comtech-serv.com >> 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.rsuitecms.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: dita-help@lists.oasis-open.org > > -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]