ZedAI XForms QTI

From zedwiki

Forms for ZedNext

Contents 1 Overview 2 XForms 2.1 Discussion 2.2 XForm Elements 2.2.1 Core Module 2.2.2 Extension Module 2.2.3 Core Form Controls 2.2.4 Container Form Controls 2.2.5 Actions 2.2.6 Submission Module 2.3 Useful links 3 QTI 3.1 Discussion 3.2 Useful Links 3.3 Summary 4 XForms and QTI Examples

Overview

Several use cases are not well addressed by the current DAISY spec.

1. Workbooks or homework for students
2. "traditional" forms such as tax forms and surveys
3. quizzes and tests

Adding some type of "forms" capability will cover most of these cases.

XForms and QTI are two XML applications that are possible solutions.

XForms

Discussion

XForms 1.1 is the version we consider for use. This is the latest version of XForms and is in currently in Candidate status.

Three characteristics of XForms are particularly germane for use in DAISY:

1. Unlike HTML forms, XForms separates the information regarding submission of the form data from the presentation of the controls. Submission information, which includes the declaration and format of the data, is contained in the model element.
   When XForms are used in XHTML, the model element is placed in the head element. Xforms input controls appear in the body element (of course). A particular input control "belongs" to exactly one model element.
2. The instance element (contained in a model element) can be used to define an XML template for the data submission.
3. Unlike HTML forms, each input control requires a label. The W3C Forms WG included this requirement expressly to increase the accessibility of the control.

Many of the XForms elements are probably not appropriate for use in the Authoring stage of a ZedNext document. XForms in its full implementation is designed to replace the dynamic functionality afforded by AJAX. This dynamic rewriting of content at presentation time should be addressed in the ZedNext Deployment phase and not in the Authoring phase. Therefore, we must limit the use of some XForms features when authoring ZedNext documents.

• Advantages

1. can be simple
2. handle most use cases
3. easy to learn if familiar with HTML forms
4. limited set of controls reduces decision complexity
5. can transform to HTML forms for simple cases

• Disadvantages

1. Many features are not appropriate for "book content"
2. Some common workbook features cannot be easily handled
3. full specification is complex
4. not widely implemented

XForm Elements

Below is a table of all the XForms elements and first draft recommendations for use in ZedNext. They are divided in categories such as Core Module, Submission Module, etc. as defined by the XForms 1.1 Recommendation. Further discussions are necessary.

Core Module

Element	Recommended	Notes
model	optional	The core modules all related primarily to submission, which may be out of scope. Their inclusion should not, however, cause any issues (and would be very beneficial for many applications)
instance	optional
bind	optional

Extension Module

Element	Recommended	Notes
extension	not recommended	At it's base, extension could be very useful, however, the wholesale incorporation of other namespaces will most likely cause issues. Restricting extension to certain namespaces may be worthwhile (e.g. to achieve items similar to the example in the XForms specification)

Core Form Controls

Element	Recommended	Part of Minimal Set	Notes
label	recommended	yes
hint	recommended	no	This causes no real issues with our format, but its nature may be out of scope. While there are situations in book content where items have "hints" associated with a question, I feel it is semantically different than the corresponding XForms items, as its default represenation is as a transient item.
help	recommended	no	Similar to <hint>.
alert	not recommended	no	This is very similar to <help> and <hint>, but its nature is less in-scope.
item	recommended	yes
choices	recommended	yes
value	recommended	yes
input	recommended	yes
secret	recommended	yes	This has interesting ramifications for audio playback.
textarea	recommended	yes
upload	not recommended	no	This is beyond the book content scope.
filename	not recommended	no	Child of <upload>, therefore out of scope.
mediatype	not recommended	no	Child of <upload>, therefore out of scope.
select1	recommended	yes
select	recommended	yes
range	recommended	yes
trigger	not recommended	no	Functionality is primarily intended for dynamic events in the form, which is beyond book content scope.
output	not recommended	no	Since we're narrowed to representation of book content, this dynamic item isn't necessary. Additionally, the injection of user-supplied content into book content will cause difficulties in audio playback (out of scope of ZedAI, but important, nonetheless).
submit	optional	no	Similar to the Core Module elements.

Container Form Controls

Element	Recommended	Part of Minimal Set	Notes
group	recommended	no
switch	not recommended	no	This is beyond the book content scope (conditionally choosing which controls to display).
case	not recommended	no	Child of <switch>, therefore out of scope.
repeat	recommended	no	This could be very useful and reduce document size in a number of situations, however, it's problematic if used in a dynamic way.
itemset	recommended	no	This is very similar to <repeat> -- it could be useful, however it will introduce problems if used dynamically.
copy	recommended	no	Child of <itemset>, with similar issues.

Actions

This whole section is similar to <repeat>--if these elements were restricted to only perform on initial load (and in the same way every time--i.e. no conditionality), it wouldn't be problematic. However, I don't think it will be possible to just strip out that event case, stripping out all these elements would be best. This is particularly true since all of their "book content"-related functionality is doable in other ways.

Element	Recommended	Notes
action	not recommended
setvalue	not recommended
insert	not recommended
delete	not recommended
setindex	not recommended
toggle	not recommended
setfocus	not recommended
dispatch	not recommended
rebuild	not recommended
recalculate	not recommended
revalidate	not recommended
refresh	not recommended
reset	not recommended
load	not recommended
send	not recommended
message	not recommended

Submission Module

The entire Submission Module is similar to the Core Module elements.

Element	Recommended	Notes
submission	optional
header	optional
name	optional
value	optional
resource	optional

Useful links

XForms 1.1 Candidate Recommendation - The root document for XForms 1.1 specification.

XForms Tutorial for HTML Authors - Great "quick-start" style intro to XForms

W3C Forms Working Group main page - Contains many useful auxiliary links and info

QTI

Discussion

The QTI (Question & Test Interoperability) Specification is a model for representing question and test items, as well as the corresponding results. QTI has been developed to aid content authors and developers of assessment systems in presenting and storing materials and is very used very heavily in online assessment systems (Reference Pearson VUE's case study: http://www.imsproject.org/question/qtiPearsonCaseStudy.pdf).

Modern day workbooks and tests aren't limited to simple interactions (i.e. enter a string, select a checkbox), but instead have a wide variety of interactive controls (drawing lines, identifying sections of normal text, etc.). Since QTI is designed specifically for these applications, almost all workbook/test questions can be represented. Various examples of these controls can be found in the QTI Implementation Guide (http://www.imsproject.org/question/qti_v2p0/imsqti_implv2p0.html).

As QTI is designed in a modular manner, such that each question is represented as a discrete object, with a "test" being a collection of "items", allowing re-use of items and customized/adaptive tests. This functionality, however, is one of the biggest drawbacks to its incorporation in ZedNext. Since each "question" (which represents one or more directly related input items and reference material) must be grouped together, there are many instances where large sections of a page would be enclosed in a QTI island. For example, a workbook page with an article and instructions to mark a certain concept--ideally, this would be encoded primarily in the document's source format, with only the question itself in QTI, but due to QTI's nature, the entire article and the question would be part of the QTI island.

• Advantages

1. mature spec
2. embraced by major educational publishers
3. intended to handle all types of questions

• Disadvantages

1. no third party renderer/processing engine
2. steep learning curve for those new to XML
3. not designed to be part of a compound document

Useful Links

QTI Spec and other links - main QTI specifications and other links

Pearson case study - actual use case of QTI

QTI Examples - contains many examples of QTI items

Summary

Including QTI items as part of a DAISY book is quite problematic. The QTI spec is really a file format. Consequently, QTI items cannot easily appear as islands in a non-QTI file. Primarily for this reason, QTI does not seem suitable for use in DAISY files.

XForms and QTI Examples

Here are several examples from actual workbooks and tax forms. The examples show the use of both XForms and QTI.

• Example 1 (IRS Form W-4 2009)
• Example 2
• Example 3
• Example 4
• Example 5 (QTI Only)
• Example 6 (QTI Only)
• Example 7 (QTI Only)
• Example 8
• Example 9
• Example 10