Resource directory for the Z39.98-2012 Authoring and Interchange
Print Forms Feature
version 1.0

Table of Contents

Introduction

The Print Forms feature provides a mechanism with which publishers can define form elements to represent a subset of the various form objects present in print publications.

The form objects are best identified via the two primary use-cases for this feature:

  1. Consumable textbooks (consumables): Consumables are a form of school textbook in which a student is expected to answer and submit questions on the printed page. Traditionally, consumables have provided a significant barrier to accessibility in the classroom.
  2. Print Forms: Print forms are any type of form intended for collecting information for submission. Common examples of print forms include employment applications, survey questionnaires, and order forms.

In addition to defining form elements, this feature provides the functionality of defining methods of submission for the collection of entered information. In the context of Print Forms, submission is broken into two parts: method and instance. The method defines the "type" of submission for the document, with options ranging from saving the form input as a file to transmitting over the network to an author-specified server. Comprised by the <instance> element, the instance information defines the structure of the sent information. This structure is an XML format of the author's choice. For example, a section of a document with form elements for entering a name and date:

      <xforms:input>
      <xforms:label>First Name:</xforms:label>
      </xforms:input>
      <xforms:input>
      <xforms:label>Last Name:</xforms:label>
      </xforms:input>
      <xforms:input>
      <xforms:label>Today's Date (YYMMDD):</xforms:label>
      </xforms:input>

could possibly have an instance structure defined as follows:

      <user date="">
      <firstName/>
      <lastName/>
      </user>

where the "Today's date" information is placed as an attribute for the <user> element, and the "First Name" and "Last Name" information is placed in the <firstName> and <lastName> elements, repsectively.

Including submission-related items is entirely an author-level decision, as many factors of the authoring environment are involved. In general, to determine if submission-related items should be included in a document, both of the following should be true:

As an example, a primary grade textbook which contains form elements only for the purpose of personal inquiry on the reader's behalf would not fit the first criterion above, thus submission-related elements should not be included. However, an employment application form is expected to retrieve information and, in this case, an author would have a set location for retrieving the information (such as the same web server used for acquiring the application's web form analogue).

This feature is maintained by the ANSI/NISO Z39.98 advisory committee under the auspices of NISO.

Normative References

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this section are to be interpreted as described in RFC2119.

General document model requirements

The markup model of this feature is based on a subset of XForms 1.1, and inherits all semantics and behaviors of that specification unless otherwise specified.

Version information

This resource directory represents version 1.0 of the Print Forms feature:

This release may not be the most recently published (current) version of the Print Forms feature. The current version should always be obtained from the static URI: http://www.daisy.org/z3998/2012/auth/features/forms/current/

Identification

This feature must be identified as forms in Z39.98-AI document feature declarations.

The canonical identity URI is: http://www.daisy.org/z3998/2012/auth/features/forms/1.0/

Specification compliance

This version of the feature is compliant with the Z39.98-2012 Specification.

Normative schemata

The normative RelaxNG schema for version 1.0 of the Print Forms feature is z3998-feature-forms.rng.

Note - this feature schema does not represent an entire document model; it is intended for inclusion in host profiles.

The normative schema includes a number of modules and/or subschemas, which are listed in Appendix 1.

Available components

This feature makes the following components available for inclusion in host profiles:

Informative References

Supporting software

Refer to the Z39.98-AI community portal for information on available software tools.

Examples

Each of the following examples depicts a real-world application of the Print Forms feature along with a short reasoning of their formulation.

The following conventions are used in the examples:

Example 1

Print textbook example 1 for use with the Print Forms feature

This example is of a page from a primary grade consumable. The student is expected to answer each of the questions on the print page and submit it to his/her instructor. Since submission is a key part of this example, the optional <model> element and its children are included.

The first two questions are encoded as an <input> element, which represents a free text input, analagous to a HTML text field. The last question is encoded as a <select1> element, which represents a "select one of many choices" input, analagous to a HTML pull-down list field.

Each of the different types of inputs contain an optional ref attribute, which links the user-submitted information to a point in the optional <instance> section.

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.daisy.org/ns/z3998/authoring/" 
  xmlns:xforms="http://www.w3.org/2002/xforms/" 
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:my="http://www.daisy.org/ns/z3998/authoring/xforms/instance/"
  xml:lang="en-US">
  <head>
    <meta property="dcterms:title">Print Forms Feature Example 1</meta>
    <xforms:model>
      <xforms:instance>
        <!--The contents of <instance> indicate the form that the response submission
          should have.  Its structure is defined entirely by the document author.-->
        <my:worksheet>
          <my:questions>
            <my:q1 />
            <my:q2 />
            <my:q3 />
          </my:questions>
        </my:worksheet>
      </xforms:instance>
      <!--The <submission> element provides the information regarding the act of 
        submitting the form.  In this example, when submitted, the form contents 
        will be saved as "page008.xml" on the reader's home computer, populated 
        with the submission questions in structure defined in <instance> (above).-->
      <xforms:submission action="page008.xml" method="put" ref="/my:worksheet" />
    </xforms:model>
  </head>
  <body>
    <h>Multiplication Problems</h>
    <p>For each of these story problems, write an equation and your solution.</p>
    <ol>
      <li>
        <!--The <input> element is required to have the <label> element as a child.
          <label> represents the text content of the question.  On the <input> element
          is the optional "ref" attribute, which specifies where in the submission 
          structure the input value should be placed-in this case, to the <q1> 
          element.-->
        <xforms:input ref="my:worksheet/my:questions/my:q1">
          <xforms:label>There are 2 people who want to eat 3 apples. How 
            many apples are needed?</xforms:label>
        </xforms:input>
      </li>
      <li>
        <xforms:input ref="my:worksheet/my:questions/my:q2">
          <xforms:label>I have 2 pies. Each pie can be cut into 10 pieces. 
            How many pieces are there?</xforms:label>
        </xforms:input>
      </li>
    </ol>
    <section>
      <h>Review Question</h>
      <ol>
        <li>Select the equation that answers the question.
          <!--The <select1> element is structured similar to <input>, in that it 
            has the optional "ref" attribute applied, as well as has the <label>
            element as a child.  In addition, the <select1> also contains an 
            <item> element, comprised of the <label> and <value> elements, which 
            represent each possible choice.  The contents of the <value> elements 
            are the data that is placed into the submission (e.g. A choice of 
            "B. 3 × 6 = ?" would result in <q4>B</q4> being submitted).-->
          <xforms:select1 ref="my:worksheet/my:questions/my:q4">
            <xforms:label>Soda comes in packs of 6 cans. How many cans are there if I 
              have 3 packs?</xforms:label>
            <xforms:item>
              <xforms:label>A. 18 × 3 = ?</xforms:label>
              <xforms:value>A</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>B. 3 × 6 = ?</xforms:label>
              <xforms:value>B</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>C. 3 × 3 = ?</xforms:label>
              <xforms:value>C</xforms:value>
            </xforms:item>
            <xforms:item>
              <xforms:label>D. 6 × 3 = ?</xforms:label>
              <xforms:value>D</xforms:value>
            </xforms:item>
          </xforms:select1>
        </li>
      </ol>
    </section>
  </body>
</html>

Example 2

Print textbook example 2 for use with the Print Forms feature

This example is of a section of a page from a primary grade consumable. As with the previous example, the student is expected to answer the question on the print page and submit it to his/her instructor. Since submission is a key part of this example, the optional <model> element and its children are included.

Of particular note in this example is that the question is actually comprised of two sub-questions (as evidenced by the phrase "show your work"). For the purposes of the example, it is assumed that both sub-questions are required to be answered, with no room for partial credit. Given this assumption, the <bind> element is used, which provides additional rules on submission (in this case, forcing both questions to be answered).

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.daisy.org/ns/z3998/authoring/" 
  xmlns:xforms="http://www.w3.org/2002/xforms/" 
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:my="http://www.daisy.org/ns/z3998/authoring/xforms/instance/"
  xml:lang="en-US">
  <head>
    <meta property="dcterms:title">Print Forms Feature Example 2</meta>
    <xforms:model>
      <xforms:instance>
        <my:worksheet>
          <my:questions>
            <my:q1>
              <my:part/>
            </my:q1>
          </my:questions>
        </my:worksheet>
      </xforms:instance>
      <!--The optional <bind> element allows one to place restrictions on 
        the information to be submitted. In this case, <bind> is requiring
        that there be two (and only two) <my:part> elements on submission.
        Note that each of the form features below reference <my:part> as 
        their sbumission, thus creating two <my:part> elements on 
        submission.-->
      <xforms:bind nodeset="my:worksheet/my:questions/my:q1/my:part" 
        constraint="count(.) = 2"/>
      <!--In this example, instead of saving to file as in Example 1, the 
        form information is submitted to a web server via the "post" method.
        Note: this is very similar to HTML forms.-->
      <xforms:submission action="http://www.example.com/submit/page5.php" 
        method="post" ref="/my:worksheet" />
    </xforms:model>
  </head>
  <body>
    <h>Show Your Work Problem</h>
    <p>Solve the question and show your work.</p>
    <ol>
      <li>
        <!--The <group> element allows an author to logically group
          together different form elements.-->
        <xforms:group>
          <!--The <textarea> element, like most other form elements requires
            the child element <label>, which represents the text of the 
            question.  <textarea> is very similar to the <input> element, 
            in that it is primarily a multi-line input.-->
          <xforms:textarea ref="my:worksheet/my:questions/my:q1/my:part">
            <xforms:label>There are 5 people who want to eat 2 bananas. 
              How many bananas are needed?</xforms:label>
          </xforms:textarea>
          <xforms:input ref="my:worksheet/my:questions/my:q1/my:part">
            <xforms:label>If there are 17 bananas, how many would be 
              left over?</xforms:label>
          </xforms:input>
        </xforms:group>
      </li>
    </ol>
  </body>
  </html>

Example 3

Print textbook example 3 for use with the Print Forms feature

This example is of a section of a page from a primary grade textbook. Unlike the previous examples, the questions posed in the text do not require submission and instead are presented for mental reference. Since answer submission is not necessary in this example, the optional <model> element is not included, leaving only the actual form controls. In addition to not including <model>, the ref attribute, which links form elements to the submission structure, is also not included on the individual <input> elements.

The first section of this example is similar to the previous examples, with two <input> elements. The second section, however, involves some re-formatting of the content. In print, the paragraph is composed of a series of labeled markers which appear inline. Each of these labeled markers correspond to input lines present following the paragraph. In the Print Forms feature, this separation isn't necessary (and may also be confusing in certain circumstances). As such, the form inputs are inserted directly in place of the label markers.

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.daisy.org/ns/z3998/authoring/" 
  xmlns:xforms="http://www.w3.org/2002/xforms/" 
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:my="http://www.daisy.org/ns/z3998/authoring/xforms/instance/"
  xml:lang="en-US">
  <head>
    <meta property="dcterms:title">Print Forms Feature Example 3</meta>
    <!--The <model> element is not included, as there is no need for submission.-->
  </head>
  <body>
    <h>Dancing</h>
    <p>Dancing is fun. There are a lot of different words associated with dancing. The vocabulary 
      list has a number of words already. Add two more dancing-related words.</p>
    <ul>
      <li>exercise</li>
      <li>breathing</li>
      <li>energy</li>
      <li>effort</li>
      <li>
        <xforms:input>
          <xforms:label>Vocabulary list item 1</xforms:label>
        </xforms:input>
      </li>
      <li>
        <xforms:input>
          <xforms:label>Vocabulary list item 2</xforms:label>
        </xforms:input>
      </li>
    </ul>
    <p>Use the vocabulary words (including those you added) to fill in the blanks in the following 
      paragraph.</p>
    <!--In this paragraph, the <input> elements are placed inline, acting as both the input marker
      and the actual input line shown in the text.  In order to improve clarity, the label has 
      been changed from "(1)" to "Blank 1".  Additionally, as submission is not necessary, the 
      optional ref attribute has been omitted.-->
    <p>I've recently found that dancing is great 
      <xforms:input>
        <xforms:label>Blank 1</xforms:label>
      </xforms:input>
      ! When I dance, I start 
      <xforms:input>
        <xforms:label>Blank 2</xforms:label>
      </xforms:input>
      heavily and feel an increase in 
      <xforms:input>
        <xforms:label>Blank 3</xforms:label>
      </xforms:input>
      . It's a lot of 
      <xforms:input>
        <xforms:label>Blank 4</xforms:label>
      </xforms:input>
      , but it's great fun and good for my health.</p>
  </body>
</html>

Appendix 1: Listing of modules in the normative schema

The below list represents the modules at the time of version 1.0 of this feature.

The occurrence of the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in documentation fields embedded in these modules are to be interpreted as described in RFC2119.