# Presentation: 346382

## XFDL Overview

- Presentation to XML.GOV
- July 23, 2003
- Keith MacKenzie – Director of Development

## XFDL: Extensible Forms Description Language

**Submitted to W3C (1998) as an application of XML**
**Allows organizations to remove paper from their business processes**
**Designed for high-value business-to-business e-commerce transactions where legal validity of transaction records is a priority**
**Dynamic interface, Security and Transport layer for data conforming to any XML Schema**

***Introduction***

- XFDL: Extensible Forms Description Language

## Understanding the need for forms

- Why are forms so pervasive?

***The primary user interface for business  ***

## Understanding the need for forms

- Brings structure to data

***Data Structures***
***  ***

**1. Paper Forms are Data Structures**

## Understanding the need for forms

- A unique user interface, in that they provide both:
- The template for the data collection
- The record or archive of the data collected

***User Interfaces***

**2. Paper Forms are User Interfaces**

## Understanding the need for forms

- Capture a fixed record of the state of the data at the time it is signed
- Indelible ink prevents tampering, signature provides authentication and authorization
- This feature is also a great hindrance to getting rid of paper
- Strict rules govern the legal admissibility of transaction records

***Transaction Records***

**3. Paper Forms are Transaction Records**

## Electronic Forms

- 	1. Be Valid transaction records
**	**Replace paper without compromising transaction integrity
- 	2. Make data accessible
- 	Allow data to integrate with other systems in an automated manner
- 	3. Simplify transaction processes
- 	Guide the user in the data entry process, reduce entry errors, facilitate business process automation

***Replacing paper***

## Valid Transaction Records

- Legal requirements for paper records have been established over many years
- XFDL replicates these requirements
- These requirements are based on three key concepts:
- Security
- Non-repudiation
- Auditability

***Specific requirements for the source documents behind transactions.   ***

## Valid Transaction Records

- These concepts are based upon a foundation of:
- signer authorization
- signer authentication
- document authentication
- context preservation

***Specific requirements have been developed for the source documents behind electronic transactions.   ***

- 1. Security

## Valid Transaction Records

- Content, context, and structure need to be preserved
- Paper forms accomplish this transparently, but it is difficult to achieve this in the digital world

***Specific requirements have been developed for the source documents behind electronic transactions.   ***

- 2. Non-repudiation

- 3. Auditability

- Valid transaction records must contain enough information to be part of an audit trail in for internal and external purposes

## Valid Transaction Records

- Most e-forms technologies do not naturally provide a strong transaction record. Why?
- Data is moved into and out of a presentation template, and these two components are independently stored
- Separation of data content and presentation context results in risk of transaction meaning being lost

***Why not use existing forms technology?   ***

- Existing Internet Technology

## Valid Transaction Records

- Example: applying for a $250K insurance policy online using an HTML form
- Claim repudiated -- how is it resolved
- Insurance company only has digitally signed tag=value pairs, not a complete transaction record
- Since the signature doesn’t cover the HTML form template, it can be changed independently
- Proper formulation includes the questions, the user’s answers, and a representation of how the document was presented to the user at the time it was all ‘locked down’ with a digital signature
- WHAT YOU SEE IS WHAT YOU SIGN!

***Example***

- Existing Internet Technology

## Valid Transaction Records

## Making Data Accessible

- Data captures in a form record must be easily made available to user systems
- XML Schema has evolved as the standard method to prescribe data structure
- Ability to directly support XML instance that complies with predefined Schema is important
- Presentation layer must provide a way to directly present, update, and extract instance for processing
- XFDL provides all this functionality

***Data Structure Definition***

## Rich Presentation

- Business Logic

- Data Instances

- Attached Files

- Making Data Accessible

## Slide 16

## Simplifying Transaction Process

- To go beyond paper, E-forms should:
- Simplify form filling of complex traditional forms by instead guiding a end-user: Wizard approach
- Exactly replicate traditional forms to ensure compliance with regulations
- Prompt the user for selection of valid values only
- Enforce data formats (date, zip code, phone number)
- Apply business rules at time of data entry
- Be state aware, to allow multiple users to focus on and update only their section
- Interoperate with workflow and process management engines

***Eforms can act as Business Process Automation agents***

## Simplifying Transaction Process

## Simplifying Transaction Process

## XFDL - Quick Feature Overview

- Stores each necessary element in a single, signable file
- Document-centrism simplifies transaction record administration and strengthens non-repudiation
- Replicates the features of paper forms while offering organization high-value business objects that can be manipulated, integrated, and stored digitally
- Supports XML Instances directly with a rich presentation, logic, and security layer

***Five major points***

- 1. XFDL is a document-centric markup language

## XFDL - Quick Feature Overview

- XFDL incorporates a rich, declarative, and extensible computation language
- Smart enough to make decisions, handle arithmetic, and respond to user input
- Fine-grained computational power
- Directs users through the interface, performing calculations and error correction on the fly
- All built into each document, which also provides nomadic capability

***Five major points***

- 2. XFDL is a 4th generation programming language

## XFDL - Quick Feature Overview

- No thread of execution to be managed
- Operates as a ‘state machine’
- Improves readability and simplicity
- No procedural JavaScript to write and maintain
- Assertion nature simplifies development of business logic

***Five major points***

- 3. XFDL is assertion-based

## XFDL - Quick Feature Overview

- Lifespan of transaction records is longer than any vendor or technology, so they must be open and understandable for document ‘future proofing’
- Semantics of the XML elements are known publicly – Complete language specification freely available
- XML Schema for XFDL language is available
- XFDL can be parsed and processed with any XML compliant parser or tool

***Five major points***

- 4. XFDL is human readable plain text

## XFDL - Quick Feature Overview

***Five major points***

- 5. XFDL provides direct support for any XML Instance

- XML Instances can exist within their own namespace within an XFDL document
- XFDL provides a method to bind XFDL presentation to items and attributes with these instances
- XFDL allows the submission of the whole document, or selected instances or portions of instances
- XFDL serves as a presentation and update layer for XML, with a minimum of transformation and integration effort

## XForms

***What is XForms?***

- XForms is an emerging standard from the W3C
- XForms 1.0 will be at recommendation status within one month
- Principle of XForms is to separate data from details of presentation
- Results in less secure transaction approach
- XForms requires a host language for the _specific_ presentation layer for XForms data, model and declaration of user interface requirements

## XForms Components

-  XForms is:
- comprised of separate sections that describe what the form does, and how the form looks. This allows for flexible presentation options, including classic XHTML forms, to be attached to an XML form definition.
- –W3C XForms Working Group
-  Two key components of XForms:
- XForms Model
- XForms User Interface

-  Source: W3C

## XFDL and XForms

***XFDL and XForms share a common approach***

- XFDL supports an arbitrary data instance, just like XForms
- XFDL can host an XForms data instance
- Instance exists in it’s own namespace
- Instance is bound to the XFDL presentation
- Instance data can be directly extracted from the XFDL presentation layer for incorporation in other systems

## XFDL and XForms

***XFDL and XForms work together***

- XForms 1.0 alone does not allow for securely signing presentation and data
- XForms 1.0 uses XFDL-like computation engine, but only supports simple computes at this time
- XFDL 6.0 compute language supports rich array of functions to solve current real-world business requirements
- XFDL augments XForms functionality by providing security and computational complexity

## XForms Future

***XForms looking forward***

- W3C has begun work on XForms 1.1 specification
- XForms 1.1 will result in a much more complete specification that better addresses security and computations
- PureEdge will continue to contribute to and lead XForms efforts
- XFDL will support additional XForms functionality as the standard matures

## Structural Overview of XFDL

***Sample Forms***

## Structural Overview of XFDL

***Sample Forms***

## Structural Overview of XFDL

***Sample Forms***

## Structural Overview of XFDL

***Sample Forms***

## Structural Overview of XFDL

***Sample Forms***

## Structural Overview of XFDL

***Sample Forms***

## Structural Overview of XFDL

***Sample Forms***

- Logo of Province of BC, Canada.  Can't you tell?
- Image in document: Underscores "What you see is what you sign"

## Pertinent Features of XFDL Structure

***Language Structure***

- Data Layer
- User input is stored in XML instances conforming to application-defined data structures (XML Schemata)
- User attachments stored in data items
- Presentation layer
- Presentation elements contain value options
- Images stored in data items (base 64)
- Presentation logic
- Presentation elements can contain ‘current value’ and a mathematical expression (compute attribute)

## Pertinent Features of XFDL Structure

***Language Structure***

- Digital signature on text copy of XFDL form
- =
- Signature on data, presentation, and logic
- =
**Transaction non-repudiation**

## XFDL Digital Signature Filters

***Why are they needed?***

- Some forms require multiple signatures
- Some forms require a user to only sign a portion of the form, e.g. signing the whole form except for the 'Office Use Only' section or sections for successive signers in a workflow.
- When additional documents must be enclosed by each signer in a workflow, they do not have an identity until created.
- “Intelligent Agent” forms have non-presentation elements which should not be covered by a user signature because they are associated with server-side applications (e.g. web services).

- Filters allow you to sign portions of the form.
- Why do we need them?

## Conclusion

***Conclusion***

-  XFDL is Document-Centric
- Forms that are like paper
- Bind data, presentation, and logic together
- Layering permitted within document
- XFDL contains an assertion-based computational language
- Calculations are declared
- Fine-grained logic for data AND presentation
- Easy to freeze state machine at time of signing
- Implements business rules
- Simplify form filling experience

***Conclusion***

- XFDL is human readable XML
- Future-proofing transaction records
- XFDL is an extensible container language
- Directly support data in any XML Schema
- Binds presentation to XML Instance
- Enclosure/Attachment of supporting documents
- Application-specific elements allowed