NOTE: This wiki is provided by the OASIS standards consortium as a collaborative tool for the OASIS DITA Learning and Training Content Specialization Subcommittee. Members of the Subcommittee are permitted to post to these pages (SC Members Page). As this is an official workspace of the TC, the OASIS IPR Policy and other OASIS rules apply to its use.

To learn more about the work of the Subcommittee, send a comment, or join this effort, visit the OASIS DITA Learning and Training Content Specialization Subcommittee homepage. Prospective members of the subcommittee must first join the OASIS DITA Technical Committee (TC Members Page).

Wiki pages are transient documents, so intermediate edits may not be saved. SC members should move all permanent work and stable artifacts to the SC's document repository, where the archival work product of the SC also can be viewed by the public.

Samples and discussion about updating spec for lcQuestion and related interactions

Background on Interactions Domain in DITA 1.2

DITA 1.2 includes a Learning interactions domain.

Agenda for Mar 1 SC meeting discussion

JPH - Here's my proposed agenda and roadmap for our discussion.


Please add discussion points about issues in adding new specialization support for questions with multiple blocks.

Titles for Questions

[WEK] Amber and I are both wondering how strong the requirement is for individual questions to have titles? Is there more documentation or history on this requirement?

If individual questions did not have titles then the new DITA 1.3 <div> element could replace <fig>, but if titles are a hard requirement then it cannot as <div> explicitly does not allow <title>

[WEK] One of my clients has the notion of "titles" for questions, but as far as I can tell from analysis of their legacy content, these "titles" are really classifying metadata that either reflects the general subject to which the question applies (e.g., "Sport Public Relations Programs") or the title of the section from the textbook to which the question applies. In neither case is this a title for the question in the sense that DITA means titles for topics or sections. Evidence of this is the fact that many questions in the same test may have the same or essentially identical titles.

They did say that titles are required by at least one of their interactive learning systems, but in that case the output title could come either from metadata within the question or from a title inherited from a grouping element (a titled section or topic that contains the questions).

This does, however, point up the need for the base model to allow for <data> anywhere that it could possibly be allowed, since being able to classify individual questions according to subject taxonomies or learning standards taxonomies is very important for some publishers (such as my first L&T-using client, Triumph Learning, who make test prep manuals for U.S. primary and secondary education--classifying questions by state standards and subject areas is of prime importance).

[ARS] my clients do not have titles for questions and they simply end up leaving the title element empty and rely on metadata and GUID for finding and identifying questions.

Managing Individual Questions as Objects

[WEK] Amber and I both have the general client requirement of managing individual questions as objects that can be used in multiple contexts. Amber also has the requirement to be able to use maps to construct sets of questions, e.g., for tests. I haven't had that specific requirement but in thinking about Amber's requirement started to realize that I very well might prefer to manage questions in that way, or at least have the option.

The unescapable implication for this is that you must have a topic that either is or contains a single question. Which then raises the issue of what to do with the topic's required title?

The base question element can't itself be a topic--that would be too limiting. So that suggests a separate topic type specifically intended to be a "transparent" holder of questions, meaning that the topic title is present but empty (although it might have a navtitle or search title) and thus the topic wrapper would not contribute to normal output results.

Such a topic would also be convenient as a holder of questions to be used via conref, which of course is always an option. But I can see the appeal of doing all your content aggregation in maps.

Does this idea seem sensible? I can't think of another solution that works within the DITA 1.x architecture.

For DITA 2.x we might start to consider the notion of an untitled unit of content that can be referenced directly from maps, but not going to suggest that for DITA 1.x.

[ARS] we're currently creating a single interaction per file and organizing the question sets for test and quizzes with standard maps. When we leave the title element empty, it makes organizing the maps very difficult because they all have the same "Untitled topic" listed in the map. There is a requirement to manage the question files individually for metadata and usage tracking purposes.

Using maps to organize interactions makes it much easier to support question set with shared information. For example, if there are three questions about a single image, then we can include the shared information in a separate topic and then add references to the file with the image and explanatory text and to each of the files that contain the interactions.

General Constraints on Specialization

The general constraints on specialization that affect us here are:

1. We can't retroactively change the specialization hierarchy of existing element types, as that could break tools that key off of specific types or for some reason make assumptions about the current hierarchy. I doubt there actually are such tools but we have no way of knowing. This means we can't change the current specialization hierarchy of lcInteractionBase from topic/fig to something else.

2. The current lcQuestionBase specializes from <p>, so at a minimum we would need to create a new question base element that specializes from <div> so that it can hold multiple para-level elements, e.g. lcQuestionDivBase or something.

3. Likewise, lcAnswerContent and the lcFeedback* elements all specialize <p>, so would need new alternatives that specialize <div>

New Sorting Question Type

[WEK] While I'm sympathetic to the need for sorting as a question type, my concern is that it represents a slippery slope of question types for which there are many possible designs and no obvious best one, depending on requirements. For the built-in types the design is pretty obvious--there's only so many ways you can structure a single-select or true/false question. The lcInteractionBase type is there specifically to enable creation of new interaction types that are still clearly semantically interactions and not just some random specialization of <fig>. If we can reach consensus on what the structure of a sorting question is, then I'd support it, but if we can't I would prefer to leave it for local specialization and perhaps provide a white paper on how one might go about developing such a specialization. I worked with a client who uses quite sophisticated interactions, including sorts, but it seemed clear to me that their particular solution was driven more by the implementation details of their interaction delivery system (that is, the Flash code they'd written) than by some abstract design and would probably not generalize in a satisfying way.

[ARS] We have specialized a sorting question and given the structure a great deal of analysis, which the client has agreed that we can share. A sort question has a set of items that are identified with one or more categories. The usual presentation is list of items and labeled columns into which the student organizes the items; in some cases the item may apply to more than one category or none of the categories.

We investigated using a table structure similar to the Match Table where the item set would be in the first column and each of the target lists would be in subsequent columns. However, sort questions can have a categorized list of items and you cannot have sub headings rows in CALS tables; therefore, we ruled out using tables for the structure.

Instead, we created a question structure similar to sequence and included identifying elements for the sort target labels. We're not thrilled with it, but it meets our needs.


Please add your samples of questions and use cases that require the use of multiple blocks in the content for the questions, answers, and feedback elements.

Questions with multi-block prompts

[WEK] Here is an example from a Triumph Learning test prep document. The tags are specialized but the mapping to base L&T types should be obvious:

This question is typical of their questions. The <question> element is my invention and is similar to solutions developed by Amber for binding multiple blocks to the base question. Today I would specialize <question> from <div> but at the time my only choice was <section> since there was no other wrapper element in DITA at that time (before the invention of <sectiondiv> or <bodydiv>) that could hold both <fig> and multiple block-level elements.

Here is a question that includes classifying metadata:

The <q_meta>, <classification>, and <standard> elements all specialize from <data>

[ARS] Here are some sample questions from Kaplan Publishing

Essay Question with Open Question

We specialized a separate element for question to contain our multi-element question element. This sample also shows our specialized element for explanation.

Single Select


I will add more samples later.

LearningContent/lcQuestion (last edited 2012-03-01 15:49:36 by john_hunt)