XFDL Overview

1
XFDL Overview

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

2
XFDL Extensible Forms Description Language
Developed by PureEdge and Tim Bray (co-author of
XML) 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
3
Understanding the need for forms
Over 80 of business documents are forms Why are
forms so pervasive?
The primary user interface for business
4
Understanding the need for forms
1. Paper Forms are Data Structures
Data Structures
Allow sets of data to be collected, organized,
classified, and understood Brings structure to
data
5
Understanding the need for forms
User Interfaces
2. Paper Forms are User Interfaces

• Simple and elegant way to provide an interface to
  users on both the front and back end
• A unique user interface, in that they provide
  both
• The template for the data collection
• The record or archive of the data collected

6
Understanding the need for forms
3. Paper Forms are Transaction Records
Transaction Records
Paper forms are contractual in nature, either
explicitly or implicitly 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
7
Electronic Forms
To be a better user interface electronic forms
need to 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
8
Valid Transaction Records
Specific requirements for the source documents
behind transactions.

• 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

9
Valid Transaction Records
1. Security

• 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.

10
Valid Transaction Records
Specific requirements have been developed for the
source documents behind electronic transactions.

2. Non-repudiation

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

3. Auditability
Valid transaction records must contain enough
information to be part of an audit trail in for
internal and external purposes
11
Valid Transaction Records
Existing Internet Technology
Why not use existing forms technology?

• 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

12
Valid Transaction Records
Existing Internet Technology
Example

• Example applying for a 250K insurance policy
  online using an HTML form
• Claim repudiated -- how is it resolved
• Insurance company only has digitally signed
  tagvalue pairs, not a complete transaction
  record
• Since the signature doesnt cover the HTML form
  template, it can be changed independently
• Proper formulation includes the questions, the
  users 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!

13
Valid Transaction Records
14
Making Data Accessible
Data Structure Definition
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
15
Making Data Accessible

• Rich Presentation

Business Logic
Data Instances
Attached Files
16
(No Transcript)
17
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
18
Simplifying Transaction Process
19
Simplifying Transaction Process
20
XFDL - Quick Feature Overview
1. XFDL is a document-centric markup language
Five major points
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
21
XFDL - Quick Feature Overview
Five major points
2. XFDL is a 4th generation programming language
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
22
XFDL - Quick Feature Overview
Five major points
3. XFDL is assertion-based
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
23
XFDL - Quick Feature Overview
4. XFDL is human readable plain text
Five major points
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
24
XFDL - Quick Feature Overview
5. XFDL provides direct support for any XML
Instance
Five major points
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
25
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
What is XForms?
26
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

27
XFDL and XForms
XFDL supports an arbitrary data instance, just
like XForms XFDL can host an XForms data
instance Instance exists in its 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 share a common approach
28
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
29
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
30
Structural Overview of XFDL
Sample Forms
31
Structural Overview of XFDL
Sample Forms
32
Structural Overview of XFDL
Sample Forms
33
Structural Overview of XFDL
Sample Forms
34
Structural Overview of XFDL
Sample Forms
35
Structural Overview of XFDL
Sample Forms
36
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"
37
Pertinent Features of XFDL 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)

Language Structure
38
Pertinent Features of XFDL Structure
Digital signature on text copy of XFDL form
Signature on data, presentation, and
logic Transaction non-repudiation
Language Structure
39
XFDL Digital Signature Filters
Filters allow you to sign portions of the
form. Why do we need them?
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).
40
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

41
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