XFDL 
e-commerce non-repudiation | Using to create information support for management applications | Table of contents | Indexes | XML Use by US Intelligence: A Case Study | |||
| XFDL e-commerce non-repudiation | XFDL - Representing Business and Government Forms in XML |
| British Columbia Canada Manning, David F. UWI.Com - the InternetForms Company Victoria | David F.
Manning
CTO and Vice-President of Development, UWI.Com - the InternetForms Company
Biographical notice David Manning co-founded UWI.Com in 1993. As the company's chief technical officer, he has supervised the development of UWI.Com's InternetForms technology from the beginning. Previous to founding UWI.Com, Mr. Manning gained expertise in network environments as a researcher at the University of Victoria. Mr. Manning's other credits include guest lectures for the Conference Board of Canada and the Advanced Systems Institute. He has also been recognized by the federal government of Canada as a pioneer on the Information Highway. |
| XFDL | Introduction XFDL - Representing Business and Government Forms in XML |
| For some time now, organizations have been looking to Internet technology to save them money. The theory is that, with a global communications network and a common set of tools, organizations can realize tremendous gains in efficiency. Now that the basic network infrastructure is reasonably well established, a great deal of work is being done to develop new business protocols and the tools to use them. |
| XFDL (Extensible Forms Description Language) is an XML-based language designed to represent complex business forms on the Web. XFDL was co-authored by UWI.Com and Tim Bray, one of the editors of the original XML specification. XFDL includes support for high precision layout, context- sensitive help, integrated computations and input validation, multiple overlapping digital signatures, and auditable transaction records. |
| Do we really need a language just for describing business forms on the Web? What about HTML and Java? Besides, aren't forms supposed to disappear in a wired world? |
| This paper explores XFDL, the business problems it addresses, and the questions it raises. Perhaps the best place to start in our exploration is with a quick look at where we are and where we want to go. |
| Introduction E-Business? |
| When we talk about the allure of "e-business," we speak of a desire to replace slow and expensive paper processes with fast and inexpensive digital ones. The business case for moving from a paper-based transaction system to an electronic one is simple and has been made a thousand times: conducting business digitally is cheaper and allows us to provide better customer service. The emergence of a ubiquitous, worldwide computer network (the Internet) and a set of common communication protocols (TCP/IP) further increases the attractiveness of doing e-business. The Internet can now provide most of the basic infrastructure necessary to communicate with our co-workers, business partners, and customers. |
| For years now, Internet email (SMTP) has provided us with a common, but limited, person-to-person messaging system and the World Wide Web (HTML/HTTP) has provided us with a versatile mechanism for publishing and collecting information. However, even with these significant advances, the true promise of doing business on the Internet has yet to be realized. We still lack the tools necessary to automate many of our more complex business processes. |
| Introduction The XML Revolution |
| XML has been heralded as a key, missing piece of the e-business puzzle. Since most significant business transactions involve the communication of some form of structured data, having a standard syntax for creating and exchanging data structures is obviously an important step. Using XML, businesses and governments will be able to leverage their IT investments over a variety of applications. Also, because XML is an open standard, its users can be confident that they will not be locked into a legacy of opaque binary data. In short, XML's simplicity and flexibility have made it an ideal foundation on which to build e-business initiatives. |
| However, XML is not an e-business solution in itself. XML provides a mechanism with which languages can be defined. XML is, if you will, a meta-language - a language in which other languages can be created. XML will let you define a particular data structure, but it won't tell you what that data structure means. A lot of work has yet to be done in defining XML languages (called Document Type Definitions or "DTDs") that will allow us to exchange meaningful messages. Progress is being made - it seems like new e-business DTDs are popping up every day. |
| XFDL e-commerce | Introduction XML and Forms --A Match Made in Heaven |
| When one considers the pervasiveness of paper forms in business (Gartner Group estimates that 83% of all business documents are forms), it is obvious that a mechanism for replacing paper forms is required for any serious electronic commerce initiative. With the advent and immense popularity of XML, and the inherently structured nature of form documents, providing that mechanism as an XML-based language is an obvious choice. This is exactly what XFDL attempts to do. |
| Does XFDL meet its objectives? Will XFDL play an important role in e-business initiatives? In order to answer these questions, we need to answer three, more basic ones. First, what is the role that forms in general will play in e-commerce initiatives? Second, does XFDL have the ability to fill that role? Third, can existing, non-forms-specific Internet technologies such as HTML and Java be used to replace the functions of paper forms in an e-business environment? Both of these languages have some forms capability and are well established in the Internet community. |
| non-repudiation | Introduction Why Forms? |
| We all know that paper forms are everywhere, but it is not instantly obvious why this is so (we know that it's not their inherent lovability). What properties do paper forms have that make them so useful? By answering this question, we can more clearly understand what technologies are required to replace them. Here are the three obvious functions that paper forms now serve in our organizations: |
| Introduction Paper forms are data structures. |
| Paper forms allow specific data sets to be easily classified and understood. Without a structured way of representing data, high-volume business processes would be very difficult to organize and implement. Imagine the chaos that would result in any large purchasing department if it received all of its communications as free-form letters. Forms allow us to operate our businesses efficiently by giving us the ability to define exactly what information types and formats are required in a given transaction. |
| The notion of data structures is (surprise, surprise) by no means foreign to IT systems. The big problem is getting IT systems to manage free-form data, not of the other way around. There are many Internet protocols currently being developed to allow businesses to perform structured communications. XML itself provides a great deal of document structure, and there are many initiatives like XML/EDI and Veo Systems' CBL that are well on the way to providing good frameworks for common business transactions. |
| It would seem that the problem of providing structured methods for communicating business information is well in hand. |
| Introduction Paper forms are user interfaces. |
| Paper forms are a simple way for users to provide information to a corporate system. As with any user interface, there are elements inherent to a well-designed form's layout and formatting that make it easy for a user to give and receive information. |
| There are many existing Internet technologies that can be used to provide effective GUIs. Java can, with considerable effort, be used to create substantial, effective, user-friendly interfaces. HTML can also be used to create very simple GUIs. While duplicating the user interface of a complex business or government form in either of these languages involves considerable pain and suffering, one of them can usually be made to do the job. |
| So, if we have EDI-type mechanisms for sending structured messages, and HTML or Java for coding user interfaces, why do we need a special language just for creating complex forms? |
| There is, of course, one requirement left to consider. |
| Introduction Paper forms are transactional records. |
| This is perhaps the most important function that paper forms fill in the business world. Most paper forms create an implicit or explicit contractual agreement. That's why we sign them. When a user signs a paper form, a "transactional record" is created. This transactional record represents an event of commercial exchange and can be used to provide evidence of that event should the need arise. |
| Consider the following scenario: |
| Bob, a lifetime smoker, decides to purchase life insurance. In the process of doing so he is required to fill out an application form. Bob, being an honest fellow, checks "yes" in the box next the question, "do you smoke?" Both Bob and the insurance agent then sign the application form. |
| Once the form is signed, the insurance agent gives Bob a copy and also files a copy with the insurance company. This is done to provide both parties with "non-repudiation" -- the ability to prove the context and content of the contractual agreement. Consequently, if there were ever a dispute over the collection of the insurance policy, the application would form a key piece of evidence. Issues of authenticity, wording, comprehension, and completeness could all be examined to determine the form's meaning and the subsequent enforceability of the insurance policy. In legal circles, a document like Bob's life insurance application form is known as a "source document." |
| In the event of a dispute over collection of the policy, Bob's family has a copy of the form that proves that Bob was honest about his smoking habit. Furthermore, because the insurance company also has a copy of the form they too can prove the exact nature of the agreement - right down to the fine print on the back. |
| In regulated industries like health care and insurance, there are very strict rules that govern the maintenance of transactional records. Even in less regulated environments, companies need the ability to exchange contractual documents if they are going to enter into agreements with individuals and other organizations. |
| XFDL non-repudiation | Introduction So What About HTML and Java? |
| The Association for Information and Image Management (AIIM) created a Performance Guideline for the Legal Acceptance of Records Produced by Information Technology Systems. In these guidelines they assert: |
| "The following shall appear with sufficient clarity so that each can be recognized: |
| Simply translated, this means that a document isn't a document unless its all there. Showing somebody a snippet of a document is not showing them the document - and just keeping snippets of your documents is not keeping a legal, auditable records. |
| In the above insurance example, being able to prove that Bob said "yes" to a question without being able to prove that the question was "do you smoke?" is meaningless. The insurance company could attempt to produce the original Web page or Java applet that they claim Bob used, but there is no way for them to decisively prove what Bob was looking at when he answered "yes." This is a significant issue when you consider that even the size and color of type on a form can contribute to its legal weight. |
| What then does this mean when we consider transacting business over the Internet? What technological issues need to be considered? |
| It is clear that HTML, Java, or EDI-type systems don't fill this need. When a user completes an HTML form, only the input data (the answers) gets sent back to the server. While this allows the server to collect the data, it does not provide any level of non-repudiation. Even if the user were to sign the returned data using a digital signature, the record would be legally meaningless. After all, what good is being able to prove what the answer was without being able to do the same with the question? |
| Java systems usually have the same problem - they store and transmit the data files separately from their presentation (the Java classes). |
| EDI systems don't even try to define a user interface. EDI is really only about agreeing on which bits of data mean what. In EDI systems the way the data is displayed is usually left up to some sort of unspecified mechanism that is designed to interpret the EDI message. (XFDL might make a very good front end for traditional EDI systems.) |
| Most existing Internet protocols can't address this issue because of the philosophy behind their basic architecture. Traditionally, engineers have divided an application's data, presentation, and logic into separate, clearly-defined architectural layers. This approach to systems architecture has a great deal of merit - stratification provides a tremendous degree of flexibility. In a stratified information system, GUIs can be changed and extended without modifying the underlying data, new data sets can be used while maintaining a consistent look-and-feel for the users, and modifications can be made to the application's logic without effecting the existing GUIs or the underlying data. |
| Unfortunately, this elegant flexibility is exactly what we don't want in our transactional records. The ability to easily change the questions (GUI) while keeping the answers (data) constant would significantly diminish a transaction record's legal meaning. |
| At the end of the day, data collected in an HTML form or a Java applet is just that - data. Legally viable transaction records cannot be created unless there is an ability to bind the data to the context in which it was collected. |
| Introduction What are People Doing Now? |
| Not many companies are doing contractual forms electronically. Those that are seem to be adopting a variation on one of the following approaches: |
| Introduction Fill and Print |
| Many companies approach this problem using paper/digital hybrids. These companies use an electronic forms package to design, distribute, and fill their forms. However, to create viable transaction records, these forms must be printed and signed the old-fashioned way. The paper record is then filed manually or scanned into a digital imaging system for archiving. The disadvantages of this approach are clear. A great deal of money could be saved if the form was kept in a digital format throughout the entire process. |
| Introduction Hope for the Best |
| In the absence of reliable electronic transaction records, the parties involved in a transaction simply have to accept the risk of liability. Some small-value transactions are currently being conducted on a "faith" basis. If the transaction falls into dispute, it is understood that one party (usually the larger one) will simply eat the loss. Larger partners sometimes enter into "blanket" agreements that define the specific resolution mechanisms should disputes arise. |
| In either case, these solutions are far from perfect. Current mechanisms for dealing with this issue are costly and vulnerable to abuse. A better system - one that more closely approximates our existing paper business practices - is required. |
| XFDL | Introduction XFDL |
| XFDL was designed to replace paper forms. XFDL does this by addressing each of the functions that paper forms fill in an organization. |
| XFDL is highly structured. XFDL forms are composed of any number of discrete form "pages" and "items." Each item can enforce a wide variety of type checking and data formatting. While XFDL in no way competes with EDI-type protocols (XFDL does not try to assign any business-specific semantics to form items), it does provide a structured messaging system. |
| XFDL has been designed to make it very easy to represent any paper form electronically. For instance, XFDL forms can be multi-page. They can contain almost any item type (buttons, fields, lists, etc.) and items can be placed on them using a precise positioning scheme. XFDL also contains an advanced computational mechanism that allows the forms UI to be highly-interactive and responsive to a user's input. |
| XFDL forms are objects that contain all the data, presentation, and logic for that form. When a user digitally signs an XFDL form (or a piece of one), the whole document context is captured. This means that, if necessary, an XFDL form can be used to prove exactly what was signed (right down to the fine print), just like the paper document. |
| Despite my cheerleading, XFDL is not perfectly suited for all applications. After all, some paper forms really are just about collecting data - they are not all that complex and no legal representations are being made. In those cases HTML, Java, and other similar technologies should be seriously considered. The absolute ubiquity of HTML and Java on the Web are powerful arguments for their use. |
| XFDL non-repudiation | Introduction How does XFDL work? |
| Introduction XFDL is a regenerative language. |
| XFDL is an interesting hybrid of document markup (XML) and programming language. Like many XML languages, XFDL is regenerative. Simply put, this means that when an XFDL document is viewed, edited, and saved (signed, transmitted, etc) the document source is regenerated with the user's edits included. In this way the user's input is kept in the same record as the rest of the form. This is one of the key properties that allows XFDL to act as a transactional record. |
| Introduction XFDL is a computational language. |
| This is the other half of XFDL's strange hybrid. Unlike most XML-based languages, XFDL is an actual programming language. XFDL can make decisions, do arithmetic, and respond to user input. You can even write simple games in XFDL (if you get bored with forms). This computational power allows XFDL to do all of the math and logic that is commonly associated with forms. |
| Because the form directs the user's actions, input mistakes are drastically reduced. Anyone who has made a mistake on their tax form can understand the value of this feature. |
| Furthermore, because the form's logic is embedded in the form document itself, it too is signed and becomes part of the form's transactional record. Embedding the logic in the form also has the pleasant side effect of allowing the form to be completed off-line, which makes nomadic data collection on Palm PCs possible. |
| It should be noted here that an infix notation was chosen to initially represent computations within XFDL. Allowance was made in the XFDL specification for supporting the prefix semantics of MathML in future versions. This choice was made for several reasons. The first and most important reason was legibility. Understanding simple calculations in an infix notation is fairly intuitive; doing so in a prefix notation is not. This problem was doubly aggravated when complex decision logic was represented. One line infix statements required ten to twenty lines of prefix code. |
| Introduction XFDL is assertion-based. |
| This is an addendum to the previous point. XFDL's computational logic is expressed using assertions. Unlike most traditional programming languages that function on a procedural model, there is no "thread of execution" to be managed in XFDL. Creating computations in XFDL is much like using a spread sheet - if you want field #1 to be the sum of field #2 and field #3, you just tell field #1 that this is the case. The XFDL language makes sure that this is always true. |
| XFDL was engineered as an assertion-based language for two reasons. First, the kind of logic that gets used in complex forms is very easy to describe using assertions. Trying to catch events and run procedural code is overly complicated when all you really want is "field #1 to be the sum of field #2 and field #3." Second, an assertion-based language makes it very easy to freeze the exact state of a form when the user decides to save it, sign it, or send it to a server. In order to capture the exact state of a program written in a procedural programming language, you would need to capture a lot of information (the heap, the call stack, the data and code segments, etc). Even once this information was captured, it would be very hard to interpret. By running a form as a "state machine," it is very easy to take a snapshot of the form at any moment during in its execution. |
| Introduction XFDL is open. |
| In keeping with the Internet tradition of openness, XFDL is available for use by anybody, for any purpose. Because it is based on XML, XFDL is easy to generate and manipulate using any of the free XML-enabled tools on the Web. While openness is important for any Internet protocol (the days when organizations were willing to use opaque, proprietary solutions are long gone) it is doubly so for an electronic forms language. |
| The first and most obvious reason that XFDL's openness is important is embodied is one of its stated design goals: XFDL forms have to act as transactional records. Implicit in this goal is the facility for third party validation. What good is a legal record if only the record's owner can understand it? What proof does a record provide if we have to take the record owner's word as to its meaning ("trust me Bob, we don't owe you a dime.")? |
| Second, the nature of XFDL is such that organizations will want to use it to store important business information. The lifetime of a business document is often much longer than that of any particular Internet technology (or Internet technology vendor). Obviously any organization would be very nervous about using a proprietary language for these purposes. |
| Introduction XFDL is about forms. |
| There is an often-quoted design goal for computer languages: "Simple things should be simple." Because XFDL has been engineered to create forms, there are a lot of forms-specific conveniences built into the language. Most of these things are not major architectural issues - they are the little things that save time and money when it's time for implementation. A brief list of these features follows: |
| XFDL non-repudiation | Introduction Summary |
| As public and private sector organizations start incorporating Internet technologies into their core business systems, there will also be a need to replace a large number of their paper forms processes. While some of these systems can, and should, be implemented using HTML or Java, many should not. Complex forms, or forms that create implicit or explicit contractual agreements require another approach. |
| XFDL's document-centric architecture was designed to reproduce paper forms. By keeping a form's data, presentation, and logic together in a single record, XFDL can provide the legal non-repudiation not offered in many forms applications. Further, XFDL's forms-specific functionality makes it a powerful language for moving complex paper forms to the Web. |
| From the above analysis, it is clear that XFDL addresses real needs. We have used documents to make legal representations for centuries. For decades, most of these documents have been forms. The way we do business will have to be accommodated by the technology we use to do it. |
| This being said, XFDL is a new language. The initial response from the analysts, businesses, and the media has been quite positive. Whether or not XFDL will gain the market acceptance required to become a ubiquitous standard remains to be seen. |
| Using to create information support for management applications | Table of contents | Indexes | XML Use by US Intelligence: A Case Study | |||