For eleven years now, PureEdge has been producing software that pulls together the functions necessary for a document to behave as a secure, intelligent web application. This is not to say that such an architecture is always suitable, nor that the internals of such an architecture do not benefit from a well-defined separation of the logical components comprising documents (instances of the architecture). But properly constructed and standardized, such an architecture yields a number of benefits for its users.
Fortunately, over the past six years, the W3C has been laying the necessary foundations with such recommendations as XPath, XML Schema, XML Signatures, and most recently XForms. For virtually all of that time, PureEdge has diligently participated in the W3C process, beginning with a note about XFDL, an XML vocabulary that combined many of the features in the above recommendations to permit the definition of compound documents that functioned as secure, intelligent web applications [XFDL-NOTE]. Since that time, PureEdge has used its implementation and deployment experiences with XFDL to help contribute key components of XML Signatures [DSIG,C14N,EC14N,FILTER2] and XForms [XFORMS,XFORMS11-REQ].
The focal point of this paper is the contribution made by a compound document language like XFDL combined with XForms, both as it currently stands and based on what is coming in the next few versions. The discussion includes not only document processing issues but also document design capabilities as well as new possibilities based on interplay between the two.
XForms 1.0 is a W3C Recommendation that describes an XML vocabulary for defining web-based electronic forms of all levels of complexity. With XForms, one defines a business processing model that contains (or references) instances of XML data to be processed, XML schema for those data instances, and processing, user interface and submission definitions for the XML data.
Schema data-type validation occurs in real time as data entry occurs, and full schema validation is performed before submission. XForms is at its best when XML data is submitted directly to the server, rather than boiling everything down to tag-value pairs, and receiving as a response either replacement XML data or a whole new document. In XForms 1.1, additional constructs are being added to allow gathering of XML data from the XForms model to be used as the payload of a SOAP message, and to receive a SOAP message as a response and extract the data payload back into the XForms model.
The backbone of XForms, though, is the processing model that is defined for XML instance data. XForms combines event-based processing with a declarative computation engine based on XPath to virtually eliminate the scripting tedium of an imperative programming paradigm . The success of these methodologies at reducing complexity is not without precedent, as anyone can attest who has experienced the increased power of event-based programming or who has seen the rise of the spreadsheet as the second killer app of personal computing [IASTED].
The declarative computation engine performs updates of instance data
values using the same methodology as a spreadsheet. Using an
<xforms:bind> element, the form author simply declares
that the content of an XML node is the calculated result of an XPath
expression, and the XForms processor takes care of updating the XML node
whenever any other node referenced by the XPath expression changes. With
the <xforms:bind> at the origin, the declarative computation
system derives power along three axes:
A final aspect of XForms that makes it ideal for use in compound
documents that represent web applications is that XForms distinguishes
between the presentation and the intent of a user interface. XForms
specifies form controls that define the basic data collection methodology
desired by the form author, but it leaves the details of presentation
to a 'host language' such as XHTML, VoiceXML, SVG or XFDL. This allows
the strengths of each host language to be leveraged where appropriate
while preserving as much common functionality as possible. Moreover,
the same XForms model can be used with multiple user interfaces of the
same host language based on other constraints recognized by the
software system. For example, the XForms <select1> element
allows a user to make one choice from among many. This may be presented using
a group of radio buttons on a desktop, a drop-down menu on a PDA,
an audible list of choices read to a phone user.
XForms represents a clean architecture for separating presentation, user interface and business processing model. The separation, though, is first and foremost a logical one with the purpose of deriving classic software engineering benefits such as encapsulation and loose coupling. These are particularly important to the design experience for inteligent documents.
Yet the user experience can be simplified and enhanced through the creation of single documents that combine these separate logical components. Users are least encumbered when they have a single file containing their data, its presentation template, and the functional rules that govern how the document is updated in response to their further input. It is particularly helpful if the user can attach other supporting files to the intelligent document. This allows the user to exploit the intelligence of the document when offline, and to efficiently email or otherwise transport the entire context of a transaction.
In essence, a document in a host language that employs XForms is able to use the declarative nature of the XForms architecture as a standard method of serializing both the logic and state of a web application. Aside from ease-of-use scenarios, this leads to better capabilities for transaction auditing and non-repudiation and to more robust security of web applications.
It is well understood that the presentation layer, not just the data, must be digitally signed to create a non-repudiable transaction [WWW8]. Indeed, this much is codified into the XML signatures recommendation [DSIG], which includes both the ability to externally reference multiple components in a single signature, but also includes an enveloped signature mechanism and signature filtering capabilities that allow the compound document architecture to securely adapt to any signature scenario [RSA,ACM].
A strength of XForms is that it has deliberately separated the intent from the presentation of the user interface, allowing a host language to provide the latter. This allows for authors the ability to choosing a host language that has the best features within a given context. For example, the XFDL language includes signature filtering and advanced layout security features (described in [ACM]) that are not available in other host languages. The enterprise could therefore choose a host language that imports XForms as its platform and be able to preserve and re-use as much of its core form processing models as possible.
A particularly compelling possibility that XForms offers for security
is in the area of using XML signatures to secure the look-and-feel and
behaviors of dynamic web applications. This will become increasingly
important as governments and other large organizations begin to distribute
XForms web applications whose behaviors are guaranteed to the end-user to be
working according to the form author's intent. The XForms
<repeat> element provides a means for declaring a static
presentation markup for a portion of the form that dynamically changes based
on the data. Since the data is in a separate, encapsulated part of the XForms
model, it is easy to omit from signatures. Thus, the on-the-glass appearance
of the form may change substantially without breaking the form author's
signature over the XForms web application.
Quite apart from the expression of a user interface and presentation layer, the XForms model can be seen as the standardization in XML-related vocabularies of an intelligent wrapper around XML data that can be both constructed dynamically and exploited in any step of the business process.
Within the XForms model, the <xforms:bind> allows the
expression of business rules and database rules as separate attributes,
allowing their definitions to be performed by different groups, perhaps even
different organizations. Indeed, generic process agents can be developed to span
all entities of an industry such as insurance, financial or medical, with the
business rules, database rules (as well as presentation layer details) of a
particular organization being plugged in by configuration or registry.
It is also entirely conceivable to create generic processing agents such as workflow engines that interact with the compound document as an intelligent agent. By performing XForms actions that set values or make insertions and deletions of data, a server-side XForms model processor could then determine further courses of actions based on the computational results enforced by the model.
XForms offers many benefits for multimodality and accessibility. When used in a compound document format, it facilitates many ease-of-use scenarios and strengthens transaction auditability and security. These are benefits predominantly derived from consideration of the client-side processing of a compound document. Yet, the XForms processing model can also be used to drive server-side processes. In this way, the compound document becomes an intelligent wrapper for XML data, and on the horizon we begin to see the next generation of business process design environments.
[ACM] "Bulletproof Business Process Automation: Securing XML Forms with Document Subset Signatures" Proceedings of the ACM Workshop on XML Security, October 31, 2003. Fairfax, VA, USA. PDF Version
[C14N] "Canonical XML Version 1.0", W3C Recommendation, 2001. http://www.w3.org/TR/2001/REC-xml-c14n-20010315 and http://www.ietf.org/rfc/rfc3076.txt
[DSIG] "XML Signature Syntax and Processing" (with D. Eastlake, J. Reagle, D. Solo, M. Bartel, B. Fox, B. LaMacchia and E. Simon), W3C Recommendation, 2002. http://www.w3.org/TR/xmldsig-core/
[EC14N] "Exclusive XML Canonicalization Version 1.0" (with J. Reagle and D. Eastlake), W3C Recommendation, 2002. http://www.w3.org/TR/xml-exc-c14n
[FILTER2] "XPath Filter 2.0" (with J. Reagle and M. Hughes), W3C Recommendation, 2002. http://www.w3.org/TR/xmldsig-filter2/
[IASTED] "The XForms Computation Engine: Rationale, Theory and Implementation Experience" (with M. Honkala). Proceedings of the 6th IASTED International Conference on Internet and Multimedia Systems and Applications, Kauai, Hawaii, August 12-14, 2002.
[RSA] "Improper Utilization of Digital Signature Technology", RSA 2000 Conference Proceedings, San Jose, California, January 2000.
[WWW8] "XFDL: Creating Electronic Commerce Transaction Records Using XML" (with B. Blair), Computer Networks: The International Journal of Computer and Telecommunications Networking, vol. 31, pp. 1611-1622, 1999.
[XFDL-NOTE] "Extensible Forms Description Language (XFDL) 4.0" (with T. Bray and M. Gordon) http://www.w3.org/TR/1998/NOTE-XFDL-19980902
[XFORMS] "XForms 1.0" (eds. M. Dubinko, L. Klotz, R. Merrick, and T. V. Raman), W3C Recommendation, 2003. http://www.w3.org/TR/xforms/
[XFORMS11-REQ] "XForms 1.1 Requirements" (with R. Merrick and S. Schnitzenbaumer), W3C WG Note, 2004. http://www.w3.org/TR/xforms-11-req