Keywords: XForms, Enterprise Applications, Enterprise Content Management, Digital Signatures, Web Services, eCommerce, E-Government, E-business, Application Architecture
Biography
John M. Boyer is a Senior Product Architect and Research Scientist at the IBM Victoria Software Lab. Since 1993, John has worked to design and implement an XML-based platform for secure and robust web form applications. John has co-authored and edited numerous W3C Recommendations, including XML Signatures, XML Canonicalization and Exclusive Canonicalization, XPath Filtering, and XForms. In 2001, John earned his Ph.D. in theoretical computer science (University of Victoria, Canada). He has published numerous refereed journal and conference papers and professional papers on algorithmics, computer security and XML-related technologies.
This paper describes a platform for the XML definition of secure, intelligent web-based applications. XForms provides a powerful model-view-controller (MVC) pattern that may best be described as a cause-and-effect processing model originated by XFDL. This paper describes a new version of XFDL that consumes, or skins, XForms. Hence, this paper presents the first integration of a standardized markup for expressing the core processing of a web-based form application (XForms) with a host language (XFDL) that offers security, precision presentation, a document-centric capability, and other features that contribute to a more rich user experience.
1. Introduction
1.1 XForms and the Model-View-Controller Pattern
1.2 Host Languages Provide Presentation Layers for XForms Views
1.3 XFDL as a Host Language for XForms in IBM Workplace Forms
2. The Structure of XFDL Documents
2.1 Pages, Items and Items within Items
2.2 Options and Suboptions
2.3 Computes, Extension functions, CSS
2.4 Applying Computes with Foreign-Namespaced Elements
3. The XFDL Skin for XForms
3.1 The General Notion of a 'Skin'
3.2 Location for XForms Models
3.3 XFDL Skin Items for Atomic XForms Controls (Widget Library)
3.3.1 The label Item Skins xforms:output
3.3.2 The field Item Skins xforms:input, xforms:secret, and xforms:textarea
3.3.3 The popup, list, radiogroup and checkgroup Items Skin xforms:select1
3.3.4 The list and checkgroup Items Skin xforms:select
3.3.5 The check Item skins xforms:input
3.3.6 The combobox Item skins xforms:select1 and xforms:input
3.3.7 The slider Item Skins xforms:range
3.3.8 The button Item Skins xforms:upload
3.3.9 The button and action Items Skin xforms:submit and xforms:trigger
3.3.10 Custom Items
3.4 XFDL Skin Items for Grouping, Switching and Repeating Controls
3.4.1 The pane Item Skins xforms:group and xforms:switch
3.4.2 The table Item Skins xforms:repeat
3.5 The Effects of XForms Constructs on the XFDL Presentation Layer
3.5.1 Single node binding and the value option
3.5.2 The xforms:label Affects the XFDL label and acclabel Options
3.5.3 The xforms:hint and xforms:help Affect the XFDL help Option
3.5.4 The xforms:alert Affects the format Option's message Suboption
3.5.5 The readonly MIP Affects the readonly Option
3.5.6 The required, type and constraint MIPs Affect the format Option
3.5.7 The relevant MIP Affects the visible and active Options
3.5.8 The Effects of xforms:group, xforms:switch and xforms:repeat on itemlocation
3.5.9 On the Transience of Options in XFDL Items that Skin XForms Controls
4. Advanced Issues
4.1 A Repeat Methodology for Persisted Data
4.2 Accessibility
4.3 Preserving the Selected Case of a Switch
4.4 Support for Switch in Repeat and IDREF into Repeats
4.5 Rich Text Support
4.6 Label and Button Images from XForms Instance Data
4.7 Attachments, Organized and Compressed
4.8 Calling Web Services
4.9 Digital Signature Security and Transaction Non-Repudiation
4.10 Full Document Submission, Computable URL, and Server-Side Responsibilities
In 1998, the W3C recommended XML as a grammar for defining interoperable software systems. Later the same year, an XML vocabulary named XFDL (the Extensible Forms Description Language) was published as a W3C Note, informing the W3C community of the need to standardize the next generation of secure, intelligent web-based forms applications. The key insights were that
The information processing needs of these so-called sophisticated forms are as complex as for any application, but what makes a language desirable in a particular application domain is the set of languages features that advantage that domain. A form provides a rich user experience for the presentation of information and gather of responses to that information.
In order to begin to meet the standardization challenge for this important class of web applications, the W3C XForms Recommendation presents an open platform for expressing the core model-view-controller (MVC) layers of forms applications. The model expresses an XML data processing framework that includes
The view layer of XForms provides intent-based data access form controls as well as hierarchy and iteration constructs that allow the viewer layer to access nested data and data sequences in the model. The distinction between a model view and a presentation layer is discussed further in the next section on host languages.
The controller layer of XForms provides the ability to listen for events and execute imperative action sequences that manipulate the model or a view (or both). It is interesting to note that, in XForms, the controller manipulations are not backed by a passive data model but rather by a active processing model that enforces a set of declaratively expressed business rules for the data. Hence, the business rules expressed in the XForms model extend the semantics of the controller layer actions. Moreover, an implicit aspect of controller layer actions is an update of the view layers that includes not only updated values but also dynamic response by iteration constructs to structural changes in the data.
I refer to this interplay between the model, view and controller layers as a cause-and-effect paradigm. The active participation of the model and views in the controller's data manipulations is made possible by a declarative style of expressing binding relationships with XPath.
The purpose of the XForms controls is to provide data access views of the model to containing applications. The most obvious view, of course, is a presentation layer for rendering the form to an end-user, and the XForms controls can indeed be used directly by a minimalist rendering engine. However, the intent of the XForms design is to allow sufficient abstraction so that XForms forms can be hosted by a XML-aware container applications that consume model views and augment them according to application-specific requirements.
At the horizon of the abstraction, model views could be created and used to drive back-end processing of data, for example. Generally, though, the primary goal of the view abstraction in XForms was to allow it to be skinned by (incorporated into) other host languages in order to meet the many diverse requirements that arise on the world wide web. One obvious host language is XHTML, but VoiceXML could be used to satisfy advanced accessibility needs, and WML (or minimalist rendition) could be used on small devices.
The XFDL language is focused on providing rich user experience in forms that appear in the business or enterprise context, which often has more stringent usability requirements than the general web context. The enterprise context tends to be an iteration over the business context; some requirements are needed by every business form while others are only needed in some forms. An example requirement from the business context is the need to present double precision numbers as formatted currency values, respecting locale issues. This includes rules for large number deconstruction, the symbol for the decimal place mark, the rules for the choosing the location and symbol of the currency mark, and rules for decimal place truncation or rounding. In XFDL, the presentation can be declared to a currency format; by default this converts an XForms data value like 10272.897814616084 to $10,272.90 in the presentation. Aside from the information processing requirements of forms in the general web context, the most common requirements in the business context are
Of particular interest are the benefits associated with the use of a document-centric architecture in XFDL-based systems. In a data-centric application, the data is bound to the MVC and presentation layers ephemerally. XFDL, on the other hand, skins the cause-and-effect MVC layers of XForms with a precision presentation layer in the same document. The full XFDL+XForms document, then, is the XML serialization of both the form application and its current state. This has several advantages for end-users and application developers. Attachments can be added, input can be provided over an extended period of time, and digital signatures can secure all or required parts of the form, including not only the data but also its precision presentation. The end-user can be empowered to save the full document locally to disk and work offline or email the document to collaborators in an ad hoc workflow. The form remains a powerful collaboration tool even in formalized workflow. Once a form is completed, the full document can be archived in a records management system for transactions auditability, and the XML data can easily be harvested from the surrounding XML document to drive back-end data processing systems.
In essence, the form document becomes the fundamental unit that traverses the business process collecting all information related to a transaction. The application developer can focus on how the data related to a transaction must flow through a system without the distraction of having to architect the delivery of application fragments related to the transaction. This is analogous to the efficiency gain derived from programming in an object oriented language instead of a procedural language.
This paper describes the first integration of XForms with a host language, XFDL, that is enabled with document-centricity and other capabilities that satisfy the full spectrum of requirements from the business context. The remainder of this paper presents an overview of the XFDL document structure, a description of how XFDL consumes the model views exposed by XForms, and what XForms features must be exploited to account for data persistence issues that arise within the current design of XForms (issues that affect any multi-user workflow as well as document-centric systems).
The XFDL document element has the local name XFDL and typically declares the XFDL namespace as
the default. To ensure backwards compatibility over time, the XFDL namespace
includes the version number. The content model of the XFDL element consists of a globalpage element followed by one or more page elements. Both of those contain start with a
global element. The page element can then contain any number of other
child elements called items, each of which represents a single
user interface control or grouping control. Each item contains zero or more
child elements called options, which provide properties
appropriate for the item.
<XFDL xmlns="http://www.ibm.com/XFDL/7.0"
xmlns:xfdl="http://www.ibm.com/XFDL/7.0"
xmlns:custom="http://www.ibm.com/XFDL/Custom"
xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<globalpage sid="global">
<global sid="global">
<!-- form global options -->
</global>
</global>
<page sid="P1">
<global sid="global">
<!-- page global options -->
</global>
<!-- items below -->
<field sid="NAME">
<!-- field options -->
</field>
<popup sid="GENDER">
<!-- popup options -->
</popup>
<!-- More items as needed -->
</page>
<!-- more pages as needed -->
</XFDL>
|
The pages, items and globals all must contain a sid attribute, which provides a scope
identifier for the element. The scope identifier of an element must be
unique among the children of its parent element. They provide an efficient
referencing method, e.g. P1.NAME refers to the first
field item above.
The XFDL schema recognizes a finite set of items, but it also allows custom
items, which have a non-XFDL namespace but contain an xfdl:sid attribute. The namespace prefix declared above by
xmlns:custom can be used to qualify
custom items, but any other namespace could also be used. A list of the
recognized items and their meaning appears below:
Using the containment items, table and pane, an arbitrary level of nesting items is permitted
because tables and panes can contain tables and panes. Moreover, the precision
layout markup in XFDL is applied within the containers, so the layout needs of
whole forms extends into the form fragments containined by panes and table rows.
As a result, tables are not just iterations of simple linear combinations of
form controls. Each row of a table can have arbitrary layout, including
subtables that have arbitrary layout.
The properties of each item are described by option subelements. A
number of the options have further element depth, and these descendant elements
are called suboptions. All options and suboptions in XFDL can be
dynamically modified by attaching a compute attribute. Due to the need for
computability and for suboption depth, item properties are expressed as
elements, not attributes. Computable properties and their relationship to
CSS-like control of rendition are discussed below and in Section
2.3.
The remainder of this section discusses the most important options in XFDL. It is not meant to replace the XFDL reference manual, though, as there are over a hundred options in total.
value option.
value option.
on or off to
indicate whether the item is rendered. Default is on.
If a container element (table, pane) is not visible, then its contained items
are also hidden.
on or off to
indicate whether the item is enabled or disabled. Default is on.
on or off to
indicate whether the item is read-only or modifiable. Default is off. When an item is read-only, the end-user is prevented
from modifying the user interface control, but the form may still
programatically modify the value option,
and the result will be rendered (if the item is visible).
value
option. This option enables the ability to handle dates, currencies, SSNs,
phone number, postal codes and other patterned input. A message suboption allows the form author to
specify a message to be shown when the value option content is invalid. A mandatory suboption contains on or off to indicate whether or not
user input is required.
compute attribute can be used to
associate the item with a globally defined style or to style the item's
appearance based on its value option
content.
compute
attribute can be used, for example, to associate the item with a globally
defined style.
on and off
content. These options are not serialized with the rest of the form as they
are designed to be detected by XFDL computes.It is not necessary to specify all of the options in an item since the options take default values. As examples, items are visible and active by default. Sometimes the default depends on the item, e.g. the default background color is white for fields and transparent for labels.
An XFDL compute attribute can be
placed on any option or suboption of an item to declare an update rule that is
automatically updated any time the nodes it references are changed. As a quick
example, we see below the markup that varies some of a field's properties based
on its value. The label text and font color are dynamically set based on the
input value entered by the user, and the background color is changed when the
field receives the focus or contains the mouse cursor.
<XFDL ... xml:lang="en">
<page sid="P1">
<global sid="global">...</global>
<!-- More Items -->
<field sid="IncomeTaxTotal">
<readonly>on</readonly>
<label compute="value >= '0' ? 'Your refund' : 'Please pay'"
>Your refund</label>
<fontcolor compute="value >= '0' ? 'black' : 'red'"
>black</fontcolor>
<value compute="some formula">$1,000.00</value>
<format>
<datatype>currency</datatype>
<presentation>
<showcurrency>on</showcurrency>
</presentation>
</format>
<bgcolor compute="focused=='on' || mouseover=='on'
? '#C0FFFF' : 'white' ">white</bgcolor>
</field>
<!-- More Items -->
</page>
</XFDL>
|
Observe that the results of a compute are placed into the content of the
element. Also, note that the computes for label and fontcolor refer to value
rather than the fully qualified reference, P1.IncomeTaxTotal.value. This is because XFDL scopes the
references relative to their document location. If the page and item scope
identifiers are omitted, then the page and item scope identifiers for the
containing page and item are used.
The compute expressions in the example above contain the decision operator
and some examples of comparators. Computes can also contain logical operations
(or, and, not) and nested decisions. A compute, such as the one for value above,
could also contain a formula involving arithmetic operations. All of these
built-in operations understand data type, so adding a number to some value
produces an appropriate result based on whether the value is a date, a currency,
a number or a string. This is why, for example, the value option content above
is comparable to '0' despite being decorated with
presentation formatting.
There are over 70 built-in functions available to XFDL compute for performing
all manner of string manipulations, financial calculations, trigonometric
calculations, and so forth. Moreover, XFDL allows extension
functions to be added via WSDLs and java classes. Such functions can
perform any calculation, even computing the next move in a game of checkers, for
example. Perhaps the most used function in pre-XForms XFDL forms is the toggle() function, which can detect a change of content of any
option that it references. Combined with the decision operator, this can be to
run an imperative sequence of functions. When the activated option of a button changes to on, then a web service function could be invoked. The set() function can be used to move the focus to a new field
when the current field's value changes to an acceptable result. The functions
set(), duplicate() and destroy can be used in combination when a button is pressed to
change the form or its data.
Originated in 1996, the compute system is really a more general-purpose
solution to address a super-set of the requirements that CSS targets. Therefore,
only the simplest computes are needed to associate a style to an item property.
The main difference is that the compute architecture was weighted toward
facilitating item customizability, so the decision to consume the style is made
by the item. However, it is easy for a design environment to offer item
multiselection so that one or more styles can be assigned to any number of items
(the CSS architecture is optimized for form design in a text editor). In fact,
XFDL is the first host language for XForms that is capable of providing CSS-like
functionality because XFDL exposes XForms instance data form XForms view
controls to the value option of the
associated XFDL item. Here is a simple example of creating a shared style:
<XFDL ... xmlns:styles="http://example.com/styles">
<globalpage sid="global">
<global sid="global">
<styles:field>
<styles:fontcolor>blue</styles:fontcolor>
...
</styles:field>
</global>
</globalpage>
<page sid="P1">
<global sid="global"> ... </global>
...
<field sid="Name">
...
<fontcolor compute="global.global.styles:field[styles:fontcolor]"/>
</field>
<field sid="Address">
...
<fontcolor compute="global.global.styles:field[styles:fontcolor]"/>
</field>
...
</page>
</XFDL>
|
A few final points are raised by this example. First, note that the field style is a form global option, and the font color style is a suboption. So, XFDL references can refer to options and suboptions in a foreign namespace, and suboptions are referenced using array syntax. Second, note that a compute could be applied to the font color style, which allows dynamic changes to all of the options that consume the style.
The XFDL compute system is meant to be applicable generally within the document, not just to XFDL options and suboptions. It would be useful for a future version of XML to consume this idea, only with some sort of XPath expression syntax. Until then, the feature is available in through the XFDL namespace. This means that the compute attribute has to be in the XFDL namespace.
There are numerous use cases for this feature. One is the computation of intermediate results. Another is computation of results in custom items. A third is to implement the notion of cascading styles. Continuing from the example above, one could have:
<global sid="global">
<styles:allInputs>
<styles:fontcolor>blue</styles:fontcolor>
<styles:bgcolor>255,255,128</styles:bgcolor>
...
</styles:allInputs>
<styles:field>
<styles:fontcolor compute="styles:allInputs[styles:fontcolor]"/>
<styles:bgcolor compute="styles:allInputs[styles:bgcolor]"/>
...
</styles:field>
</global>
|
The guiding principle of the integration between XFDL and XForms is that XFDL is quite literally a skin that provides a sophisticated presentation layer for XForms view controls. This means that the user interface controls suggested by XFDL and all of its options and computes are used to style the XForms controls. At the markup level, the skin concept is reinforced by placing the XForms control at the option level inside an XFDL item so that the latter is a skin for the former even in the document serialization. The XFDL item's properties for font, border, coloring, positioning, size and so forth are thus applied to the user interface control associated with the XForms view control skinned by the XFDL item, and the XForms view control behaves like any other XFDL option that provides special properties to an XFDL item, such as a binding to instance data.
Of course, it is also the case that putting a compute on a value option is not appropriate because such
computations are the domain of the calculate model item property of the XForms
model. However, for most items, the data content obtainable from the single node
binding of the XForms control is exposed to XFDL through the value option, so computes on other item
properties can be based on the data coming from XForms by simply referencing the
value option as was done before XFDL
integrated with XForms.
XFDL as a skin also means that XFDL is malleable, taking on the shape of what is under it, to keep with the analogy. In other words, the XFDL items interact with XForms view controls to consume the instance data and model item properties (MIPs) exposed by the XForms view controls. Generally, this consumption occurs by setting the default value of the XFDL option or suboption based on the information from the XForms view control. However, in some cases, the more appropriate behavior is to combine the information from XForms and XFDL in some way. The details of the effects of XForms constructs on XFDL are discussed in detail in Section 3.5.
The form global option xformsmodels is
used to contain all xforms:model elements
in an XFDL document. For example,
<XFDL ... >
<globalpage sid="global">
<global sid="global">
<xformsmodels>
<xforms:model ...>
<!-- [schema], instances, binds, submissions, actions -->
</xforms:model>
...
</xformsmodels>
...
</global>
</globalpage>
<page sid="P1">
<global sid="global"> ... </global>
...
</page>
</XFDL>
|
Although the technology is designed to scale up to very large forms, it still
helps to start with a simple example to help isolate the building blocks of all
forms. To this end, we consider for the next few sections a form that might be
used during an application for a mortgage. One might have to fill in various
parameters like the principal, duration and interest rate, and the form would
then report the monthly payment. We start with how an XForms view would expose
that result to the presentation language via an xforms:output control. The XFDL item most
frequently used to display non-editable text is the label, so that is the skin for xforms:output.
<label sid="MonthlyPayment">
<xforms:output ref="/loan/mpymt"/>
<format>
<datatype>currency</datatype>
<presentation>
<showcurrency>on</showcurrency>
</presentation>
</format>
</label>
|
XForms also allows a value attribute
to appear instead of the ref to allow a
simple formula to be calculated without having to store it in instance data. The
xforms:output can also have an xforms:label to associate some information with
the resulting formula. An example of this might be summing the results of a
purchase order:
<label sid="POSubtotal">
<xforms:output value="sum(/po/lines/line/total)">
<xforms:label>Subtotal:</xforms:label>
</xforms:output>
<justify>right</justify>
<format>
<datatype>currency</datatype>
<presentation>
<showcurrency>on</showcurrency>
</presentation>
</format>
</label>
|
The XFDL label item has a couple of
special features that aid in presentation. While both the xforms:label and the value contribute to the display, only the latter
is used to set the XFDL value option. This
allows the XFDL format to process the
numeric value. Second, it allows the justify option to operate only on the currency
value label. This is useful for left aligning the text labels for subtotal, tax
and total of a purchase order while right aligning the associated values.
The appropriate XFDL item for typed input is the field, which therefore can be the skin for
single-line (xforms:input), single-line
write-only (xforms:secret) and multiline
xforms:textarea XForms controls. Since the
skinning pattern is identical, only the single-line input is shown below:
<field sid="LoanPrincipal">
<xforms:input ref="/loan/principal">
<xforms:label>Loan Principal</xforms:label>
</xforms:input>
<format>
<datatype>currency</datatype>
<presentation>
<showcurrency>on</showcurrency>
<currencylocale compute="Currency.value->value"/>
</presentation>
</format>
</field>
|
In this example, the xforms:input binds
to a node of instance data identifed by the XPath express /loan/principal. According to XForms, if the node doesn't
exist, the field behaves as if it were bound to a non-relevant node (see Section
3.5.7). The xforms:label provides
the default value for the XFDL options label and acclabel. The value option is not shown in the above
serialization because it is transient in XFDL items containing XForms controls
(see Section
3.5.9). However, the value is
available during run-time for use in XFDL computes, and the format option casts it to a currency value. The
locale of the currency is harvested by the XFDL compute system from the user
selection made in the example of Section
3.3.3.
Perhaps the most common user interface control for obtaining a user choice is
the popup list (a.k.a. the drop down list). This corresponds to the minimal
appearance for the xforms:select1, which
corresponds to the XFDL popup item.
However, the form author may desire the compact appearance of an XFDL list or the full appearance of either a group of
radio buttons (radiogroup) or a even a
single-selection group of check boxes (checkgroup) The skin methodology for these items
is the same except for the use of the appearance attribute. The minimal
appearance is considered to be the default in XFDL, so the form author need not
put the attribute when the skin is a popup,
but the appearance attribute is required for the compact and full settings, and
the setting of the appearance attribute must match the XFDL item skinning the
xforms:select1.
<list sid="Currency">
<xforms:select1 ref="principal/@currency" appearance="compact">
<xforms:label>Choose currency</xforms:label>
<xforms:item>
<xforms:label>US Dollars</xforms:label>
<xforms:value>en_US</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Canadian Dollars</xforms:label>
<xforms:value>en_CA</xforms:value>
</xforms:item>
</xforms:select1>
<itemlocation>
<after>Principal</after>
<alignt2t>Principal</alignt2t>
<expandb2b>Principal</expandb2b>
</itemlocation>
</list>
|
This example shows the XFDL list item as
the skin for the single-selection control for choosing the currency locale.
Although the user sees US Dollars and Canadian Dollars, the underlying value is the raw locale
string, which is what the compute on the currencylocale
references.
This example also shows a few of the suboptions available within the itemlocation option. The default size of a list is wide enough to surround the widest choice
and tall enough to show all choices, plus the label (if any). However, this is
not compact enough in this case. Since we would like to match the countenance of
the Principal field, the height must be enough for the label and only one
choice. First, the list item is moved so that its left margin is after the right
of the Principal field. The top margin is then aligned with the principal field;
alignment does not affect the size of the item. Finally, the last suboption
changes the height so that the bottom margin of the list is aligned with the
bottom of the Principal field (a negative expansion in this case). The width is
not changed by this sequence of locators.
XForms supports an alternate syntax for specifying the choices for an xforms:select1. Instead of having one or more
xforms:item elements, the xforms:select1 may contain an xforms:itemset that implicitly generates one
xforms:item per node identified in a
node-set binding. XFDL supports this feature, but since the same technique is
used in an xforms:select, the example is
deferred to Section
3.3.4.
The XFDL processor implicitly creates an XFDL item to correspond with the
presentation of each xforms:item, whether
explicitly declared or generated by xforms:itemset. This allows more powerful control
of the presentation by adding XFDL options to each item using an xforms:extension. Again, the same technique is
used with an xforms:select so the example
is also shown in Section
3.3.4.
XFDL offers multiselect controls of both compact and full appearance by
skinning xforms:select with the XFDL list and checkgroup items, respectively.
<!-- In the xforms:model -->
<xforms:instance>
<mainData>
<chosenDVDs>1 3 5</chosenDVDs>
</mainData>
</xforms:instance>
<xforms:instance xmlns="" id="DVDChoices">
<data>
<DVD title="The Matrix" code="1"/>
<DVD title="The Wedding Singer" code="2"/>
<DVD title="Tombstone" code="3"/>
<DVD title="First Wives' Club" code="4"/>
<DVD title="The Terminator" code="5"/>
<DVD title="When Harry Met Sally" code="6"/>
</data>
</xforms:instance>
<xforms:bind nodeset="chosenDVDs" constraint="string-length(.) <= 5"/>
...
<!-- In an XFDL page -->
<checkgroup sid="constrained_multiselect">
<xforms:select appearance="full" ref="chosenDVDs">
<xforms:label>Bonus selection-- Choose 3 DVDs for only a buck!</xforms:label>
<xforms:itemset nodeset="instance('DVDChoices')/DVD">
<xforms:label ref="@title"/>
<xforms:value ref="@code"/>
<xforms:extension>
<labelfontinfo>
<fontname>Times</fontname>
<size>12</size>
</labelfontinfo>
<itemlocation>
<after compute="itemprevious"/>
</itemlocation>
</xforms:extension>
</xforms:itemset>
</xforms:select>
<labelfontinfo>
<fontname>Times</fontname>
<size>12</size>
<effect>bold</effect>
</labelfontinfo>
<border>on</border>
<bgcolor>cornsilk</bgcolor>
</checkgroup>
|
The first interesting feature of this example is that it shows how to constrain the user to some subset of the available choices. The XForms constraint is used to prevent the user from submitting a form in which more than three choices have been made. The expression accounts for the need to use a character entity for the less-than symbol in an XML attribute, and it acccounts for the space separator between the code values. Because neither XPath 1.0 nor XForms 1.0 offer a function to count the space separators, the form author should make all values have the same length.
Due to the nodeset expression, a check box item is
generated to present each DVD element in
instance data that is matched by the node-set binding of the xforms:itemset. For each generated check box, the
xforms:label is evaluated relative to the
generating node from the nodeset binding and determines the textual label
associated with the check box. Similarly, the xforms:value determines the data that goes into
node referenced by the xforms:select when
the corresponding check box is selected by the user.
The two XFDL options in the xforms:extension are copied to each generated
check box item. The compute in the itemlocation automatically runs to determine
the preceding checkbox. Every check box with a preceding check box is placed
after its predecessor, resulting in a horizontal row of check boxes. The default
behavior gives a vertical column of checkboxes because the default for itemlocation is to put each item below its
predecessor (within the context of the container item).
The checkgroup, then, is considered to
be a container item for the generated check boxes. The XFDL options outside of
the xforms:select1 affect the containing
checkgroup. For example, the default border
is off and the default background color is transparent, but this example makes
alternate settings.
Sometimes input is the answer to a simple yes/no question. Rather than making
the user type yes/no or true/false, XFDL allows a check item to skin an xforms:input.
<check sid="single_check">
<xforms:input ref="wantMembership">
<xforms:label>Do you want to join the DVD club?</xforms:label>
</xforms:input>
...
</check>
|
When the user's textual input is to be aided by a popup (drop down) of some
kind, the XFDL combobox item is used to
provide the assisted input capability. When the item skins an xforms:select1, then a popup list is available to
the user. The XForms syntax is the same except that the xforms:select1 must contain the attribute setting
selection='open'.
<combobox sid="PickYourPet">
<xforms:select1 ref="/pet/type" selection="open">
<xforms:label>Pick your pet:</xforms:label>
<xforms:itemset nodeset="instance('usualPets')/choice">
<xforms:label ref="@petname"/>
<xforms:value ref="@petcode"/>
</xforms:itemset>
</xforms:select1>
</combobox>
|
When the combobox skins an xforms:input, and the format option indicates that the datatype is a
date, then a calendar chooser is available to assist user input.
<combobox sid="EndDate">
<xforms:input ref="rental/endDate">
<xforms:label>Agreement End Date</xforms:label>
</xforms:input>
<format>
<datatype>date</datatype>
</format>
</combobox>
|
Selection of a value within an integer or floating point range can be
accomplished with the slider item, which
skins the xforms:range. As usual, the XFDL
options affect the presentation of the range control. The font information
affects the tick mark labels, for example. This example also shows how to change
from the default of no border and a transparent background.
<slider sid="OverallRating">
<xforms:range ref="rating" start="1" end="5" step="1">
<xforms:label>Overall Rating:</xforms:label>
</xforms:range>
<labelfontinfo>
<fontname>Times</fontname>
<size>14</size>
<effect>bold</effect>
</labelfontinfo>
<fontinfo>
<fontname>Times</fontname>
<size>10</size>
</fontinfo>
<border>on</border>
<bgcolor>cornsilk</bgcolor>
</slider>
|
The xforms:upload control allows for a
single-file attachment. When skinned by an XFDL button item, the user can activate a file
selection dialog by pressing the button, and the selected file's content will be
placed in the referenced instance data node (base 64 encoded).
<button sid="GetThePicture">
<xforms:upload ref="/data" mediatype="image/*">
<xforms:label>Press me to attach a picture</xforms:label>
</xforms:upload>
</button>
|
The xforms:trigger is used to activate a
sequence of XForms actions, such as inserting or deleting data, changing the
input focus or sending a submission. The xforms:submit acts as a shorthand for activating
an triggering an xforms:send action. The
XFDL button (and the automatic action) skins both of these XForms controls.
<!-- The hard way -->
<button sid="Submit">
<xforms:trigger>
<xforms:label>Submit Loan</xforms:label>
<xforms:send ev:event="DOMActivate" submission="S"/>
</xforms:trigger>
...
</button>
<!-- The easy way -->
<button sid="Submit2">
<xforms:submit submission="S">
<xforms:label>Submit Loan</xforms:label>
</xforms:submit>
...
</button>
|
Single and multiple line data can be extracted from the instance without rendition to the end-user by using an item that is not in the XFDL namespace to skin the appropriate XForms control.
<my:simpleData xmlns:my="http://example.com" xfdl:sid="SimpleData">
<xforms:input ref="data">
<xforms:label/>
</xforms:input>
</my:simpleData>
|
The instance data node referenced by the single node binding is available to
the xfdl:value. So, other XFDL computes can
refer to it using SimpleData.value and the XFDL set() function can be used to push data through the single
node binding to the bound instance node. See Section
4.5 for an example of using a custom item to capture the plain text
associated with a rich text field.
A collection of XFDL items can be logically and visually contained using the
XFDL pane item, which skins an xforms:group if the collection of items to be
contained is invariant or the xforms:switch
if the collection of items must be changed based on user events. A motivating
example appears in Section
3.4.2.
As with the prior items that were used to contain either items, such as checkgroup, the options for background color and
border exist and default to transparent and off, respectively. The default for
the visible option is based on the
relevance of the node referenced by the single node binding expressed in the
underlying xforms:group or xforms:switch, or to on
if the single node binding is not expressed. All of the items contained by a
pane are invisible if the pane is invisible due either to the default or to
an explicit setting.
The table element is capable of
iterating a collection of XFDL items once for each node of the nodeset binding
of the xforms:repeat skinned by the table
item. Any XFDL items can be placed into the xforms:repeat, including pane items and other table items. Here is an example:
<!-- Instance data, including repeat 'row' prototypical data -->
<xforms:instance id="po" xmlns="">
<po>
<order>
<row>
<product/>
<unitCost>0</unitCost>
<qty>0</qty>
<lineTotal>0</lineTotal>
</row>
</order>
<subtotal>0</subtotal>
<tax>0</tax>
<total>0</total>
</po>
</xforms:instance>
<!-- column headers -->
<label sid="productColumn">
<value>Product Name</value>
<itemlocation>
<y>75</y>
<width>150</width>
</itemlocation>
</label>
<label sid="unitCostColumn">
<value>Unit Cost</value>
<size>
<width>15</width>
<height>1</height>
</size>
<justify>center</justify>
<itemlocation>
<after>productColumn</after>
</itemlocation>
</label>
<label sid="qtyColumn">
<value>Quantity</value>
<justify>center</justify>
<itemlocation>
<after>unitCostColumn</after>
<width>100</width>
</itemlocation>
</label>
<label sid="lineTotalColumn">
<value>Line Total</value>
<justify>right</justify>
<itemlocation>
<after>qtyColumn</after>
<width>100</width>
</itemlocation>
</label>
<!-- The table item, ignoring repeat template for now -->
<table sid="POTable">
<bgcolor>cornsilk</bgcolor>
<border>on</border>
<xforms:repeat nodeset="order/row[position()!=last()]"
id="PORepeat">
<!-- XFDL items to repeat go here -->
</xforms:repeat>
</table>
|
The usual XFDL options appropriate for a container item are available to the
table item with the usual defaults. The
default for visibility is extended from single node binding to node-set binding
in a natural way. The default is off if the node-set
binding does not match any relevant nodes (and, of course, an empty node-set
contains no relevant nodes).
The node-set binding excludes the last row node because techniques used later in this
paper will preserve the last row to be used as prototypical data for inserting
new rows. The id will also be used later
to help determine the row that has the focus so that insertion and deletion
operations can be performed relative to the focused row. Now we are able to see
an example of content for the xforms:repeat
<pane sid="focusPane">
<bgcolor compute="focused=='on' ? '#C0C0FF' : 'transparent'"/>
<xforms:group ref=".">
<combobox sid="Product">
<xforms:select1 ref="product" selection="open">
<xforms:label>Choose product</xforms:label>
<xforms:itemset nodeset="instance('products')/product">
<xforms:label ref="@name"/>
<xforms:value ref="@code"/>
</xforms:itemset>
</xforms:select1>
<suppresslabel>on</suppresslabel>
<itemlocation>
<expandr2r>productColumn</expandr2r>
</itemlocation>
</popup>
<field sid="unitCost">
<xforms:input ref="unitCost">
<xforms:label>Unit Cost</xforms:label>
</xforms:input>
<justify>center</justify>
<suppresslabel>on</suppresslabel>
<itemlocation>
<after>Product</after>
<expandr2r>unitCostColumn</expandr2r>
</itemlocation>
<format>
<datatype>currency</datatype>
</format>
</field>
<field sid="Qty">
<xforms:input ref="qty">
<xforms:label>Quantity</xforms:label>
</xforms:input>
<justify>center</justify>
<suppresslabel>on</suppresslabel>
<itemlocation>
<after>unitCost</after>
<expandr2r>qtyColumn</expandr2r>
</itemlocation>
</field>
<label sid="LineTotal">
<xforms:output ref="lineTotal"/>
<justify>right</justify>
<itemlocation>
<after>Qty</after>
<expandr2r>lineTotalColumn</expandr2r>
</itemlocation>
<format>
<datatype>currency</datatype>
</format>
<acclabel>The total cost for all units of this product</acclabel>
</label>
</xforms:group>
</pane>
|
Any number of items can be placed in an xforms:repeat, which handles the collection of
items as if they were surrounded by an anonymous xforms:group. However, in this example, the group
is explicitly created with an XFDL pane
item in order to get more control over the appearance of each table row.
Specifically, the bgcolor option is
overloaded with a compute that sets the background to a highlighted color if the
pane has the focus. The focus is
hierarchically assigned in XFDL, so the pane has the focus if an item within it has the
focus. The net effect of this compute, then, is that the entire repeat table row
that contains the focus is highlighted.
A second interesting feature of this example comes from the behavior of the
itemlocation option. Observe that the
locators make references within the containing group and also references to the
column headers. Generally, this option behaves in a scoped manner with respect
to hierarchically organized XFDL items, so XFDL items within inner nested
repeats can refer to column headers in the outer nesting repeat (and so on out
to the page level).
Finally, this example also shows additional accessibility support available
in XFDL forms via the suppresslabel and
acclabel options. The latter option can
provide a screen-reader-only message. The suppresslabel option is more important to
iterated XForms constructs as it allows the XForms view controls to retain their
xforms:label for accessibility purposes
without infesting the visual display with information that is obtained by other
means within the form's visual design, such as column headers.
The single node bindings of most XForms view controls is transferred to the
XFDL value, where it is formatted (if there
is any formatting to do) and made available to the compute system and rendition
engine. One exception occurs for XForms controls that have optional single node
bindings, where the binding is only used to obtain a relevance setting. The
second exception is for the xforms:upload,
where the single node binding does not affect the display text but is also used
for more than relevance. The third and final exception is that the single node
binding attaches to the rtf option in rich
text fields (see Section
4.5).
The single node binding is also used by controls capable of input to push
data into the model whenever the associated XFDL value changes. Such changes can occur as the
result of user input or as the result of XFDL computes setting data into the
value. The default behavior is to convert the value content from its
presentational format into raw data. Typically this is done according to the
datatype given in the format option. All the specifications of the
format option are reversed to create raw
data that matches an XML schema data type that is associated with the XFDL datatype. The most usual applications for this
feature are conversion of currency values into xsd:double and date values into xsd:date. The format option also contains a suboption that can
turn off the unformatting so that, for example, long dates like April 27, 1968 can be placed directly in instance data. The
suboption is called keepformatindata.
The xforms:label creates a weak binding
only with the XFDL label and acclabel options. It provides only their default
content. This allows either option, if they exist and are non-empty, to override
the default. This is in keeping with the notion of XFDL as a skin over XForms.
This means, however, that content from XForms cannot be accessed by the compute
system using references to the XFDL options. Of course, the information from
XForms labels can be accessed by querying the XForms labels or their referenced
data nodes directly.
XFDL has a system of associating help messages with atomic user interface
items. When the user desires help for a control or enters invalid input, the
help message appears in a tooltip. If the XFDL help option is not specified, then the underlying
xforms:hint and xforms:help are concatenated and used
instead.
User input can be invalid due to failing the validity tests imposed by XForms
on the associated instance data node or by failing the validity test of the XFDL
format option (if one is given). When the
user has entered invalid input, the message
suboption of the format option is displayed
in a tooltip. If the XFDL message is not
specified, then the underlying xforms:alert
is used instead.
The readonly MIP of the instance node
bound to a control by the single node binding affects whether the user can
modify the data. The MIP sets the default for the readonly option, though contradicting the MIP
results in data changes not be accepted by the model anyway.
The validity of the value of an item may be assessed by the format option, if one is given. These results are
then combined with the information from the XForms model to determine the
overall item validity. An item is invalid unless all channels report validity:
any XML schema definitions, the required,
type and constraint MIPs and the XFDL format. The format option does not have to be present for the
XForms validity channels to be applied. If the result is invalid but the value
is empty, then the item shows itself to be required. Otherwise, if the result is
invalid and the value is non-empty, then the more severe invalidity countenance
is displayed. Both states result in the tooltip being displayed with message
content from Section
3.5.4.
The relevant MIP affects atomic
controls by setting the default for the visible option to off.
The active option is also turned off (i.e. the item is disabled.
If a container item (pane, table, radiogroup, checkgroup) is not visible, then its contained
items are not visible, regardless of their own XFDL settings and relevance.
There are two special relevance rules for the table item. First, it has a node-set binding, so
it's visible option defaults to off only if none of the nodes in the node-set binding are
relevant (or if the node-set binding produces an empty node-set). Second, for
any non-relevant node, the corresponding row of items generated by the table is not shown, and the table geometry is collapsed to omit the space for
the hidden items.
Other than non-relevance of a table row having an effect on the table size,
the XFDL visible option, whether set
explicitly or implicitly by relevance, does not change the item bounding box and
therefore does not affect the layout of other items.
The itemlocation option provides over 30
keywords for use as a sequence of suboptions that manipulate the bounding box of
an item. Some of the keywords make absolute settings, and others make settings
by aligning or expanding a bounding box margin relative to another item or
items, or by positioning an item relative to another item. When an item is
within a table or pane, the references from options like itemlocation are automatically scoped according
to the logical hierarchy expressed in the document. Further information on and a
markup example of this effect appear in Section
3.4.2.
When XFDL computes run, they change the contents of options. However, if the
item containing a changed option also contains an XForms control, then the
changes are not serialized because they can always be recomputed whenever the
form is run once instance data is pushed out through the XForms view controls to
the XFDL item presentation layer. A second rationale is that if it were
necessary to save such information at the XFDL layer, then the item could not be
used in an xforms:repeat anyway. A
principal benefit of the transience is that the markup for the presentation
layer is not changed, which means it can be digitally signed as a way of
offering trusted forms application.
The xforms:insert action is used to add
a new subtree of instance data by copying an existing subtree. The attribute set
was designed to be synchronized with the xforms:repeat, so the action has a node-set
binding, the last element of which is duplicated. The xforms:repeat is then expected to automatically
update the iteration of its template to allow a view of the additional data.
Here is the trigger for adding a new row to the purchase order example of Section
3.4.2:
<button sid="Insert">
<xforms:trigger>
<xforms:label>Insert Row</xforms:label>
<xforms:action ev:event="DOMActivate">
<xforms:insert nodeset="order/row"
at="index('PORepeat')" position="after"/>
<xforms:setfocus control="PORepeat"/>
</xforms:action>
</xforms:trigger>
</button>
|
When the user activates this button, the node-set binding obtains all the
row elements, and the insertion operation
duplicates the last row after the instance
node corresponding the row of the repeat table that last had the focus, which is
availabe from the index() function. The effect of the
insertion is that the new node appears and that the index of the xforms:repeat is adjusted to indicate the
position of the newly added node. Once this is done, the trigger's action
sequence sets focus back from the activated button to the table. Since focus is
hierarchic in XFDL, the table then passes the focus to the first focusable item
in the currently indexed row (the new row).
The challenge with this scheme is that the newly created instance subtree is
not empty, but rather contains the same data as the last row of the table. An
easy solution would be to add xforms:setvalue actions after the xforms:insert to clear the new row. Of course
this requires the form author to write a different action sequence for each
table. then, if the schema for the data changes, then the action sequence has to
be changed. The solution also does not scale to nested repeats because there is
no way to clear an inner table (XForms 1.0 contains no looping actions).
It is better to have a general method that can clear the row of data without having to know the data structure. This would also facilitate the creation of design environment support for tables, and it would solve the nested repeat problem. The following are the components of a solution:
xforms:bind to make the last
node non-relevant
xforms-model-construct-done event to
conditionally insert a second row of data if only row exists
The first of the above components was already shown in Section 3.4.2. The latter three are shown below. Two of the components call for a conditional insert action. Although XForms 1.0 does not offer conditional actions per se, XPath has predicates that are capable of keeping or omitting nodes based on conditions, and if the node-set binding produces an empty result, then actions like insert and delete perform no operation.
<!-- In the XForms model... -->
<xforms:bind nodeset="order/row[last()]" relevant="false()"/>
<!-- For every row, last() returns the total number of row elements in the
containing nodeset, so the condition last()=1 always returns false
unless there is only one row, at which point a second row is inserted.
The position is before, so that repeat indices will be set to 1. -->
<xforms:insert ev:event="xforms-model-construct-done"
nodeset="order/row[last()=1]" at="1" position="before"/>
<!-- In the page... -->
<button sid="Delete">
<xforms:trigger>
<xforms:label>Delete Row</xforms:label>
<xforms:action ev:event="DOMActivate">
<xforms:delete nodeset="order/row" at="index('orderTable')"/>
<xforms:insert nodeset="order/row[last()=1]" at="1" position="before"/>
<xforms:setfocus control="orderTable"/>
</xforms:action>
</xforms:trigger>
</button>
|
In the XML fragments above, the conditional insert in the xforms-model-construct-done event causes a second row element to be added if there is only one.
This starts the form with one relevant row of data, and that data is in the
initial state. Since the user cannot modify the non-relevant row, it will
remains in the initial state. When the user clicks the delete button, if the
last relevant row is deleted, then the one non-relevant row is immediately
inserted back into the data by the conditional insert in the delete button's
action sequence. The end-user experience is that hitting delete on the last row
simply clears the values in the row.
XFDL includes presentation layer extensions that facilitate better
accessibility support than is typically achievable with other XForms
implementations at this time. A key issue arises with the accessibility of
tables driven by xforms:repeat. The problem
is that many form authors are tending to provide empty xforms:label content for XForms view controls
that are within an xforms:repeat because
they don't want the labels to show up in every row of a repeat table.
In order to allow forms authors to specify XForms label content in repeated
controls without sacrificing on the visual fidelity of the form, XFDL includes
the suppresslabel option so that items can
turn off the visual rendition of the label while still allowing it to be
available to accessibility software. Furthermore, XFDL also supports the option
acclabel as a means of creating very high
fidelity accessibility support through tailored messaging that is more
appropriate for screen reading than some visual labels tend to be. Markup
examples of these options are available in Section
3.4.2.
The xforms:switch contains a number of
xforms:case elements, each of which is very
similar to an xforms:group in that it is
the container for a collection of zero or more items to be rendered. The purpose
of this construct is to enable the user to switch between groups of items. The
initial case of the switch is chosen as the first case with a selected attribute containing the value true (or the first case, if none contain true).
As the user interacts with the form, the xforms:toggle action is somehow triggered to
change the selected case of the switch. However, this does not change the values
of the selected attributes in the cases
to reflect the current state of the switch. So, if the full document containing
the form is saved and reloaded, the state of the switches is lost. Similarly, a
user who submits data to a server one day and downloads the data to continue the
next day will also have lost the switch states. Finally, part of the
implementation experience of enabling switch in repeat (see Section
4.4) was the determination that the selected attributes of a switch would be unable
to store the selected states of all switches generated by a repeat.
To solve this problem, XFDL supports the attribute xfdl:state on XForms switch elements. This
optional attribute contains an XPath expression evaluated with a context node
equal to the result of the single node binding. If the single node binding is
not expressed, then the context node for the xfdl:state is obtained as if the single node
binding were ref=".". If this attribute is given,
resolves to a node, and that node contains the ID of a case in the switch, then
the switch is initialized to that case (otherwise the normal initialization is
used). Also, whenever the switch is toggled, the ID of the newly selected case
is written to the node referenced by the xfdl:state (if the attribute is given and its
XPath expression resolves to a node). If the XPath expression identifies more
than one node, then the attribute is considered to resolve to the first node in
the set (i.e. the attribute adheres to the first node rule). A markup example
appears in Section
4.4.
This feature is particularly important because it allows the XForms control that is supposed to switch among sets of controls to be used in the implementation of what is often called model-based switching, which could previously only be done by using a set of XForms groups bound to some nodes whose relevance was changed as a means of switching groups. Using a switch is preferrable because the markup directly associates the cases involved in achieving a result.
As currently written, the XForms Recommendation does not recommend a
methodology for how xforms:switch should
behave when used within an xforms:repeat.
Indeed, the meaning of IDREFs into repeated content is also not defined for the
index() function, and the xforms:setfocus and setindex actions. The recommendation states that
a future version will add the feature once implementation experience and user
feedback are available. This has now occurred and the future version could
possibly be XForms 1.0 Third Edition, or XForms 1.1 at the latest.
One issue that arose through implementation experience with XFDL was the
switch state problem described in Section
4.3. The main problem identified in the recommendation was how to make
the xforms:toggle action operate on a
switch that is within a repeat when the toggle indicates a switch case using an
IDREF in its case attribute.
When an IDREF refers to an element that appears inside one or more XForms repeats, the IDREF can be contextualized. For the most part, the index of each containing repeat can be used to translate from an identified element of the source document and the iterations of that content by the repeats. Broadly speaking, then, the target of IDREFs is the repeat row that contains the focus. The discussion in the XForms working group is leaning toward a slightly more sophisticated contextualization for technical reasons, but the difference will not affect the more common use cases.
The guiding principle behind this refinement is that techniques used within a form should continue to work when the form is reused as a component in a larger form. For example, a delete trigger should be able to delete the current row of a repeat table regardless of whether or not that repeat table is within another repeat table. Similarly, the ability to set the focus or toggle a switch should not be lost when the controls involved are placed in a repeat. Here is some example markup for using switch in repeat:
<table sid="T">
<xforms:repeat nodeset="some/nodes[position()!=last()]">
...
<pane sid="P">
<xforms:switch xfdl:state="@state">
<xforms:case id="ETF">
<!-- Controls for electronic fund transfer info -->
</xforms:case>
<xforms:case id="CC">
<!-- Controls for credit card info -->
</xforms:case>
</xforms:switch>
...
</pane>
<radiogroup sid="R" appearance="full">
<xforms:select1 ref="@state">
<xforms:label>Credit Card or ETF?</xforms:label>
<xforms:item>
<xforms:label>Credit card</xforms:label>
<xforms:value>CC</xforms:value>
</xforms:item>
<xforms:item>
<xforms:label>Electronic fund transfer</xforms:label>
<xforms:value>ETF</xforms:value>
</xforms:item>
</xforms:select1>
</radiogroup>
</xforms:repeat>
...
</table>
|
The goal with XFDL is to allow for more sophisticated types of user input
than just plain text data entry and simple selection capabilities. One
requirement that arises fairly regularly is the need of users to decorate their
textual input. To meet this requirement, the XFDL field item supports the ability to accept
multiline rich text as user input when the texttype option is changed from the default of
text/plain to the value text/rtf. That declaration causes the field item to use the rtf option as the primary option for
communicating content between the user interface control, the XFDL presentation
layer, and the XForms view control. The value option becomes a secondary option for
capturing the plain text shadow of the rich text.
<field sid="CommentField">
<xforms:textarea ref="comment/richtext">
<xforms:label>Comment:</xforms:label>
</xforms:textarea>
<scrollhoriz>wordwrap</scrollhoriz>
<texttype>text/rtf</texttype>
</field>
|
Although the single node binding attaches the instance node to the rtf option, it is sometimes helpful to the
application developer to get the plain text as well. This can be used for
indexing purposes or be provided to drive other applications that have no rich
text rendition capability. By storing the translation being created on the
client-side XFDL processor, there is no need to build a server-side translation
to meet those requirements. Delegation of this responsibility to the form
application can be done with the following markup:
<custom:field xfdl:sid="customField">
<xforms:textarea ref="comment/plaintext">
<xforms:label>Plaintext of comment</xforms:label>
</xforms:textarea>
<custom:set_value xfdl:compute="toggle(CommentField.value)=='1'
? set('value', CommentField.value) : ''"/>
</custom:field>
|
XForms includes the ability to obtain file content and upload it into
instance data. This content could, for example, be a picture from a digital
camera of a house to be sold. A rich user experience would show the uploaded
picture to the user so that he or she can be sure that the correct file was
selected. This seems to be the role of the xforms:output, but in XForms 1.0 this element is
only capable of displaying text. There is a new attribute being added to xforms:output in XForms 1.1 called mediatype that will allow the output of images.
Although it won't be interoperable until XForms 1.1, XFDL offers this feature
now as an extension that is unavoidably necessity by the need to solve use cases
like the one above. Example markup for this feature appears below:
<button sid="GetThePicture">
<xforms:upload ref="/data" mediatype="image/*">
<xforms:label>Press me to attach a picture</xforms:label>
</xforms:upload>
</button>
<label sid="ShowThePicture">
<xforms:output ref="/data" mediatype="image/*"/>
</label>
<button sid="SubmitThePicture">
<xforms:submit submission="S">
<xforms:label>
<xforms:output ref="/data" mediatype="image/*"/>
</xforms:label>
</xforms:submit>
</button>
|
Although XForms 1.0 offers an attachment feature, it understandably has a few limitations in the first release of the language. The most important use case was to allow attachment of an image while being aligned with an XML schema type. Since the xsd:base64Binary type does not recognize compression and since images are typically compressed anyway, there is no compression feature for XForms attachments. However, if the user must attach a large file or many files that are not compressed, such as word documents, spreadsheets and other supporting documents of a financial filing, for example, then the size of instance data may become unwieldy. Moreover, if there are many files, a rich user experience feature would be to allow the user to attach multiple files with a single control and organize those files into a structure defined within the form.
XFDL allows these features as extensions to the button item that can be accessed by setting the
button's type option to one of enclose, extract or remove. If only compression is required, then the button can
be associated with a single attachment using the data option. A folder scheme can be specified
with the datagroup option. Though the
requirement has not yet arisen in our practice, the sufficiently motivated form
author could use the XFDL compute system to allow the end-user to construct the
set of folders for the attachments.
XForms 1.0 contains the ability to invoke web services that are based on SOAP 1.2. Although the WSDL descriptions of these services will not be directly consumable until a future version of XForms, the underlying SOAP envelopes and schema compliant XML can be hosted in XForms instances. The following parameterization of the XForms submission is needed:
ref attribute to indicate
the SOAP request envelope.
mediatype attribute to
application/soap+xml; action=NameOfService.
xforms:setvalue actions in an
xforms-submit handler to copy instance data to the
SOAP request envelope.
instance attribute to
indicate the instance in which to place the SOAP response envelope.
xforms:setvalue actions in an
xforms-submit-done handler to copy from the SOAP
response envelope to instance data.The key limitation to this approach is that only simple data can be sent and
received. XForms 1.1 will allow arbitrary XML subtrees to be copied to and from
SOAP envelopes via a new action called xforms:duplicate. XForms 1.1 will also support
SOAP 1.1 by setting a SOAPAction header based on the mediatype attribute content, and changing the
content type from application/soap+xml to text/xml and copying over the charset,
if given, from the mediatype attribute as
well.
A form is responsible for gathering the data of a transaction from a user (or users) so that the tranaction can ultimately take place between the user and the recipient of the form. If the recipient wants to be able to later prove the correctness of performing the transaction with or on behalf of the user, then the form application would benefit from the use of digital signatures.
A user can create a digital signature over any message (octet sequence). Once created the validation of that signature by the recipient ensures that the message has not changed and identifies the user who created the signature. Of course, the message signed should consist not only of transaction data but also a record of the presentation layer used to provide the data to the user. The reason is that the user is not reading the data but rather is interpreting the data through the presentation layer. Signing only the data would be somewhat analogous to signing only the ink or laser printer toner without affixing it to the paper.
Since XFDL keeps the presentation layer and data in the same file, it is easy to create digital signatures and add them to the bundle. The XFDL signature system supports signing the full document, but it also contains signature filters that allow part of the document to be omitted. The omission can be as simple as omitting the office-use-only section of a form so that it can be filled out after the user's signature is affixed. However, numerous other use cases exist for documents that have a non-trivial work flow associated with their completion. An easy example is the simplest form of multiple signer scenario, the signer/co-signer case. One person must sign the document first, and the document must then undergo the additional transition to allow a second signature. Since both signature are affixed to the document, the first signature must in some way omit the markup of the second signature so that the addition of the second signature does not corrupt the message validation performed for the first signature.
To enable signatures in an XFDL form, the form author must add one or more
XFDL button items with the type option set to signature. Further options in the button allow for signature
configuration, including specification of the cryptographic engine to use as
well as the XML filtration to be performed on the document. The XFDL signature
filter system provides an option called signinstance that allows the form author to omit
parts of the data in XForms instances that must undergo transition after the
signature is affixed. However, some functionality offered by XFDL has no analog
in XForms and is therefore not stored in instance data. There are other XFDL
options that allow these other markup extensions to be omitted as needed.
The most commonly asked question about signatures is "Why can't I just say what I want to sign rather than what should be omitted from the signature?" The answer is that XFDL allows the form author to do this, but this type of signature is usually insecure, so it is recommended that this feature be used only in special cases as an optimization to a previously created omission signature. The problem is this: if a signature filters a document based on finding what to sign, then it is easy to add arbitrary content to the document that doesn't match the filters. Therefore, the filters will validate the few bits of the document that its filters matched, but the newly added unsigned content may significantly alter the interpretation of that content. Therefore, it is better for the form author to be specific about what is allowed to change after the signature is affixed, and then sign everything that does not fit that specification. This way, anything added to the document that does not fit the form authors specification of what is allowed to change will cause the signature to become invalid.
Another of the extended behaviors available from the XFDL button item is that it allows the submission of
the entire form document rather than just the XML data being manipulated by the
model. The type option supports the content
keyword done, which submits the form to a given URL then
closes the form. Submission without closing can be done with the submit keyword.
<button sid="Submit"> <value>Submit Whole Form</value> <type>done</type> <url>http://example.org/.../processForm.php</url> ... </button> |
It is interesting to note that the submission URL is represented simply as another option of the item. As an option, it is subject to the machinations of the XFDL compute system. This means it is easy to set up rules within the form that dynamically decide where the form will go next. This can be used, for example, in very lightweight workflow scenarios.
Once a form document arrives on the server-side, there are several possible tasks that can be performed. The first would be to validate digital signatures, if any, to ensure that further work suggested by the form should indeed be performed. Next, the entire form could be archived for future transaction auditability and non-repudiation purposes. If the transaction data has now been completely gathered by the form, then the underlying instance data can be extracted from the form to drive back-end systems. This extraction is very easy because the entire document is XML. However, it may be necessary to use a module that is partially aware of XForms enough to initialize an XForms model so that non-relevant nodes can be pruned from the data extracted. On the other hand, if the form is not finished gathering transaction data from all parties involved in the transaction, then the form can be moved to the next state of the work flow so that it can be received and further transitioned by the next role player in the work flow sequence.
XHTML preview stylesheet created by Philip Mansfield.