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:
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.
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.
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.
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/
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/
This version of the feature is compliant with the Z39.98-2012 Specification.
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.
This feature makes the following components available for inclusion in host profiles:
input
,
range
,
secret
,
select
,
select1
and
textarea
elements from the
XForms 1.1 Core Form Controls Module
group
and
repeat
elements from
XForms 1.1 Container Form Controls
model
element
Refer to the Z39.98-AI community portal for information on available software tools.
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:
xforms:
is used for Print Forms feature elements.
my:
is used for instance elements.
<!-- -->
) are used in the code examples to identify points of interest and further explain items referenced in the Discussion.
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>
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>
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>
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.