In December 2002, the E-Gov office of the Office of Management and Budget (OMB) requested the Chief Information Officer Council (CIOC) to assess how electronic forms (e-forms) technologies and standards could be leveraged to accomplish E-Gov program goals.
The XML Web Services Working Group (XML WS-WG), under the leadership of Brand Neimann, accepted this task, and stood up the "E-Forms for E-Gov" pilot in February 2003.
The primary goal of the pilot is to determine best practices, and identify business metrics for changing to an e-forms process to support GPEA, the President's E-Gov mandate, and the Performance Reference Model (PRM) required by the Federal Enterprise Architecture (FEA). This paper represents the culmination of the pilot team's work.
For more information, see:
The E-Forms pilot conducted its analysis work through an open and collaborative team that included broad representation from the federal government and the vendor community. A list of participants is included in Appendix A.
The pilot team held monthly meetings from March 2003 through July 2003, and formed a number of sub-teams to conduct detailed assessments of specific problem domains. Where possible, the sub-teams included members from multiple federal agencies and multiple vendors.
A few of the sub-teams did not have adequate representation, so remained dormant. The active sub-team reports are summarized in Section 6.0 of this document, and the Pilot Chair (Rick Rogers, Fenestra) has included his own assessments for the dormant teams.
An electronic form (e-form) is a self-contained collection of declarative meta-data that defines how a form is to be "realized" via generalized computer software - in other words, an "e-form" defines how a form should look, behave, and operate on a computer. An e-form allows the capture of a response dataset, which represents the data provided by a respondent via keyboard entry, importing, or other means.
Many software applications capture responses - for example, any application that includes a user-interface that allows input of data values from the keyboard supports response dataset capture. E-Forms are distinct from standard custom-coded data-entry applications in the respect that e-forms are self contained declarative meta-data, and applications that process e-forms are generic and meta-data driven.
This generalized meta-data driven aspect of e-forms offers powerful technical advantages:
Reduced costs. Generic e-forms software applications can be used to realize and process any number of e-forms, thus reducing the number of applications to be procured/built, maintained, deployed, and supported. Also, collecting data electronically is demonstrably cheaper than collecting it via paper.
Component-based architecture. Self-contained declarative meta-data facilitates a component-based architecture, because different components an be plugged into parts of the system to operate on the standardized and generalized e-forms meta-data.
Reuse and Harmonization. Constructing electronic forms from meta-data promotes the reuse of meta-data across forms, which in turn reduces forms authoring costs, and facilitates harmonization across forms.
Scalability. Adding a new e-form to an existing e-forms system simply entails defining the e-form meta-data - it does not entail creating any new software. With appropriately user-friendly e-forms authoring tools, non-programmers can easily add new e-forms to the system.
Consistency. Because e-forms capture the way a form should look, behave, and operate in declarative meta-data, there is a large degree of inherent consistency across forms. This consistency benefits the respondents, and also the back-end processing systems that use the response datasets.
Timeliness and Accuracy. Capturing data from e-forms is nearly always demonstrably faster than capturing data from paper, and the built-in validations in e-forms ensure a higher degree of accuracy.
E-Forms incur a few disadvantages, which must be recognized:
Restrictiveness. This is the flip-side of consistency. A custom-coded application can do literally anything that the host programming language allows - this provides maximum flexibility. The declarative meta-data driven approach of e-forms means that the capabilities and features of the form are constrained by the meta-data standard used to define the form, and the extent to which generic software components correctly and completely implement that standard.
Potential for Vendor Lock-in and Dependency. There are many e-forms meta-data definitions, a few of which are fully based on Voluntary Community Standards (as defined by OMB Circular A-119), and many of which are not. In addition, the standards in this domain are currently in flux. Systems that are not standards-based are frequently only supported by one specific vendor, and even some standards-based systems have support from only one vendor.
This means that in the current landscape, using e-forms involves some degree of vendor lock-in, because the vendor must provide and maintain the generic components to operate on their "flavor" of e-form meta-data. Hopefully this will change over time as the many e-forms standardization efforts (such as XForms) become more widely adopted and supported.
The current e-forms landscape faces some challenges that are worth noting:
Incomplete Integration with Web Browsers. The most ubiquitous, generic, and popular user-interface is the generic HTML web browser. However, web browsers do not natively support many of the advanced features and capabilities present in e-forms meta-data standards. For example, the presentation language of the web, HTML, is quite limited in its typographical capabilities, particularly for domains where precise typography is required (such as legally binding documents).
This has led to a situation where nearly all of the major e-forms vendors implement their e-forms user-interfaces in applications that are separate from the web browsers, and which are deployed as stand-alone client applications, or browser plug-ins, or both. These applications are known as form-fill applications, or as e-forms user agents.
This situation forces a difficult choice between targeting the ubiquitous but limited web, versus adopting a richer e-forms meta-data system that requires a separate application to be deployed. Because of the high cost of deploying custom applications, the current situation has slowed adoption of e-form systems.
Lack of Standard Component Stack. There are many different standards that cover different segments of the e-forms problem domain (e.g., XML, XML Schema, XML Web Services, WebDav, ISO 11179, UBL, SVG, HTML, etc.).
There are also many types of generic e-forms services that could leverage these standards and be exposed as standardized components (e.g., forms catalog, schema registry, forms authoring component, forms user-interface agent, response dataset submission server, response dataset repository, etc.).
However, there is no standards-based component stack that pulls together all the individual standards to define how the components should work together. While many e-forms product vendors support selected standards, the lack of a standards-based component stack means that different e-forms solutions are only marginally interoperable with each other. This situation further increases vendor lock-in and dependency.
Security and Privacy. The most secure/private e-forms solutions (for example, Public Key Infrastructures) also involve significant expense and logistical tradeoffs. The lack of an inexpensive and easy-to-manage security infrastructure hampers adoption of e-forms that capture sensitive information.
In one sense, the business case for electronic forms within the federal government is already made because it the Government Paperwork Elimination Act (GPEA) mandates electronic forms. In another sense, it is important to map the benefits of investments in e-forms to performance measures, as required by the Federal Enterprise Architecture (FEA) and its Performance Reference Model (PRM).
Forms lie at the heart of many federal government processes, and much of the data collected by the government is collected via forms. As such, forms (and e-forms) can map to all of the mission and business results measurement categories defined in the PRM and the Business Reference Model (BRM).
Put another way, forms already facilitate nearly every mission and business result in the federal government to some degree, and e-forms can be leveraged in place of forms.
E-Forms particularly contribute to customer results, in the sense that the technical advantages they offer translate directly to customer results.
The principal and most important customer result e-forms offer is reduction of burden on both citizens and businesses. In the PRM, this is the Customer Results: Customer Benefit: Customer Impact or Burden measurement category.
The "Final Report of the Small Business Paperwork Relief Task Force" from the Small Business Administration (SBA) cites an Office of Management and Budget (OMB) analysis that illustrates the dimension of federal paperwork burden:
"OMB estimates the cost to provide data required by all approved information collection requests in Fiscal Year 2003 was approximately 8.2 billion hours and $320 billion. OMB’s estimates reflect data provided by the collecting agencies,and may understate the actual burden imposed on the public."
E-Forms technology is specifically designed to make filling in forms easier, and if by so doing e-forms reduce the burden even marginally, the improved customer results are enormous. Here are some specific ways e-forms can reduce burden:
Automate providing responses. E-forms can automate the process of providing responses, through a number of strategies, including: importing response data from existing data stores; pre-populating new forms with data from previous forms; automatically filling-in responses based on other responses.
Simplify and harmonize forms. The meta-data driven aspect of e-forms facilitates reuse of components of forms (such as questions) and harmonization across forms. This promotes data sharing within the federal government, and potentially reduces the number of federal forms facing the citizens and businesses. Semantic technology and interview-style design can also be employed with e-forms to reduce and simplify the data collection facing the customer.
Facilitate information exchange. The meta-data driven aspect of e-forms also facilitates direct information exchange between systems, which means customers could bypass forms entirely and provide requested information to the government via direct information exchange.
In addition to reducing response burden, general e-forms solutions map to other PRM "Customer Results", including (but not limited to):
Customer Benefit: Customer Satisfaction. Reducing the response burden imposed by forms often leads to increased customer satisfaction.
Service Coverage: Service Efficiency. E-Forms that are tied into a back-end processing can improve the efficiency of the customer service through turnaround time on processing responses. The same benefit also applies to the Timeliness & Responsiveness category.
Service Accessibility. Making e-forms available via the web improves their availability, and when properly automated and integrated with back-end processing systems, ensures a high degree of service accessibility. Many e-forms meta-data standards also provide advanced Section 508 accessibility capabilities.
In general, e-forms solutions map to several PRM "Processes and Activities" results, including (but not limited to):
Financial: Savings & Cost Avoidance. When integrated with back-end processing systems, can provide significant savings. For example, e-forms reduce the printing, mailout, paper-handling, and keying costs associated with paper forms.
Cycle Time & Timeliness. As part of a fully automated processing system, e-forms can reduce the cycle time for processing response datasets and increase the timeliness of outputs (statistical reports, service requests, etc.) of the transaction initiated by the e-form submission.
Quality: Errors. Because e-forms allow validation of response data as it is being created by the customer, e-forms reduce errors and improve the quality of the captured responses.
How an e-forms solution maps to most of the PRM "Technology" results depends largely on the e-forms solution and how it compares to possible alternatives in detailed performance metrics.
In general, e-forms solutions strongly promote all five of the generic measurements in the "Information & Data" category: External Data Sharing; Data Standardization or Tagging; Internal Data Sharing; Data Reliability & Quality; and Data Storage. E-Forms contribute to these results because their meta-data driven approach facilitates tagging, harmonization, and reuse
For more information, see:
This section recommends a nominal set of components in e-forms solutions.
As mentioned in Section 3.3, there is no standard e-forms component stack, so the components identified in this section just provide a context for understanding the capabilities of e-forms products. Hopefully, future standards development will formalize the kinds of services to be provided by these components.
E-Forms Authoring Component. Allows a non-programmer to define the meta-data which comprises an e-form, including presentation, content, structure, and behavior. Includes a user-interface that allows people to design e-forms.
E-Forms Generator Component. Builds e-forms automatically from existing meta-data. In some scenarios e-forms do not need to be manually designed with the authoring component - instead, they can be generated automatically from existing meta-data.
E-Forms User Agent Component. Provides a user-interface that allows a respondent to create the response dataset for the e-form. Also known as a "form fill" component. Supports filling forms, signing forms, and submitting forms.
E-Forms Web Broker Component. Translates the meta-data contained in an e-forms document into standard HTML and serves it up via a standard web server to the standard web browsers. This serves as an alternative to an E-Forms User Agent, because it allows the standard web browser to serve as the user-interface.
E-Forms Catalog Component. Serves as a registry for published e-forms, and includes respondent profile information so that respondents can find forms which apply to them.
E-Forms Schema Registry Component. Serves as a registry for the response dataset schemas used by e-forms. Facilitates schema reuse and harmonization, and facilitates direct information exchange (since exchange uses the same schemas).
E-Forms Submission Server Component. Serves as a collection point for submitted e-forms, and routes (and possibly reformats) the submissions to appropriate back-end processing systems. Maintains submission status and history.
E-Form Authentication Component. Authenticates e-forms respondents and their signatures.
E-Forms Workflow Component. Performs standard workflow management for e-forms documents, including routing, approval, etc.
No available e-forms solution today segments its software into all of these components, but the components presented here offer a way to asses the types of services that can be provided within specific solutions.
The "E-Forms for E-Gov" pilot subdivided into sub-teams to assess technology and standards for the key e-forms problem domains. This section captures that assessment.
E-Forms capture responses to fields, also known as data elements, or just elements. Most e-form meta-data standards specify meta-data that describes the attributes of these elements, including name, data type, length, context, etc. The collection of these element definitions for a particular e-form is called a schema.
There are several voluntary community standards that cover the schema domain, with the two in widest use today being the International Standards Organization (ISO) 11179 "Specification and Standardization of Data Elements" standard, and the World Wide Web Consortium (W3C) "XML Schema" standard. ISO 11179 and XML Schema are largely complimentary, and can be supported simultaneously.
ISO 11179 and XML Schema are lower level syntactic standards that define the physical characteristics of elements. There are also higher level standards, such as the OASIS Universal Business Language (UBL), and the XML Business Reporting Language (XBRL), that arrange elements into semantic structures appropriate for different contexts. Other relevant schema standards include the OASIS Relax standard.
The E-Government initiatives within the federal government employ XML as a core technology to enable data interoperability, exchange, and reuse. As such, XML Schema is a vital standard for E-Forms products to support - without native XML Schema support, an E-Forms product cannot plug into the E-Government framework.
The E-Forms for E-Gov pilot team for schema developed a set of recommendations for designing e-forms schemas. It is available at:
http://www.fenestra.com/eforms/downloads/Schema_Design_ Recommendations3.doc
For more information, see:
When an e-form captures electronic responses according to a schema, it stores them in a response dataset.
While there are some legacy voluntary standards and properietary systems for modeling response datasets, the clear mandate is to use the W3C "Extensible Markup Language" (XML) standard for response datasets. This means that each e-form's responses are captured in an XML document, that conforms to the e-forms schema.
Using XML to represent the e-forms response datasets allows the submitted e-forms responses to be automatically processed by tools that support XML, such as the native XML support available in some relational databases, XML transformations in tools that support the Extensible Stylesheet Transformation Language (XSLT), middleware applications that support XML-based routing and workflow, etc.
E-Forms solutions that are not based on XML will probably require a tranformation layer to translate their propertiery representation of response datasets to XML, so that the responses can be plugged into the plethora of XML-enabled applications available today.
E-Forms include a presentation layer, which is the user-interface for the form itself - that is, how the form looks.
Presentation standards can be absolute or relative. Absolute presentation standards precisely describe the typographical layout of the e-form in a way that is consistenty reproducible regardless of system-specific capabilities such as installed fonts, screen resolution, user-preferences, window size, etc. Relative presentation standards allow the layout to be targetted to system-specific attributes.
The most widely known example of an absolute presentation standard is the proprietary Adobe Portable Document Format (PDF). Within practical limits, a PDF document will look the same on any device on which it is displayed. The most widely known example of an relative presentation standard is the Hypertext Markup Language (HTML). An HTML document can look different on each device, depending on the size of the web browser window, the fonts installed, user preferences (such as relative font sizes), etc.
Like any technology trade-off, there are advantages and disadvantages to both approaches. Absolute presentation standards ensure device-independence for the document's appearance, which can be critical for legal or archival purposes. However, the main trade-off is a typically much larger set of meta-data to describe the typography (making absolute e-forms documents larger). Relative presentation standards allow for smaller e-forms documents that can be reproduced reasonably under many different situations, at the cost of precision.
Other relevant standards include the W3C Extensible Stylesheet Formatting Objects (XSL-FO), W3C Scaleable Vector Graphics (SVG), and the proprietary XML Forms Description Language (XFDL) from PureEdge. XSL-FO and XFDL are relative, while SVG is flexible enough to be either relative or absolute.
Any e-forms standard will primarily target on-screen presentation of the form. However, the government will be producing paper forms side-by-side with electronic forms in many contexts for the foreseable future. There are some advantages to producing a highly capable presentation language that can work well for both the paper and electronic targets.
HTML, for example, while ubiquitous for electronic user-interfaces, is not suited for producing paper layouts for all but the simplest government forms. This means that if HTML is used for electronic presentation, a second presentation standard would need to e used for paper presentation. The SVG standard, with its robust and precise typographical cababilities (including full support for absolute device-independence), is very promising in this area.
Several of these presentation standards are used in conjunction with the W3C Cascading Style Sheets (CSS) to provide style-based markup, and the W3C Extensible Stylesheet Transformation Language (XSLT) to transform XML-based content into XML-based presentation.
For more information, see:
E-Forms can include a content layer, which is the underlying structure of the questions on the form. For example, an e-form's content might arrange questions, sub-questions, items, etc., into an "outline" tree structure.
There is some debate in the e-forms community about whether a content layer is necessary. It is quite possible to shift the content meta-data to the presentation backplane layer - in other words, the content structure is not separately maintained, and the content is shifted to the presentation. Several popular e-forms solutions (including Adobe Acrobat) take the approach of shifting content to the presentation layer, and not explicitly maintaining content.
The prinicipal standard for e-forms content is the W3C XForms standard. This standard has only been recently published as a "recommended" specification, and adoption is in the early stages. XForms defines a "model" of an e-form, that can be bound to many different presentation options.
The principal advantage of defining a separate content layer is just this - the content can be repurposed to different presentation options for different scenarios. For example, one XForms e-form content model could be transformed into HTML web pages for a pure web-based approach, SVG pages for use in an E-Forms User Agent in a typograhically rich and precise electronic approach, or SVG pages for use in producing paper forms. The content would be reused across these presentation options.
Separating content from presentation also facilitates accessibility, and is a primary recommendation from the W3C Web Accessibility Initiative (WAI): "Both [information/substance] and structure are separable from presentation".
The principal advantage of merging content and presentation is that it simplifies the meta-data, and allows for maximum presentation flexibility. It also makes the binding between content and presentation physical and permanent, which may be perceived to have some benefits for legal and archival requirements (more on this in Section 6.7).
These trade-offs are pretty mixed, and there are ways for each approach to mitigage its weaknesses, and incorporate the strengths of the other.
For more information, see:
E-Forms within the federal government are required to be Section 508 compliant, which means e-forms must accessible to people with disabilities. Inaccessible technology interferes with an individual's ability to obtain and use information quickly and easily. It is critical that e-forms are accessible.
Accessibility compliance guidlines are published in the W3C Web Accessibility Initiative (WAI) standards and the Amercian Foundation of the Blind.
For more information, see:
Different e-forms have different security requirements, but the security issues are complex. There are a host of security related standards.
The E-Forms security sub-team has written recommendations paper on this topic, and they address these key areas in detail: authentication and credentials; signature; authorization and access control; session integrity; audit; and archive. This paper is available at:
http://www.fenestra.com/eforms/deliverables/security_recommendations.doc
For more information, see:
The archival records domain and the security domain intersect, because both are concerned with ensuring the integrity and authenticity of the e-forms record. The security recommendations paper covers the archival issues.
Briefly, the National Archives and Records Administration (NARA) guidlines require that the "presentation", "content", and "context" must be bound together in such a way that they can be demonstrated to belong to the same transaction. This may mean physically combining these into a single physical file, or ensuring that they are bound together through some other trusted means, such as electronic hashes and signatures. In addition, any signature must be applied to this combination of presentation, content, and context, and the authentication process must ensure integrity.
For most government applications, E-Forms solutions must be designed and selected with these core archival requirements in mind.
For more information, see:
E-Forms often participate in workflow, which involves a service-based architecture. In addition, the various nominal e-forms components described in Section 5.0 could be integrated together using a service-based architecture.
Web services provide the framework for implementing these service-based architecutures. Just as there is no standardized component stack for e-forms, there is no standardized set of services. However, using web services for standard e-forms activities such as submitting response datasets to a form submission server, obtaining new e-forms from a catalog, routing an e-form for a signature through a workflow engine, etc., are perfect candidates for web services.
Web services can also be used to provide behavior in e-forms themselves. For example, a computationally intensive lookup or validation might better be performed on a web server instead of within a client, and the e-form could use a published web service to execute the behavior on the server.
The advantage to using web services is they promote a distributed service-oriented component-based architecture.
There is a standard Web Services stack of standards, including description, workflow, service registration and discovery, security, routing, non-repudiation, etc.
For more information, see:
Here are the recommendations of the E-Forms for E-Gov pilot:
Meta-data driven e-forms provide an opportunity to reorganize the government's data collection activities along the FEA lines of business to accomplish important E-Government goals - eliminating redundancy, promoting data sharing, and reducing reporting burden.
This final report is currently in draft stage, when it is approved by the E-Form for E-Gov pilot team, it will be submitted to its parent, the XML Web Services Working Group, and the AIC Components Subcomittee of the CIO Council. Continuing work on these efforts will originate from the CIO Council.
Accessibility
Business Case
Client Specifications
Fixed Content & Behavior
Form Selection
Presentation
Records-Keeping
Schema
Security
Services