XFDL: creating electronic commerce transaction records using XML

Computer Networks 31 (1999) 1611–1622

XFDL: creating electronic commerce transaction records using XML

Barclay Blair Ł;1, John Boyer 1

C=O UWI.Com, 400-1095 McKenzie Ave., Victoria, BC V8P 2L5, Canada

Abstract

In the race to transform the World Wide Web from a medium for information presentation to a medium for informationexchange, the development of practices for ensuring the security, auditability, and non-repudiation of transactions that arewell established in the paper-based world has not kept pace in the digital world. Existing Internet technology providesno easy way to create a valid ‘digital receipt’ that meets the requirements of both complex distributed networks and thebusiness community. In addition, an improved articulation of digital signatures is needed. Extensible Forms DescriptionLanguage (XFDL), developed by UWI.Com and Tim Bray, is an application of XML that allows organizations to movetheir paper-based forms systems to the Internet while maintaining the necessary attributes of paper-based transactionrecords. XFDL was designed for implementation in business-to-business electronic commerce and intra-organizationalinformation transactions. 1999 Published by Elsevier Science B.V. All rights reserved.

Keywords: XML; XFDL; Electronic commerce; Electronic records; Records management

1. Introduction

This paper discusses the issues surrounding thecreation of legally-binding electronic transactionrecords on the Internet and outlines an XML-basedsolution called Extensible Forms Description Lan-guage (XFDL). This discussion begins with an anal-ysis of the current function of paper forms withinorganizations, and then moves to an analysis ofthe business need for viable transaction records inelectronic commerce. From there, digital signaturesand existing Web-based technology are studied, andfinally, XFDL is explained in detail.

Ł Corresponding author.1 E-mail: {barclay,jboyer}@uwi.com

2. Understanding the need for forms

Forms can be described as the primary user in-terface for business [13]. Industry analysts have es-timated that organizations worldwide produce 90billion pre-printed pages per day — a significantportion of which are paper forms [4]. In order to un-derstand why forms are so pervasive, it is necessaryto analyze the functions that paper forms currentlyserve within organizations.

2.1. Paper forms are data structures

Paper forms allow specific sets of data to beeasily organized, classified, and understood. With-out a structured way to represent data, high-volumebusiness processes would be very difficult to im-plement and organize. For example, purchasing de-partments typically depend on the structured data

/99/$ – see front matter 1999 Published by Elsevier Science B.V. All rights reserved.PII: S ( 9 9 ) 0 0 0 2 8 - 6

1612 B. Blair, J. Boyer / Computer Networks 31 (1999) 1611–1622

of forms to gather and process critical informa-tion.

2.2. Paper forms are user interfaces

Paper forms are a simple and elegant method ofproviding structured data to information systems. Aswith any user interface, there are design elementsthat provide inherent logic to meet the demands ofthe human user on the front end and the processon the back end. Paper forms are a unique userinterface, in that they provide both the templates fordata collection, and the record or archive of the datacollected.

2.3. Paper forms are transaction records

Perhaps the most important function of paperforms is their ability to create transaction records.Most paper forms are contractual in nature, eitherexplicitly or implicitly. In practice, users of a formindicate their participation in this contract by fillingin the necessary information and adding their sig-nature. Should there be any disagreement about thecontract represented by the form, the form can beused as proof of the transaction. The term ‘trans-action’ is used generically and can refer to the ex-change of goods, services, money, information, andso on.

Paper forms capture a fixed record of the stateof the data at the time the form was signed — inother words, they create a valid ‘source document’.Indelible ink prevents tampering, and the signatureprovides signer authentication and authorization.

While this is an important feature of paper forms,it is also creates a dependence on physical doc-uments that severely hampers the automation offorms processing systems. Many organizations havestrict rules governing the maintenance of transactionrecords that may also restrict automation. Until re-cently, these issues have been largely ignored in thecreation of Web-based forms.

Clearly, paper forms are a vital part of the busi-ness process. However, it is also clear that depen-dence on paper-based systems is inefficient andcostly in a digital world. Analysts estimate that itcosts organizations in the USA over US$ 120B an-nually to process paper forms [11].

3. Understanding the business need

The emergence of electronic commerce as a driv-ing force for technological development is widelyrecognized. Various mechanisms are now in placeto enable effective transactions between businessesand consumers. However, another area of growththat may ultimately have a greater impact on thedevelopment of Web-based technology for exchang-ing structured information is that of business-to-business electronic commerce. Business-to-businesselectronic commerce may also be a key drivingforce for the acceptance of XML, as it cannotbe accomplished within the limitations of HTMLalone [6].

It is estimated that the value of business-to-business electronic commerce will grow to US$1.3 trillion by 2003 [16]. Unlike consumer-basedelectronic commerce, business-to-business electroniccommerce requires both buying and selling organi-zations to seek methods for integrating their businessprocesses.

XML [10] has been heralded as a key enablingtechnology for this type of integration [20]. Sincetransactions of this type typically involve the com-munication of some form of structured data, havinga standard syntax for creating and exchanging datastructures is obviously an important step. However,XML is not a solution in itself, but simply a frame-work for describing the necessary protocols.

XML offers a method for integrating businessprocesses by providing an open, extensible structurefor data exchange. Reliance on unique or proprietarytechnology for these tasks is costly, inefficient, andrisky, often resulting in ‘black box legacy systems’that may be part of a strategy to lock organizationsinto a particular vendor’s products [19]. EDI was anattempt to enforce standard data formats for elec-tronic commerce, but the cost of implementation haslimited its application. XML can provide many of thebenefits of EDI without the prohibitive infrastructurecosts.

3.1. What makes a valid transaction record?

When the importance and pervasiveness of pa-per forms in business is considered in conjunctionwith the growth of electronic commerce, it is clear

B. Blair, J. Boyer / Computer Networks 31 (1999) 1611–1622 1613

Fig. 1. Hierarchy of transaction record validity.

that a method for moving paper forms to the In-ternet is needed. More specifically, the features thatpaper forms offer (data structures, user interfaces,and transaction records), must be integrated intoelectronic commerce systems. XFDL was designedspecifically for this purpose. In order to understandthe design of XFDL, it is necessary to look at thearchitecture of transaction records in more detail.

The legal requirements for paper records havebeen clearly established over many years. In addi-tion, the regulations governing the general admissi-bility of electronic records have been dealt with inmany jurisdictions [15]. There are three key conceptsto be considered in the management of transactionrecords: security, non-repudiation, and auditability.These concepts are based on a foundation of autho-rization, signer authentication, document authentica-tion, and context preservation. Fig. 1 illustrates therelationships between these concepts in the ‘hierar-chy of transaction record validity’.

3.1.1. SecurityGuidelines for transaction record security can be

found in the Digital Signature Guidelines of theAmerican Bar Association [3]. Security is achievedthrough authorization, document authentication, andsigner authentication.

The ceremony of signing a record denotes thesigner’s authorization, which means that the termsof the transaction are understood and the signingparties agree to proceed with the transaction. Doc-ument authentication refers to the fact that recordsmust provide protection from tampering after theyhave been completed. Paper forms provide this, atleast to a degree that is acceptable to the courts, dueto the difficulty of modifying the form’s appearancewithout destroying the paper. Signer authenticationrefers to the ability to identify who signed a docu-

ment, message, or record. The inherent uniqueness ofhandwritten signatures on paper forms authenticateseach signer by providing proof of identity.

The prevailing electronic method for achievingtransaction record security is the digital signature.In an environment where digital signatures are used,each person is given a mathematically related pairof ‘keys’. The ‘private key’ uniquely identifies thesigner; consequently, access must be restricted tothe key’s owner. The ‘public key’ is used by allpersons to authenticate signatures created with theprivate key. The typical formulation for the digitalsignature algorithm [14] states that when a signer‘performs the ceremony’ of creating a signature (im-plying authorization), a signature S for a given mes-sage M is created by the function Encrypt(hash(M),PrivateKey), and that verification of signature S isaccomplished by testing the equality of hash(M)and Decrypt(S, PublicKey). The hash() function is amathematically sound method of detecting a changein M, thereby achieving document authentication.Encryption protects the hash value from tampering,and decryption will only be successful with signer’spublic key. Because the public key is uniquely re-lated to the private key used to create the signature,signer authentication is achieved.

3.1.2. Non-repudiationA record that offers transaction non-repudiation

ensures that the agreement represented by the recordcannot be disputed. Paper forms provide all the con-tent necessary to prove the nature of an agreement.A paper form provides a logical structure that isfixed and immutable. A form’s fields, check boxes,and other elements have corresponding labels (as-sociated by position) that provide the ‘questions’ ofthe contract, and the data entered with permanentink provide the ‘answers’ to those questions. Paperforms accomplish non-repudiation in such a trans-parent manner that it takes some effort to realizethat special precautions must be taken to achieve thesame results by digital means.

In the electronic world, it is usually assumed thattransaction non-repudiation is accomplished throughthe use of digital signatures. Actually, it was quicklyrecognized that the digital signature algorithm didnot completely solve the problem. The efficacy ofa digital signature is directly proportional to the


security with which the signer’s public key can bedelivered to the verification phase. An entire industrydevoted to the creation and maintenance of PublicKey Infrastructures (PKI) has been developed toaddress this issue.

There is a similar problem on the opposite sideof the digital signature process — during signaturecreation. Consider the reason why a signer creates adigital signature. A digital signature is only neededif message M will be given to another party — theverifier. Since M has a source and a destination, itis essentially a transaction record. A digital signa-ture can achieve transaction record non-repudiation,but the above stated goal of transaction non-repudia-tion is to “ensure that the agreement represented bythe record cannot be disputed”. Hence, the efficacyof a digital signature in achieving transaction non-repudiation is directly proportional to the extent thatthe transaction record M completely represents thetransaction.

The Association for Information and Image Man-agement’s (AIIM) Performance Guideline for the Le-gal Acceptance of Records Produced by InformationTechnology Systems lays out the following guide-lines:

The following shall appear with sufficient clarityso that each can be recognized:ž Individual letters, numbers and symbols;ž Combinations of letters, number, and symbols

forming words or sentences;ž Graphics, such as signatures, logos, pictures,

etc;ž Sound;ž Other features of records such as color, shape,

texture, etc. that relate to the content of theinformation [2].

These guidelines further illustrate the need fortransaction records to contain not only the content ofan agreement, but the context and structure as well.

3.1.3. AuditabilityA record that provides non-repudiation not only

protects the parties in the agreement, but also canconsequently be part of a reliable audit trail for inter-nal (business audits) or external (legal, or chain-of-custody) purposes. In order for a transaction recordto be part of a viable audit trail, it must contain atleast the following information:

ž who was involved;ž when the transaction occurred;ž the nature of the transaction; andž the results of the transaction [13].

The paper forms involved in each step of a supplychain, for instance, are all part of the audit trail fora given transaction. As the ‘hierarchy of transactionrecord validity’ in Fig. 1 illustrates, auditability ispredicated on effective transaction non-repudiation,so automated processes will only be more effectivethan paper when they meet or exceed the ability ofpaper to achieve non-repudiation.

3.2. Existing internet technology

Although there are many approaches to Web-based forms and transactions, it is useful to look atHTML forms as a baseline in order to illustrate keypoints about transaction records on the Web. HTMLforms are often used as a replacement for paperforms in business-to-consumer electronic commerce.Although HTML forms do provide a user interface,they do not duplicate the other two important fea-tures of paper forms — namely, the provision of adata structure, and the creation of a viable electronicrecord.

HTML is a language that was designed to sepa-rate markup from content, a concept inherited fromSGML. While this philosophy has been a corner-stone in the development of the Web, it also makesHTML unsuitable as a replacement for paper formsin high-value business-to-consumer and business-to-business electronic commerce.

Most existing Internet protocols cannot addressthis issue because of the philosophy behind theirbasic architecture. Traditionally, engineers have di-vided an application’s data, presentation, and logicinto separate, clearly-defined architectural layers.This approach to systems architecture has a greatdeal of merit — stratification provides a tremendousdegree of flexibility. In a stratified information sys-tem, interfaces can be changed and extended withoutmodifying the underlying data, new data sets canbe used while maintaining a consistent look-and-feelfor the users, and modifications can be made to theapplication’s logic without affecting the existing in-terfaces, or the underlying data. Unfortunately, thiselegant flexibility is exactly what cannot exist in


transaction records. The ability to easily change thecontext (interface) while keeping the content (en-tered data) static diminishes a transaction record’slegal effectiveness.

In practice, when a user fills and submits anHTML form, only the input data (content) is sentto the server, where it usually becomes fields ina database. The HTML form (context and structure)itself is maintained as a separate HTML file. Becausethe act of submitting an HTML form separates thecontent from the context and structure, a transactionrecord that offers non-repudiation and auditability isnot created.

Consider this example: A person buys a US$250K life insurance policy by filling out an HTMLform with the desired policy parameters and digitallysigning the submission. Five months later the per-son is diagnosed with a terminal illness, then diesafter another five months. When the bereaved spouserequests the insurance payment, the claim is denieddue to a caveat that the policy does not cover deathdue to terminal illness diagnosed within six monthsof the start of the policy — a caveat that appeared inthe fine print. Litigation is the most likely result.

The spouse can easily repudiate the transactionbecause the insurance company only has a digitalsignature on the tagDvalue pairs that represent thepolicy parameters collected by the HTML form.There is no way to prove that the fine print was eventhere. Further, even if the HTML form mentions asix month caveat, the wording is very important:was it diagnosis within six months, or death withinsix months? Now suppose that the static text ofan HTML document was included in the signature.The spouse can still repudiate the transaction byclaiming that the fine print had the same color as thebackground, that it was positioned in negative pixelspace, that the font was too small, and so on. Indeed,the proper formulation of the transaction record mustinclude the questions, the user’s answers, and arepresentation of how this was presented on thecomputer screen [2]. Unlike a paper form, whichcaptures a ‘snapshot’ of the agreement at the time ofsigning, HTML forms offer no similar guarantee.

Java systems usually have the same problem —they store and transmit the data files separately fromtheir presentation (the Java classes). In addition, EDIsystems were designed primarily to reduce input

errors caused by manual key entry and to bypassslow physical delivery systems, and as such, veryfew, if any, EDI systems have a built-in facilityfor capturing the content and context of electronictransactions [13].

3.3. Liability and technical shortcomings of existingimplementations

Although electronic commerce is growing veryquickly, most organizations do not have the abil-ity to create viable electronic transaction records. Inthe absence of these records, the parties involvedin a transaction simply have to accept the risk ofliability. Most business-to-consumer electronic com-merce transactions are currently being conductedon a ‘faith’ basis. If the transaction falls into dis-pute, it is understood that one party (usually thelarger one) will simply accept the loss. Larger part-ners sometimes enter into ‘blanket’ agreements withfinancial institutions that define specific resolutionmechanisms should disputes arise.

Other organizations approach this problem usingpaper=digital hybrids. These companies use an elec-tronic forms package to design, distribute, and filltheir forms. However, to create viable transactionrecords, these forms must be printed and physicallysigned. The paper record is then filed manually orscanned into a digital imaging system for archiving.The disadvantages of this ‘fill and print’ approachare clear. A great deal of money could be saved ifthe form remained in a digital format throughout theentire process.

HTML and Java-based solutions may be appro-priate for low-value business-to-consumer electroniccommerce, where blanket dispute resolution agree-ments exist. In these situations, the requirement toretain detailed information may not be critical forregulatory compliance, or for discovery and litiga-tion [13]. However, these solutions are not ade-quate for high-value business-to-business electroniccommerce and critical intra-organizational informa-tion transactions. A better system — one that moreclosely approximates existing paper business prac-tices — is required. XFDL was designed for this typeof implementation, where improperly-kept transac-tion records have the potential to inflict serious lia-bility.


4. Extensible Forms Description Language(XFDL)

XFDL is a highly-structured XML protocol de-signed specifically to solve the body of problemsassociated with digitally representing paper forms onthe Internet. The features of the language includesupport for a high-precision interface, fine-grainedcomputations and integrated input validation, multi-ple overlapping digital signatures, and legally-bind-ing transaction records [8].

4.1. XFDL is a document-centric markup language

XFDL takes a ‘document-centric’ approach todigital forms by storing each necessary element of aviable transaction record in one securable file. Doc-ument-centrism is a controversial design tenet for anXML derivative, but it is the key feature in creatingnon-repudiable transaction records — the ‘message’must accurately record the full transaction contextin order to achieve the essential purpose of digitalsignatures. Just like a paper form, the content, con-text, and structure of an XFDL form are all storedtogether. In the event of a dispute, an XFDL doc-ument can be recalled and used to prove the exactnature of a transaction. An organization can there-fore create a ‘forms repository’ of XFDL documentsthat provide legally-admissible transaction recordsfor dispute reconciliation, business audits, chain-of-custody processes, and so on.

4.2. XFDL is a computational language

Unlike most XML languages, XFDL is also aprogramming language. XFDL is smart enough tomake decisions, handle arithmetic, and respond touser input. The fine-grained computational power ofXFDL allows it to automatically perform the mathand logic functions that are performed manuallyin paper forms. This allows an XFDL documentto direct a user through the interface, performingcalculations and error corrections ‘on-the-fly’.

This computational power, or logic, is embeddedinto the XFDL document and becomes part of thetransaction record that is digitally signed. Embeddedlogic also gives XFDL documents offline function-ality, as an external connection to a script or some

other source of programmatic intelligence is not re-quired. This also makes XFDL documents usefulfor nomadic, or disconnected, data collection usingportable computers and hand-held appliances.

Infix notation was initially chosen to representcomputations within XFDL. Allowance was madein the XFDL specification for supporting the prefixsemantics of MathML [18] in future versions. Theprimary reason for this decision was readability. Un-derstanding simple calculations in an infix notationis reasonably intuitive, whereas doing so in a prefixnotation is not. This problem is aggravated whencomplex decision logic is represented, where a one-line infix statement can require ten to twenty lines ofprefix code to accomplish the same task.

4.3. XFDL is assertion-based

XFDL’s computational logic is expressed using as-sertions. Unlike most traditional programming lan-guages that function on a procedural mode, there isno thread of execution to be managed in XFDL. Cre-ating computations in XFDL is much like using aspreadsheet. For example, to make Field1 the sumof Field2 and Field3, Field1 is ‘told’ that thisis the case. As the user interacts with the form, chang-ing the values of Field2 and Field3, the XFDLlanguage makes sure that the assertion is always true.

XFDL was engineered as an assertion-based lan-guage for two reasons. The first is readability. Thetype of logic that is normally used in complex formsis very easy to describe using assertions. Capturingevents and running procedural code is overly com-plicated for operations like “make Field1 the sumof Field2 and Field3”.

The second, more compelling reason for an as-sertion-based design is that it is very easy to freezethe exact state of a document when the user decidesto save it, sign it, or send it to a server. Capturingthe exact state of a program written in a procedurallanguage would require the acquisition of a greatdeal of information, such as the heap, the call stack,the data and code segments, and so on. Even if thisinformation could be captured easily, it would bedifficult to interpret — the transaction would not behuman readable. By operating an XFDL documentas a ‘state machine’, it is easy to take a snapshot ofthe document at any moment of its execution.


4.4. XFDL is human-readable plain text

A core design tenet of both XML and XFDLis human readability. File formats for transactionrecords obviously need to be machine-readable, butcan be more ‘future-proof’ if they are also human-readable [19]. XFDL is designed to create transac-tion records whose life span may be much longerthan any particular Internet technology or vendor.Organizations need to maintain these records as ev-idence of their business process for many years,and, as such, cannot depend on opaque binary dataformats for this purpose.

4.5. XFDL is a publicly accessible open standardbased on XML

XFDL derives several benefits from having a hu-man readable XML syntax. Any document format,such as XFDL, which claims to be human read-able must be a publicly accessible open standard.This is necessary to ensure that the semantics ofthe XML elements are known. As a natural conse-quence of this, organizations can share structured in-formation gathered by XFDL documents with otherorganizations without a costly translation process.This is also valuable for organizations that wantto share data among internal departments whosesystems may be based on fundamentally differentontology. Furthermore, because it is built on XML,XFDL is easy to generate and manipulate usingany of the XML-enabled tools on the Web, andit is easier to find human resources who have theskill set necessary to create software to performthese manipulations. While openness is importantfor any Internet protocol, the concepts of ‘data min-ing’ and ‘future-proofing’ information are especiallyprescient for a language that creates transactionrecords.

4.6. XFDL is extensible, allowing application-specific=server-side logic

Most languages based on XML are not themselvesextensible, but rather are composed of a very definiteset of keywords, rules, and so on. Although the mostimportant function on a non-repudiable transaction— the digital signature — occurs on the client ma-

chine, the full lifetime of a transaction can be quitecomplex and involve processing by modules otherthan a forms viewer. In a ‘fat-client’ application de-sign, these modules will run on the client machine,whereas the ‘thin-client’ application architecture willhave these modules on the server side. In either case,the ability to add custom functions to XFDL com-putes and, in general, to use XFDL’s computationengine within custom items and options designed formodules other than a viewer is a key componentin managing a transaction record’s lifetime from asingle source document.

For example, custom items, options and functionscan describe complex interactions between a formand a server-side ODBC database. They can also beused to specify workflow logic for the form basedon content in the form. Indeed, most of the essen-tial functions of electronic commerce transactionsoccur on a server after the client has provided autho-rization, and XFDL’s computation engine facilitatesthese operations by letting the transaction documenthave greater control of its own processing.

5. Advanced discussion of XFDL

As stated previously, the primary design goal forXFDL was the creation of secure, auditable, andnon-repudiable transaction records for Web-basedinformation and electronic commerce transactions.However, the creation of viable transaction recordsis only one piece of the puzzle for organizations thatwish to move their paper forms to the Internet. Acomplete range of features designed to reflect the‘real world’ business need for electronic commerceforms is required. These features are outlined inthe stated design goals for XFDL [8]. This sectiondiscusses XFDL in more detail, and also discusses anumber of these other design goals.

5.1. Structural overview

The root element of an XFDL form is surroundedby <XFDL> and </XFDL> tags. Each page of the formis surrounded by <page> and </page>. The itemsin a page represent widgets such as buttons, fields,labels, checkboxes and pop-ups, but also invisibleobjects like digital signatures and custom items.


A button, for example, would be surrounded by<button> and </button>. A button on the formwill have several options, represented by subordinateelements. For example, if the button displays the text‘Submit’, then the option <value>Submit</value>would appear in the button.

Fig. 2 shows the complete text for a small form.The benefits of XFDL over other solutions involvingtechnologies like Java are best seen in larger formsfound in business and government, but Fig. 2 hasmost of the structural components that are simply it-erated to build those larger forms. The example formdoes the familiar Pythagorean Theorem calculation,which determines the hypotenuse length of a trianglegiven the lengths of its sides.

5.1.1. Root element, version, page, item, and relativescoping

The XFDL element has a mandatory attributecalled version that indicates the language versionof XFDL to which the form complies. This controlswhich keywords may be available, for example. Eachpage and item has a mandatory attribute called sid,which stands for scope identifier. In order to supportthe computation system, each XML element mustbe uniquely identifiable. XML contains a method fordoing this, but it requires an identifier that is uniquewithin the document, so it is not scalable to the largeforms typically found in business and government.This is important when trying to cut-and-paste logicwhile building forms, but it is especially pertinentwhen creating XFDL forms that dynamically dupli-cate a new row of items while running in the viewer.For example, a purchase order that grows dynami-cally must duplicate all line items. In this case, allcomputations must have relative scope so that thenew computes will apply to the new items, ratherthan to the originating items.

5.1.2. Options in the form global, page global, anditem content

Before the first page element, and before thefirst item of each page, an XFDL form can con-tain ‘global’ options. These are option elements thatgenerally provide default settings for the options ineach item. Their structure is the same as optionsappearing in an item, so only item options will bediscussed here. Even an item as simple as a label can

have many options, such as its text value and fontspecification as shown in the Title label of Fig. 2.Additional options such as image and itemlocationdescribe precisely where the label should be on theform. A number of other item-specific options con-trol a variety of behaviors. For example, a fieldcan be made read-only (editstate) or contain inputvalidation and formatting (format).

The sid attribute is not required and has no mean-ing in options (or any elements they contain). Op-tions do not need a sid attribute because the elementtag acts as the scope identifier. According to TimBray [9], this dichotomy causes XFDL to have a‘look-and-feel’ that XML users have come to expect.

5.1.3. Element depth for arrays and computesSome options, like value, contain simple charac-

ter data, while others, like fontinfo, contain sub-ele-ments. This latter type of option exemplifies XFDL’snotion of an array. However, elements for simplecharacter data may need to contain a computationthat calculates the character data, such as field C inFig. 2. The content attribute is used to indicate howan element’s content will use element depth.

A unique scope identifier is optional for ar-ray elements. The tag ae is a reserved tag usedby array elements that have no scope identifier.Such elements can still be referenced in com-putes using ordinal position. For example, the re-sult of p1.Title.fontinfo[facename] evalu-ates to “Times”, but p1.Title.fontinfo[0] isalso “Times” because XFDL arrays are zero-basedand can be accessed by ordinal position even if theyare named.

5.1.4. Compute structure and syntaxA computed element contains the sub-elements

cval and compute. The content of cval is the currentvalue of the computation given by the compute ele-ment. The cval plays an important role in transactionnon-repudiation because its contents are frozen oncea digital signature is applied to the surrounding ele-ment. This helps XFDL to create a ‘snapshot’ of thetransaction.

XFDL includes the standard arithmetic operatorsas well as the ternary decision operator (?:). Thesix comparators, logical-and, logical-or and logical-not are available for creating conditions, and nested


<?xml version=”1.0”?><XFDL version=”4.0.0”>

<page sid=”p1”><label sid=”Title”>

<value>Pythagorean Theorem</value><fontinfo content=”array”>

<facename>Times</facename><ae>18</ae><ae>bold</ae>

</fontinfo></label><field sid=”A”>

<label>Enter side lenght A:</label><value>3</value>

</field><field sid=”B”>

<label>Enter side lenght B:</label><value>4</value>

</field><field sid=”C”>

<label>Hypotenuse lenght C is:</label><editstate>readonly</editstate><value content=”compute”>

<cval>5</cval><compute><![CDATA[

A.value <= ”0” || B.value <= ”0”? ”” : sgrt(A.value*A.value + B.value*B.value)

]]></compute>

</value></field>

</page></XFDL>

Fig. 2. An XFDL form.

decision logic is permitted. XFDL also provides nu-meric, financial, and string manipulation functions,as well as the ability to define new functions.

Operands are specified by a relative scoping no-tation that is rooted at the center by the optionidentifier. For example, fontinfo is the center ofp1.Title.fontinfo[0]. The static reference op-erator (.) is used before this option to ascend theelement hierarchy, and array brackets are used afterthe option to descend the element depth of arrays.The reference returns the specified element’s simplecharacter data content, or the content of the cvalsub-element if the specified element is computed.Hence, computed and non-computed options can beseamlessly integrated.

A reference need not list the entire element chainabove the option. Using relative scoping, the unspec-ified portion of a reference is assumed to be equalto the ancestor elements containing the reference.For example, in Fig. 2 the reference A.value in the

compute of field C’s value is assumed to refer to anitem A appearing on the same page as item C.

5.1.5. Use of cdata with computesSome computation operators, such as logical-and

(&&) and less-than (<), are forbidden by XML ascharacter data because more sophisticated parsingtechniques would be required to decide whether & ispart of an entity reference or when < is part of a startor end tag. Hence, computes that use XFDL decisionlogic are often enclosed in an XML CDATA section.

5.1.6. Compute parsing requirementsThe XFDL syntax rules allow a compute to con-

tain a mathematical expression or a decision state-ment, yet a conditional expression can also beginwith an arbitrarily long mathematical expression.Hence, a recursive descent parser will not suffice;an SLR(1) or better parser is required [1]. However,modules that simply need to process the XFDL form


as an XML document do not need an auxiliary parserbecause the compute can be treated as character data.

5.2. XFDL and DTDs

The DTD notation offered by XML is usefulfor some XML extension languages, but creating aDTD for a language with a mandate of XFDL’s sizeis not possible. DTDs were problematic from thebeginning of XFDL’s design because a DTD hasthe same expressive power as a regular expression,so XFDL computations (whose recognition requiresa parser rather than a lexical analyzer) could onlybe validated as PCDATA. However, the extensibilityof XFDL (the ability to create custom items andoptions) is the largest problem. A third obstaclewas the inability to enforce tag uniqueness but notelement order at the option level.

5.3. Reduced server-side processing via inputvalidation=formatting and calculations

One problem with paper-based systems is thehigh probability for introducing incorrect data intothe system. For instance, a person may write animproper date. Then the error is duplicated by dataentry clerks, and eventually integrated across theenterprise into departments such as purchasing andinventory. These front-end errors are costly. In largeorganizations, forms may go through dozens of stepsbefore reaching their final destination. Input errorsare expensive in this situation because they delay thestream of processing or cause the process to be rolledback and re-initiated. XFDL minimizes these typesof errors. For instance, a form field can be set up toaccept only dates or only integers in a certain range.XFDL defines a wide variety of data types, includ-ing dates, integers, floats, strings, and so on. XFDLalso allows for a variety of checks to be performed,including range, length, and template value compar-isons. Furthermore, XFDL computations also reduceserver-side processing by preventing math errors oncalculated fields.

5.4. Binary enclosures with Base-64 encoding

XFDL offers an internal flat-file system for enclo-sures. Enclosures can be of any type, and are grouped

into ‘folders’ for ease of use. Because enclosures aresigned, saved, and transmitted as part of the XFDLdocument, they too become part of the transactionrecord. This is useful for applications such as legalforms that require free-form statements as support-ing documentation, or online recruitment forms thatrequire resumes to be attached. Note that these enclo-sures often contain binary data, so they are convertedto Base-64 [17]. This is not human readable, butenclosures often represent digital images or soundswhich cannot be stored in a human-readable format.Attachments of other file formats are also possi-ble, with human readability being sacrificed for asmoother transition from opaque formats.

5.5. Precision layout for dense business andgovernment forms

Many organizations, especially those in govern-ment and in regulated industries like insurance andhealth care, have devised exhaustive rules for gov-erning the appearance of paper forms. It is importantthat these organizations have a method for preciselyreproducing the appearance of paper forms on theWeb, when even small changes in font color, size,and the layout of boxes and lines can seriously im-pact the legal viability of the form record [2]. UnlikeHTML and Java-based forms, XFDL documents al-low precise recreation of the layout and appearanceof paper forms on the Web. Although the accep-tance of Web technologies such as CSS [5] and XSL[12] promise to offer greater interface control, thesetechnologies currently only address the need for pre-cise presentation, not the need for viable transactionrecords. For instance, a style sheet cannot currentlybe inextricably bound to user-entered data.

Some organizations also require the ability toprecisely print forms, even after instituting a Web-based forms processing system. XFDL documentssupport precision printing for these situations. Thisfacilitates smoother transition from paper-based and‘fill-and-print’ processes.

5.6. Digital signature security and flexibility

XFDL defines a technology-neutral digital signa-ture interface that allows it to work with most com-mon digital signature systems, such as RSA, DSS,


biometric tokens, and so on. For cryptographic sig-natures, the signer’s public key certificate is includedwith the encrypted hash. In addition to verifyingthe encrypted hash, the certificate authority signatureon the signer’s public key certificate is also verifiedusing a certificate authority certificate on the verify-ing box. This simplifies the delivery of the signer’spublic key while preventing substitution attacks [7].

The digital signature hash value is not just com-puted on the entered data, as is the case with HTMLforms. The XFDL elements that contain the con-tent, context, and structure of the original form are‘locked down’ by the digital signature, in much thesame way that a paper form is considered to beimmutable once signed. The XFDL computes onsigned values are also discontinued, and the cvalelement content represents the computed value at thetime of signing.

XFDL also supports multiple overlapping signa-tures that apply to different sections of a form. Manycomplex paper forms require multiple levels of inputand approval. In this case, a multi-section form isused to gather the appropriate information and sig-natures. XFDL duplicates this facility with signaturefilters that specify either by inclusion or exclusionthe pages, items, and options to be signed by a partic-ular signature. Each signature item can have its ownsignature filter options, and the elements specified asbeing signed can overlap elements signed by othersignatures and can also include elements not signedby other signatures. In practice, an XFDL form canbe routed through an electronic workflow system,with each user adding the required information anddigital signature until the document is complete.

6. Conclusion: forms, XFDL, and electroniccommerce

“Soon, to the degree that the Web continues toevolve toward richer data representation and pro-prietary systems gain Web interfaces, XML willmediate the recreation of reality in cyberspace.”[19]

This paper has examined the role that paper formsplay in the business process, as well as the role towhich they will evolve in business-to-business elec-

tronic commerce. For centuries, organizations haveused documents to make legal representations. Fordecades, most of these documents have been forms.Effective electronic commerce technology must ac-commodate the business process. XFDL is a lan-guage that endeavors to ease the transition frompaper-based and fill-and-print systems to the Web bymirroring real-world requirements, rather than forc-ing organizations to adapt their business processes tonew technology.

Acknowledgements

Special thanks to David Manning, CTO ofUWI.Com, for direction and information. Thanksalso to Steve Shewchuk, Lori Waters, and Paul Chan.

References

[1] A. Aho, R. Sethi and J. Ullman, Compilers: Principles,Techniques, Tools, Addison-Wesley, Reading, MA, 1985.

[2] The Association for Information and Image Management(AIIM), Performance guideline for the legal acceptance ofrecords produced by information technology systems, PartIV: Model act and rule, Part 3. Also, Proposed modelrule for acceptance of records, §6. Criteria for determiningacceptance of records.

[3] M. Baum and R. Schwartz (Eds.), Digital Signature Guide-lines: Legal infrastructure for certification authorities andsecure electronic commerce, American Bar Association,Section of Science and Technology, 1996, http://www.abanet.org/scitech/ec/isc/dsgfree.html.

[4] R. Bertrand, J. Hearn and B. Lett, The North Americanpre- and post-processing equipment market: Capturing thebenefits and avoiding the pitfalls, Strategic Analysis Report,Gartner Group, September 26, 1995.

[5] B. Bos, H.K. Lie, C. Lilley and I. Jacobs (Eds.), CascadingStyle Sheets, Level2, CSS2 Specification, W3C recom-mendation, May 12, 1998, http://www.w3.org/TR/REC-CSS2/.

[6] J. Bosak, XML, Java, and the future of the Web, WorldWide Web Journal 2 (4) (1997) 220.

[7] J. Boyer, Digital signatures with the Microsoft CryptoAPI,Dr. Dobb’s Journal 286 (1998) June.

[8] J. Boyer, T. Bray and M. Gordon (Eds.), Extensible FormsDescription Language (XFDL) 4.0, W3C note, http://www.w3.org/TR/NOTE-XFDL.

[9] T. Bray, Personal communication to J. Boyer during thedesign phase of XFDL.

[10] T. Bray, J. Paoli and C.M. Sperberg-McQueen (Eds.), Ex-tensible Markup Language (XML) 1.0, W3C recommenda-


tion, February 1998, http://www.w3.org/TR/1998/REC-xml-149980110.

[11] R. Casonato, Integrated electronic form management strate-gies, Inside Gartner Group, February 21, 1996.

[12] J. Clark and S. Deach (Eds.), Extensible Stylesheet Lan-guage (XSL) 1.0, W3C Working Draft, August 18, 1998,http://www.w3.org/TR/WD-xsl.

[13] Cohasset Associates, Inc., Electronic commerce forms: Re-quirements, issues, and solutions, http://www.cohasset.com/uwi.

[14] T. Cormen, C. Leiserson and R. Rivest, Introduction toAlgorithms, The MIT Press, Cambridge, MA, 1990.

[15] Federal Rules of Evidence (FRE) 803(6).[16] Forrester Research, Inc., Resizing online business trade,

November 1998.[17] N. Freed and N. Borenstein, Multipurpose Internet Mail

Extensions (MIME) Part One: Format of Internet messagebodies, Innosoft, First Virtual, November 1996, http://ds.internic.net/rfc/rfc2045.txt.

[18] P. Ion and R. Miner (Eds.), Mathematical Markup Lan-guage, W3C recommendation, May 15, 1997. http://www.w3.org/TR/WD-math-970515/

[19] R. Khare and A. Rifkin, Capturing the state of distributedsystems with XML, World Wide Web Journal 2 (4) (1997)

207, http://www.cs.caltech.edu/¾adam/papers/xml/xml-for-archiving.html.

[20] R. Knox, XML: What is it and why should users care?Gartner Group Research Note, November 6, 1998.

Barclay Blair works in MarketingCommunications at UWI.Com. Hereceived a Professional Writing de-gree from the University of Victoria,and has been writing and speakingabout the Internet since the incep-tion of the World Wide Web.

John Boyer is a software develop-ment manager at UWI.Com and aco-editor of the XFDL specification.He is also a doctoral student in theComputer Science Department at theUniversity of Victoria.

Documents

XFDL: creating electronic commerce transaction records using XML