|
Français | Contact Us | Help | Search | Canada Site | ||||
| What's New | About Us | Policies | Documents | TBS Site |
| Calendar | Links | FAQs | Presentations | Home | ||||||
|
|
|
 |
Prepared For: Prepared By: Reviewed by EDSWG: November 15, 1996 Table of ContentsExecutive Summary 1 Appendix A: Electronic Form DTD 37 Appendix B: Service Agreement 41 Appendix C: Request for Translation 49 Appendix D: PARTICIPANTS - Electronic Forms Interface Standardization Pilot Project 61 Executive SummaryThis project is part of an on-going effort of the Government Standards program to define and to promote a standards-based electronic document environment that fulfills government policies on information technology and information management. The objective of the project was to define and test an interface standard to exchange electronic form data between different vendors' electronic form applications. Since there are currently many vendor's electronic form applications installed in the Federal Government, it becomes necessary to interchange data between them in order to continue development within an "open systems" architecture. This will avoid the creation of proprietary "islands of automation" as well as minimize the Government's reliance on any single electronic forms vendor. As outlined in this report, the project team successfully designed and tested a standards-based interface to exchange electronic form data between different vendor's applications. This pilot report examines 5 distinct issues:
Each of these issues is discussed at some length within this report. At the end of the report, there are conclusions that have been drawn from the work performed during this project as well as a Recommendations for Implementation section. The Recommendations section lists the recommendations of the Electronic Document Standards Working Group that should be acted upon by the Government to continue the move towards a standards-based electronic forms environment throughout the Government. 1. BackgroundThis report has been developed by InfoDesign Corporation for the Treasury Board Secretariat. It reviews the objectives, results and recommendations of a pilot project to standardize the interchange of electronic forms information (subsequently referred to in this report as the E-Forms Interface Pilot) which was undertaken by the project participants in conjunction with The Electronic Document Standards Working Group. The E-Forms Interface Pilot represents a follow-on project to an E-Forms Prototype implementation which demonstrated that:
The E-Forms Interface Pilot brought together government and industry participants representing several Federal Government departments, Government Technology Information Services (GTIS), SGML specialists and electronic forms software vendors (see appendix D for a list of participants). This project team undertook the interface pilot in order to:
2. DefinitionsCommon Gateway Interface (CGI) - the standard interface for WWW (World Wide Web) servers to invoke programs to perform a given function. Data type - the type of information that can be entered into a field on a form (e.g. date, number, characters, etc.). Digital signatures - a method of identifying and validating that a document was "signed" by a given person. This capability is typically implemented through encryption algorithms. Document type - a set or "class" of documents which have common structures and content. Books, statutes, technical manuals, journals, articles, etc. represent unique document types because they exhibit characteristics that are unique to each of them. DTD - Document Type Definition. The component of an SGML application that identifies the rules that specify the structure and contents of documents that belong to a given "document type" or class. This rules file identifies the valid elements and attributes that can or must be included in a document of this "type". It also includes information about the order and nesting of these elements. DSSSL - Document Style and Semantic Specification Language. An optional component of an SGML application which defines a vendor and application independent method of formatting and processing SGML documents. In it's simplest form a DSSSL specification is similar to a stylesheet used for common wordprocessing applications such as MS Word and Corel Wordperfect. DSSSL-Lite - A subset of the DSSSL specification which defines vendor independent stylesheet information for the on-line viewing and printing of SGML documents. E-form designer (application) - a forms designer application allows a user to draw a form on a computer screen and to define each of the fields that appear on that form. The form definition includes a list of applicable fields along with their associated definitions and field attributes such as; information masking instructions, security constraints, data type specifications, fixed or maximum field length limits, etc. The display characteristics, which control the overall appearance of the form, are contained in a style sheet component. This component includes attributes that specify; the "background" colour of the form, placement of horizontal and vertical lines, box sizes and styles, field titles, shading, font styles and sizes, etc. Encryption - A method of coding a document such that it can only be read by users or programs that have the appropriate decryption (de-coding) key. HTML - HyperText Markup Language - The document markup language for the WWW. HTML is an application of SGML that defines a set of tags which WWW browsers such as Mosaic and Netscape can format. It also includes a universal linking mechanism to hyperlink from a position in one document to a position within the same document or to a document on a remote WWW server. Form data - the actual content of an electronic form typically entered through an e-form filler application. E-form filler (application) - a forms filler application allows a user to enter the information (form data) for a given form. The forms filler application uses the definitions created by the E-form designer application to display and format the appropriate input fields on screen. It, additionally, performs such functions as security, data integrity, etc. on each field being input. Generic DTD - a document type definition which does not use content specific element or attribute names. In terms of electronic forms, a generic DTD defines the set of generic elements and attributes which can be used to express the names and definitions of input fields for all electronic forms. Specifically, it defines a single element called "input" which has a set of user-definable attributes associated with it which define the name of the input field as well as attributes such as size, masking information, security, data type, etc. The "user" in this case is the forms designer. Instance (electronic form) - an instance of an electronic form is a document containing the actual fielded data input by the user of the e-forms filler application. It is normally used in the context of "an instance of", meaning that the instance (document) conforms to a given Document Type Definition (DTD). Instance (template) - as recommended in this document, all electronic forms are defined by a single, generic DTD. Specific electronic forms, such as the "Request for Translation Form" and the "Specific Service Agreement" would then be defined using "templates" conforming to the generic DTD. These templates (or "blank" forms) are actually instances of the generic DTD and define all of the input fields (such as Originator Name, Branch Code, Postal Code, etc.) used on the specific electronic form along with the definition of the fields such as name of the field, size, masking information, security, data type, etc. See section 0 Single E-form DTD vs. DTD per E-form for an explanation of the difference between a "template" of a single, generic e-form DTD and a content-specific DTD for each form type. MIME type - MIME is a standard encoding scheme, popularized by the Internet, for attachments to e-mail messages. The MIME type is a field in the e-mail message that identifies the type (eg. MS Word, Excel, Wordperfect, etc.) of document that is encoded and attached. Many e-mail systems key on the MIME type to decode the document and invoke the appropriate application to view the document. MIME types are registered and published by a central standards authority. Plug-in applications - an application that gets invoked by the Web browser when a received data stream is not HTML or is not processable by the browser. The header of the data stream identifies what type of data is enclosed. Based on the type of data being received, the browser will invoke the appropriate plug-in application on the client computer. Processing instructions - special markup allowable in SGML documents. Processing instructions are embedded in documents to direct the computer to perform special functions. When processing the document, processing instructions, such as cursor-location, etc., are not typically considered part of the user entered information. SGML (ISO 8879) - Standard Generalized Markup Language. Approved by ISO (International Standards Organization) in 1986, this international standard defines a language and syntax through which document types can be defined. In it's simplest form, it allows a tag set to be defined and validated for a given document type (see DTD). In the context of electronic forms, SGML can be used to define the rules and syntax of electronic form definitions, templates and instances to be exchanged between applications and users. SGMLOpen - a consortium consisting mostly of software vendors whose purpose is to develop, maintain and promote adherence to implementation guidelines for SGML-aware software products. SGMLOpen also promotes SGML to business organizations in general. SGML Application - a DTD or set of DTDs with guidelines detailing how the DTDs are applied for a given document class. For example, HTML is an SGML Application, as is CALS (a military electronic interchange initiative) and J2008 (for automotive technical documentation) among many others. To this end, the SGML DTD(s) and set of guidelines defining electronic forms interchange is considered an SGML Application. Style sheet - a style sheet is typically a formatting specification that is defined by an e-form designer application. The style sheet defines the layout or the "blank" version of a form in which specific field contents will appear when a form is displayed or printed. It includes details such as the width and colour of horizontal and vertical lines, boxes, wording, shading, etc. which surround the contents of individual fields. Style sheet interchange - the method of exchanging formatting and style information for the display and printing of electronic forms. All electronic form applications currently employ their own proprietary style sheet definition files. In order to interchange this style sheet information, it is necessary to use a vendor-independent, agreed-to language and syntax which can be used to define and interchange this information, for example, DSSSL. Template - a template is essentially a blank form which defines all of the input fields for a specific form. This template is then used for accepting and validating data which is input by users. World Wide Web Committee (W3C) - an international committee whose mandate is to define the standards for use on the World Wide Web (WWW). In addition to other standards, the W3C defines and maintains HTML (HyperText Markup Language). 3. The OpportunityElectronic Forms are becoming more and more prevalent in the Canadian Government. Each department is implementing electronic form solutions to meet their requirements and these solutions are being used on a day to day basis by thousands of employees throughout the Public Service. To date, electronic form applications have provided a good return on investment within the departments themselves by reducing paper-based forms usage and eliminating the inherent inefficiencies of paper-based handling and distribution (a savings of approximately $35.00 per electronic form instance, according to industry estimates). The use of electronic forms is expected to continue its exponential growth for the next several years as the Government of Canada strives to work smarter, streamline it's information flows and do more with less. Among the thousands of forms being used throughout the Government today, only 10%-20% are available electronically and these implementations are confined to selected departmental initiatives that have chosen to implement specific vendor electronic forms software packages. There is an opportunity for Government to: · reduce the number of forms by rationalizing the data which is being collected and by eliminating redundant forms; · make the forms available electronically in order to reduce the paper burden and to improve the overall speed and efficiency of forms filling, routing and management; · ensure the effective, secure interchange, processing and archiving of the forms-based information that is generated by electronic commerce and administrative transactions conducted by the Federal Government and the private sector. 4. The ChallengesWhereas a number of independent initiatives are currently underway within Government to reduce the paper burden and to facilitate electronic commerce in general, this report is concerned only with the more restricted objective of illustrating the potential for Government to ensure effective and secure interchange, processing and archiving of forms-based information. To achieve this objective, several technical hurdles must be addressed and overcome. Namely, the forms-based information must be:
Most of these hurdles don't exist, or are minimized, in homogeneous networks that use the same version of a specific e-form application. Many of today's e-form application vendors provide secure interchange and consistent processing between networked installations of their own products using proprietary means. However, in a large enterprise such as the Federal Government, it is not possible (nor necessarily advantageous) to implement only one e-form application across the entire enterprise and the private sectors that conduct electronic transactions with the Federal Government. Even if implementation of only one application package was feasible, archiving would remain a problem since future releases of a vendor's software may not, necessarily, be able to process data created using earlier versions of that software. Therefore, until the above challenges are overcome, the Government will not be able to effectively and securely interchange e-form data within and across departments or with the commercial sector and, thereby, will not maximize the opportunity of reducing paper and streamlining it's information flows. In addition, to overcoming the technical hurdles, the government would need to facilitate implementation of standard e-forms interfaces through proactive support services as outlined in Section 8. 5. Standard Definition of E-Forms Structure & Content 5.1 E-Form Software ApplicationsTypical E-Form applications consist of two separate, yet related, software components: the Forms Designer and the Forms Filler. The Forms Designer is used to design the layout (or "template") of the form. The Forms Filler application is used by end-users to enter the information (i.e. "fill out") into the form. Creating templates for forms requires specialized applications to make the job easy for forms managers and to assist them in making the definitions consistent and meaningful for forms users. A Forms Designer allows a forms manager to draw the form on screen and to define each of the fields that apply to that form. Traditionally, these types of applications generate a proprietary (i.e. vendor-specific) form definition and style sheet. The form definition includes a list of fields used in the form along with their definitions and associated attributes which specify such details as: masking information, security, data type, field length, etc. The style sheet defines the "background" of the form, for example there may be horizontal and vertical lines, boxes, field labels and user instructions, shading, etc. A Forms Filler allows a user to view the form on screen and enter information into the fields of the form. By reading the form definition and style sheet provided by the Forms Designer application, the Forms Filler is able to not only display the form and accept information, but also perform real-time validation and calculations on the information that is entered by the user. For example, if the field is specified as a "date" field, the e-forms filler will only allow a proper date to be entered. After the user is finished entering the information into the fields on the form, the information may either be stored as a file (traditionally in the proprietary format) or as a proprietary schema in a standard database management system. There are four (4) major pieces of information that an e-forms filler application needs in order to present and process an electronic form:
In the above list, the processing information is listed as a single item. Actually, the processing information consists of data definition information (e.g. data validation rules, field definitions and code values, etc.) and data presentation information (e.g. display areas and icons, font styles and sizes, etc.). The latter is typically stored as some type of style sheet while the former is retained as part of the template. To achieve the primary objective of the E-forms Interface Pilot, the proposed interface solution must support the interchange of form instances and the forms data definition information that is generated by traditional forms filler and forms designer software. How this information can be interchanged is described in the following sections. It is also necessary to exchange the data presentation information between applications in order to realize a truly "open" environment where e-forms can be defined once and then used in all e-forms filler applications. This issue is discussed in section 0 Proposed Interchange Strategy. 5.1 Single E-form DTD vs. DTD per E-formWhen applying SGML techniques to support the interchange of form instances and data definitions, there are two strategies which can be followed:
As illustrated below, in the first option all instances for all e-forms conform to a single DTD.
Figure 1: Single, Generic E-Form DTD The DTD uses constructs (i.e. SGML elements) such as "input" to define an e-form. An "input" element corresponds to a field on the form. The "input" element has attributes associated with it that define such things as field name, size, type, masking information, security, etc. So a template for a specific form may look something like this: ... <input name=today.date type=date size=8 mask="yy/mm/dd"></input> <input name=first.name type=char size="1"0></input> <input name=last.name type=char size="1"5></input> ... While the instance of the e-form may look something like this: ... <input name=today.date type=date size=8 mask="yy/mm/dd">96/03/31</input> <input name=first.name type=char size="1"0>Samual</input> <input name=last.name type=char size="1"5>Jones</input> As illustrated in the above examples, the element name is always "input", the attributes define the characteristic of each field and the contents of the element is the contents of the field input by the user of the e-form filler application. A similar concept would be used for more complicated field structures such as groupings, check boxes and radio buttons. In this scenario, the DTD defines the rules by which all e-forms can be described. The major advantages to this scenario are:
In the second option, SGML instances conform to the DTD which defines the individual form.
Figure 2: DTD per E-Form In this case, each e-form may use different elements to define the fields on the form. For instance, the element named "first.name" may be defined for the field whose contents is the user's first name. Similarly the element named "last.name" may be defined for the field whose contents is the user's last name. Using the same example as described in option 1, a template may look something like: ... <today.date type=date size=8 mask="yy/mm/dd"></input> <first.name type=char size="1"0></input> <last.name type=char size="1"5></input> ... While the instance of the e-form may look something like this: ... <today.date type=date size=8 mask="yy/mm/dd">96/03/31</input> <first.name type=char size="1"0>Samual</input> <last.name type=char size="1"5>Jones</input> ... The general structure is similar to the previous example, except that the element name is different for each field in this case. However, it is important to note that there are two major disadvantages to this scenario:
While implementing the interface pilot, it was seen that most of the existing e-form applications were designed as proprietary versions of a generic e-form DTD that was supplemented by a unique template for each e-form (i.e. equivalent to option 1 above) In other words, the respective e-forms vendors have devised their own rules (whether hard coded in the application or stored in configuration files) for defining electronic forms and then applied these rules to create form templates that are all stored in the same format (essentially instances of the rules). For example, a form template is typically implemented as a list of fields, each with a corresponding set of attributes such as: field name, security, masking codes, validation routines, help text, etc. To support standardized definition of the structure and content of electronic forms, an earlier investigation on the role of SGML in an electronic forms environment had recommended that each form have its own DTD. This recommendation was revisited by the interface standardization pilot which determined that the DTD per E-form approach (while workable) was not an easy solution to implement. Consequently, it could inhibit acceptance and implementation of a standards-based solution by the vendor community and would complicate the management and implementation of standardized e-forms by the user community. For these reasons, the pilot participants concluded that the alternative (i.e. a single, generic DTD approach) should be the recommended option. 5.3 SGML vs. HTMLThere has been some discussion within the IT community on the relative merits of using HTML instead of SGML for the definition of electronic forms to support intersystem interchange. Since HTML is a specific application of SGML, this debate is more accurately described as HTML markup versus a newly defined guideline for applying SGML markup in electronic forms. As described in the previous section, e-forms can be defined using SGML with either a generic DTD or a separate DTD for each e-form. HTML version 3.2 specifies a generic e-form DTD that is actually quite similar to the generic DTD approach proposed in this report. The following sections of this report describe how HTML forms are currently used, why they are currently insufficient for business e-forms and how HTML may be extended to provide the necessary capabilities. 6. Forms Design and ProcessingThis section places the discussion of generic electronic forms facilities, described in section 5.1, within an Internet context. It provides a context for the forms processing facilities which are currently provided in HTML and a basis for identifying the capabilities that will be provided by Java-enhanced forms in the near term. In summary, this section provides a context which re-enforces the recommended forward strategy for e-forms standardization and processing provided by the overall report. 6.1 Current HTML-Based Forms Processing6.1.1 CGI ProcessingHTML forms have been designed for the sole purpose of prompting and accepting fielded data from a client Web browser and processing it with a server-based software program invoked through a CGI (Common Gateway Interface). This processing configuration is illustrated in Figure 3 below. The actual e-form data input by a user through a Web browser is almost never stored in an HTML instance. HTML is merely used to create the display and cause the Web browser to prompt and accept the information. The data typically flows directly to the CGI program which immediately processes it and then either stores it in a database or discards it.
Figure 3: Current HTML Forms ProcessingIn the above scenario, the user located at the browser site is prompted for specific pieces of information following successful log-on to the HTTP server at a local or remote site. The actual prompts are by the HTML form residing in a database linked to the HTTP server. The data input by the user in processed by the CGI application software which validates that the user-supplied data corresponds to the constraints specified for individual fields defined by the HTML form. Even if the data was to be stored and interchanged as an HTML document, the current HTML standard (HTML v3.2) is inadequate for processing business e-forms that need to be interchanged in typical business transactions. For example, HTML 3.2 does not support common e-form functions like data type verification, field value validation, calculated values, masks, etc. and must rely on custom developed CGI scripts to provide these capabilities. This additional functionality is a standard requirement for business e-forms and vital to the display and processing of forms data. It should not be left to CGI programs (which are custom developed on every server) to process. 6.1.2 Plug-in ApplicationsSome Web browsers allow Plug-in Applications to be attached. Plug-in applications are applications that get invoked by the Web browser when a data stream is received that is neither HTML nor processable by the browser. The header of the data stream identifies what type of data is enclosed. Based on the type of data being received, the browser will invoke the appropriate plug-in application on the client computer.
Figure 4: Plug-in ApplicationsThis is the technique currently employed by at least one electronic forms vendor to process electronic forms across the WWW. Unfortunately, the current implementation uses the vendor's proprietary data types and therefore the data cannot be processed by other e-form vendor applications. This limitation could be circumvented by standardizing the electronic form data types and thereby allowing multiple vendors' applications to interchange the forms data. 6.2 Future HTML Forms Processing (Java)Work is continuing at a rapid pace to enhance WWW applications. Electronic forms processing is but one area which will be undergoing tremendous change over the next year or two. The enormous interest in Java and JavaScript is having a profound effect on how electronic forms applications will look in the near future. Java is a programming language that allows true platform-independent application development. It was developed by Sun Microsystems and has been submitted to the appropriate bodies for approval as an international standard. Java allows a developer to create an application (called an "applet") which can be downloaded from any node to any node in the network. This application can then be loaded dynamically and executed immediately.
Figure 5: Java "Applets"With respect to Forms Filler applications, it is highly likely that Forms Filler applications will become "applets", written in Java or JavaScript. They would be dynamically downloaded to the user's workstation whenever an HTML document, processed by a Web browser application, contained electronic form markup. JavaScript is a scripting language that allows dynamic behaviors to be specified completely within an HTML document. It is derived from Java but is considerably simpler to program. This means that HTML documents could incorporate dynamic behaviour (e.g. validate field values) within the Web browser application which could be implemented on the client computer without the use of Java applets or server CGIs (Common Gateway Interfaces). As an indication of what lies ahead, Netscape released a strategy document entitled "The Internet Application Framework: A White Paper" which includes the following example to illustrate the power of JavaScript. A simple, but enormously useful capability illustrates the power of JavaScript. In the past, the processing of an HTML form has required the user to fill out various elements of the form, then click on a "Submit" button. This causes the filled-out form to be transported to a server for processing by a CGI script. User feedback awaits a round-trip over the network, which can take several seconds. Further, the results appear in a new document, not the one containing the original form. JavaScript, on the other hand, extends the HTML form by adding an event model of the kind found in most GUIs. It enables the various elements of a form to be associated with events, which can be triggered immediately when the user carries out keyboard or mouse actions within the form. The events cause invocation of JavaScript functions, which have been declared in the document's headers. This permits immediate feedback to the user, which can range from simple error checking to complete computations whose results are displayed on the original form. The user sees immediate feedback and, since processing of JavaScript is done on the client, the need for a network round-trip and the invocation of a separate CGI program at the server is completely eliminated. While this example uses electronic forms to show the power of JavaScript, it is certainly not expected that JavaScript will replace the need for true Electronic Business Forms applications (or "applets" as described above). Although, undoubtedly, some HTML authors will use JavaScript to generate Electronic Form application functionality, large numbers of custom JavaScript e-form applications would become unmanageable because each form would use potentially different processing rules unless the rules are carefully controlled. It appears safe to assume that JavaScript will be most useful for receiving and validating data input for custom applications. Given this paradigm of Java and JavaScript applications, it appears that Java "applets" would provide the best application mode for presenting and processing electronic forms across the WWW. 7. Data Interchange RequirementsForms may be interchanged using any number of methods. For example, they may be interchanged:
Today, the most common interchange method is e-mail. Most e-forms filler applications have proprietary methods for interchanging forms between users via e-mail. Typically, the interchange is initiated by sending the form instance as an e-mail message (or alternatively as an attachment that is embedded in the message). At the recipient end, the message is handed over to an e-forms filler application that has been integrated with the local e-mail system, such as cc-mail, etc. Typically, the messaging process automatically invokes the e-form filler when it encounters a specific header string in an incoming message. In moving the form data out of the control of a single application or even a single computing environment, it becomes increasingly necessary to interchange other kinds of information such as style sheets as well as the form definition and form data. In addition to supporting e-form data interchange, the forms filler application needs to support digital signatures and encryption to ensure the integrity and confidentiality of each interchange. These topics are discussed further in section 0 Encryption and Digital Signatures. 7.1 Pilot Messaging EnvironmentThe pilot project defined a standard header string that would be recognized by the respective e-mail systems in order to invoke each of the vendors' e-form applications. Although this proved to be a workable solution, a more generic alternative, that would be easier to implement across e-mail applications, would be to register a standard MIME type to facilitate electronic forms interchange. This Mime-type would be an integral part of the standard e-form DTD described in this report. A similar kind of extension could be provided for X.400-based messaging environments to ensure message standard independence.
Figure 6: Interface Pilot Messaging Environment 7.2 Proposed Interchange StrategyThe WWW has been very successful in developing and implementing standards that are non-proprietary as well as platform-independent. It has opened the doors for people to communicate and interchange data using all kinds of computing environments ranging from the simplest character terminals to the most advanced computers. It has also allowed handicapped people to interact with the WWW using Braille, large type, and voice recognition. Within this environment any HTML-encoded document can be read and displayed, as necessary, by any browser used by the recipient. It is this type of interchange environment that the electronic forms community needs to move towards. With the recognized need to interchange electronic forms, comes the corresponding need to ensure cross-platform interchange as well as to tailor the forms processing and display to users with special needs. The WWW functionality can be exploited by transmitting forms data as a single data file and enabling the forms filler applications to execute a user selected style sheet to control the display. The WWW community is quickly moving toward the use of linked style sheets to allow users to select the display features of the information instead of leaving it to the Web browser to define how the styles should be applied. An investigation needs to be undertaken to test existing style sheet definition methods, such as DSSSL or DSSSL Lite, to assess the ability of these standards to support the interchange of styles for business form applications. 7.3 Standards-Based Forms ProcessingExisting e-form designer applications will need to be modified to generate output, using the standard DTD for forms definition and style sheet specification, in order to interface with other vendor's e-forms filler applications. Once this generic DTD is implemented, e-forms filler applications will no longer need custom e-form designer applications. This means that an e-forms filler application would be able to import a form definition and form style sheet which was created by another vendor's e-form designer that complied with the generic DTD defined in Appendix A. In the WWW realm, this e-form designer and e-form filler interoperability is analogous to the shared ability of HTML authoring tools and browsing applications to process documents. Thus an author that creates an HTML document using any HTML authoring tool virtually ensures that any browser will be able to read and interpret that document correctly. Similar integration of the generic DTD and associated templates with existing e-forms designer applications would allow forms managers to define new templates that would enable users to display or create the form contents using any HTML browser or e-forms filler application. It is this ability to design a form on any e-forms designer application independent of the requirement of the e-forms filler application that is the fundamental feature of standards-based forms processing. 7.4 Proposed Generic DTD and Associated Templates The proposed DTD, which appears as Appendix A in this report, has been written with business forms interchange and HTML in mind. By standardizing the electronic form data types, the DTD enables multiple vendors' applications to interchange and process the forms data in a consistent and meaningful fashion. This data type information could be defined either external to the HTML markup or included in an enhanced HTML markup language. The preferred approach, that is advocated in this report is to develop an SGML data format that is external to HTML but that would be submitted to W3C for potential inclusion into the HTML standard as well. It is envisaged that the generic DTD and associated templates will fulfill a two-fold purpose in that they:
By defining the DTD as a subset of the HTML DTD, users are provided with a more versatile and easily implementable approach for electronic form processing and interchange. 8. Centralized ServicesThere are many issues to be considered, with regard to ensuring consistency of e-forms and in assisting users to obtain the correct form, before embarking on a large implementation of standards based electronic forms. The key issues to be resolved are concerned with the best means of ensuring that users will:
To resolve these issues, we need to look at both technology and management solutions since it is generally recognized that technology solutions are only as good as the management support for those solutions. 8.1 DTD Registry/RepositoryIn an organization as large as the Federal Government, it will be absolutely essential that a centralized registry/repository be established to manage all approved, interdepartmental electronic form definitions. The electronic forms being used in the Government are too mission critical to allow form definitions to be created on an as needed basis by each department. A proactive approach to e-form design is necessary to avoid duplication and inefficiencies that result from incompatible forms definitions which compromise automated processing of the interchanged forms data across departments and industrial sectors. This does not mean that a large centralized service is necessary to create, update and distribute all electronic forms. Rather, the service needs to be a registry service which identifies the forms that are in existence, validates their definitions and styles, maintains an up-to-date record of available forms and associated style sheets and ensures that the required information is available to everyone that needs it. The CGSB (Canadian General Standards Board) has been tasked by Treasury Board with the responsibility for standardization of government-wide forms. This responsibility includes all aspects of forms standardization including print, and electronic media. It is recognized that the contributions of various stakeholders, technologies and skills will be required in implementing technologies such as SGML forms and a DTD registry repository as proposed in this report, that this effort represents a significant investment, and that senior-level government support and collaboration with other related groups will be essential to the success of this initiative. 8.2 Encryption and Digital SignaturesWhen a user receives an electronic form, it is essential that the transmitted information remains confidential and untampered. In other words, the data interchanged between the sender and receiver must be protected to ensure that what the sender sent is what the receiver received. The following five security requirements are crucial for electronic forms interchange and user acceptance of electronic transactions:
Encryption addresses the confidentiality and access control requirements, while digital signature addresses the integrity, authentication and non-repudiation requirements. A digital signature is an application of public key cryptography that identifies exactly who "signed" the document while possibly locking specific fields from further modification. Cryptography can be categorized as either secret key cryptography or public key cryptography. Secret key cryptography uses a single cryptographic key shared by two communicating parties. For secret key cryptography to be effective, the key must be kept secret and controlled by the parties that have access to the key. A major advancement in cryptography was the invention of public-key cryptography. Public-key cryptography makes use of two keys: a public key and a private key. The two keys are mathematically related, but the private key cannot be determined from the public key. Each party has its own public/private key pair. The public key can be known by anyone; however, no one should be able to modify it. The private key is kept secret. Its use must be controlled by its owner and it should be protected against modification as well as disclosure. The major advantage of public-key cryptography is that it removes the need to use the same key for encryption and decryption. Essentially, the transmission is encrypted using the recipient's public key. The receiver then uses the private key to decrypt the message and the sender's public key to authenticate the message. The Canadian Government is currently implementing a public key infrastructure which is based on the Entrust application for encryption and digital signatures. Entrust is a commercial product developed by Northern Telecom which, according to published reports, adheres to the following standards (among others):
The strategy outlined in this report for the interchange of electronic form data should not affect the implementation of Entrust, nor any other product conforming to these standards. Further investigation is necessary to determine exactly how specific fields or blocks of fields within an electronic form can be locked by an application of a digital signature. 8.3 ArchivingArchiving of electronic form instances represents an essential component of the forms life-cycle management and sound business practice. It is also a government policy for the management of government information holdings and the retention of essential public records. However, in certain electronic form environments, such as database-stored e-form instances and current HTML implementations, there is no means of saving the data as single objects or as aggregate files that can be stored separately from the forms application for archival purposes. Some of the key aspects of successful electronic forms archiving are concerned with:
Using SGML for the interchange of electronic forms has a profound effect on the ability to archive and retrieve legacy electronic forms data. First of all, the same SGML data model used to interchange the data can be used to archive it. This capability provides a standard representation of the entire electronic form regardless of how the data is actually stored by the originating application. Secondly, since the archived data is not vendor proprietary, any document management application can be used to view it. This characteristic eliminates the danger of having archived data and no application to process it whenever a vendor stops supporting the required software package, or the user fails to archive the originating application (and computing environment) with the data. 9. Project DeliverablesSpecific deliverables developed during this project by the project team included the following:
successful interchange of the form data between two vendors' products (i.e. Jetform's Form Filler and Craig Technologies' Novell Informs) via e-mail across Federal departments using different e-mail applications (e-mail interfaces to departmental e-mail systems were interconnected via the GTIS X.400 gateway);
10. The ConclusionsThis proof of concept project has worked out to be very useful in many respects. The major conclusions drawn by the pilot project are as follows: It is possible to import/export SGML using form filler applications;
11. Recommendations for ImplementationThe Canadian Government needs to move swiftly to a standards-based approach for the description and interchange of electronic forms data. As the number of Federal employees using electronic forms increases, so to will the trail of proprietary form templates and instances. This aggregate growth of incompatible applications and data will continue to frustrate employee efforts to interchange, manage and archive and resulting information generated by these proprietary forms applications. By moving to standards-based electronic forms, the Government can become more efficient, effective and responsive without sacrificing any of the functionality currently provided by the installed electronic form applications or the vendors' potential for innovation. Having reviewed and considered the E-Forms Interface Pilot objectives, results and conclusions, the Electronic Document Standards Working Group recommends that the Government expeditiously advance the implementation of standards-based electronic forms by taking the following steps:
Appendix A: Electronic Form DTD <!DOCTYPE eform [ <!-- **********************************************************************/ /* */ /* File: eform.dtd */ /*Created By: Larry Osipenko larry@idc.com */ /* InfoDesign Corporation */ /* Owner: Government of Canada */ /* Function: Document Type Definition for Electronic Forms */ /* */ /* Comment: This DTD was created as part of the E-forms SGML test project */ /* It is currently in early prototype form and is subject */ /* to many, drastic changes. */ /* */ /* The intent of this DTD is to allow standalone interchange */ /* between e-form applications and to provide an initial idea */ /* for a DTD fragment that could be used in HTML for electronic */ /* forms. */ /* */ /* All input capable fields have been collapsed into one element */ /* definition, other than tables and images. This includes */ /* multi-select and multi-line. */ /* This considerably simplifies the DTD. However, as a later */ /* exercise it may make sense to make each input type a separate */ /* element to better define the attributes for each input type. */ /* */ /* It is expected that "presentation" information will somehow */ /* accompany the information contained in an instance of this */ /* DTD. This presentation information may be in the form of */ /* a DSSSL or DSSSL Lite style sheet, or to-be-developed */ /* presentation model specifically designed for e-forms */ /* (depricated), or in the form of an HTML document surround */ /* this e-form. Further work is need to define how presentation */ /* information is attached and processed in conjuntion with */ /* an instance of this DTD. */ /* */ /* This DTD has not been tested and should undergo review and */ /* testing by an e-form DTD development committee before */ /* being used. */ /* */ /* */ /* Public Identifier: */ /* The doctype declaration for each instance of this DTD should */ /* be as follows: */ /************************************************************************* */ <!Doctype eform PUBLIC "-//CDN-GOV//DTD E-FORM//EN" [ ]> /****************************************************************************/ /* */ /* History: */ /* */ /* V1.0 */ /* Date:March 31, 1996 */ /* Created By:Larry Osipenko */ /* InfoDesign Corporation */ /* larry@idc.com */ /* Under contract with the Canadian Federal Government */ /* */ /* */ /************************************************************************--> <!--================ Character mnemonic entities ======================--> <!ENTITY % ISOLAT1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN"> %ISOLAT1; <!ENTITY % ISONUM PUBLIC "ISO 8879:1986//ENTITIES Numeric and Special Graphic//EN"> %ISONUM; <!ENTITY % ISOPUB PUBLIC "ISO 8879:1986//ENTITIES Publishing//EN"> %ISOPUB; <!ENTITY % ISOTECH PUBLIC "ISO 8879:1986//ENTITIES General Technical//EN"> %ISOTECH; <!ENTITY % ISOAMS PUBLIC "ISO 8879:1986//ENTITIES Added Math Symbols: Arrow Relations//EN"> <!ENTITY % ISOGRK3 PUBLIC "ISO 8879:1986//ENTITIES Greek Symbols//EN"> %ISOGRK3; <!ENTITY % FORM.Version "1.0"> <!ENTITY % version.attr "VERSION CDATA #FIXED '%FORM.Version;'"> <!ENTITY % URL "CDATA" -- The term URL means a CDATA attribute whose value is a Uniform Resource Locator, See RFC1808 (June 95) and RFC1738 (Dec 94). --> <!--=================== Text Markup =======================================--> <!ENTITY % font "TT | I | B | STRIKE | BIG | SMALL | SUB | SUP"> <!ENTITY % phrase "EM | STRONG | DFN | CODE | SAMP | KBD | VAR | CITE"> <!ENTITY % text "#PCDATA | %phrase | %font | IMG"> <!ELEMENT (%font|%phrase) - - (%text)*> <!--================ Forms ===============================================--> <!ENTITY % form.content "(INPUT | IMG | TABLE)"> <!ELEMENT EFORM - - %form.content> <!ATTLIST EFORM %version.attr name CDATA #REQUIRED -- identifies the name of the e-form template, to be filled in at template creation time-- templver CDATA #REQUIRED -- version of e-form template -- > <!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX | RADIO | BUTTON | HIDDEN | IMAGE | SIGNATURE)"> <!ELEMENT INPUT - O (%text)*> <!ATTLIST INPUT type %InputType TEXT -- what kind of widget is needed -- name CDATA #REQUIRED -- required for all but submit and reset -- group CDATA #IMPLIED -- name of the group that the field is in -- checked (checked) #IMPLIED -- for radio buttons and check boxes -- size CDATA #IMPLIED -- specific to each type of field -- rows NUMBER #IMPLIED -- number of input rows -- maxlength NUMBER #IMPLIED cols NUMBER #IMPLIED -- number of input columns -- default CDATA #IMPLIED-- default value to be displayed -- label CDATA #IMPLIED -- label to be used for field -- selection CDATA #IMPLIED -- list of possible values for entry, this could be displayed like a selection list-- align (top|middle|bottom|left|right) top -- image alignment -- nextfield CDATA #IMPLIED -- next field where cursor should go after processing this field-- help CDATA #IMPLIED -- help text -- mandatory (mandatory | optional) optional -- mandatory data entry?-- picture CDATA #IMPLIED -- mask to be applied to data eg. (999) 999-9999 -- validation CDATA #IMPLIED -- types and syntax of validations have yet to be determined. Examples are: numeric, non-zero, date, case or if statements based on other fields in the form, etc. -- calculation CDATA #IMPLIED -- types and syntax of automatic calculations have yet to be defined. Examples are additions, multiplications based on other fields, SQL statements, etc. -- errmsg CDATA #IMPLIED -- error message to display. Error messages could also be displayed from within a calculation or validation case statement -- lockfields CDATA #IMPLIED -- mandatory for type=SIGNATURE -- <!--=================== Images ============================================--> <!ENTITY % Length "CDATA" -- nn for pixels or nn% for percentage length --> <!ENTITY % Pixels "CDATA" -- integer representing length in pixels --> <!-- Suggested widths are used for negotiating image size with the module responsible for painting the image. align="left" or right cause image to float to margin and for subsequent text to wrap around image --> <!ENTITY % IAlign "(top|middle|bottom|left|right)"> <!ELEMENT IMG - O EMPTY -- Embedded image --> <!ATTLIST IMG src %URL #REQUIRED -- URL of image to embed -- alt CDATA #IMPLIED -- for display in place of image -- align %IAlign #IMPLIED -- vertical or horizontal alignment -- height %Pixels #IMPLIED -- suggested height in pixels -- width %Pixels #IMPLIED -- suggested width in pixels -- border %Pixels #IMPLIED -- suggested link border width -- hspace %Pixels #IMPLIED -- suggested horizontal gutter -- vspace %Pixels #IMPLIED -- suggested vertical gutter -- usemap %URL #IMPLIED -- use client-side image map -- ismap (ismap) #IMPLIED -- use server image map -- > <!-- USEMAP points to a MAP element which may be in this document or an external document, although the latter is not widely supported --> <!--======================= Tables ========================================--> <!-- Widely deployed subset of the full HTML table standard, see RFC XXXX --> <!-- horizontal placement of table relative to window --> <!ENTITY % Where "(left|center|right)"> <!-- horizontal alignment attributes for cell contents --> <!ENTITY % cell.halign "align (left|center|right) #IMPLIED" > <!-- vertical alignment attributes for cell contents --> <!ENTITY % cell.valign
> <!ELEMENT table - - (caption?, tr+)> <!ELEMENT tr - O (th|td)*> <!ELEMENT (th|td) - O (%text)*> <!ATTLIST table -- table element -- align %Where #IMPLIED -- table position relative to window -- width %Length #IMPLIED -- table width relative to window -- border %Pixels #IMPLIED -- controls frame width around table -- cellspacing %Pixels #IMPLIED -- spacing between cells -- cellpadding %Pixels #IMPLIED -- spacing within cells -- > <!ELEMENT CAPTION - - (%text)* -- table or figure caption --> <!ATTLIST CAPTION align (top|bottom) #IMPLIED > <!ATTLIST tr -- table row -- %cell.halign -- horizontal alignment in cells -- %cell.valign -- vertical alignment in cells -- > <!ATTLIST (th|td) -- header or data cell -- nowrap (nowrap) #IMPLIED -- suppress word wrap -- rowspan NUMBER 1 -- number of rows spanned by cell -- colspan NUMBER 1 -- number of cols spanned by cell -- %cell.halign -- horizontal alignment in cells -- %cell.valign -- vertical alignment in cells -- > ]> Appendix B: Service Agreement
Service Agreement DTDNote: The DTD listed below was created using the previously recommended approach of content-specific DTDs per e-form. It was created at the start of this project and used during the pilot. As a result of the pilot, the DTD in appendix A is the recommended approach. This DTD, below, is included for completeness purposes only and is not recommended for use as an e-form exchange definition. <!DOCTYPE service [ <!-- **********************************************************************/ /* */ /* File: service.dtd */ /*Created By: Larry Osipenko larry@idc.com */ /* InfoDesign Corporation */ /* Owner: Government of Canada */ /* Function: Document Type Definition for the Specific Service Agreement */ /* Electronic Form */ /* */ /* Comment: This DTD was created as part of the E-forms SGML test project */ /* As such, no redesign of the form was performed. The DTD */ /* elements and attributes should match identically to the */ /* existing e-form. */ /* */ /* Public Identifier: */ /* The doctype declaration for each instance of this DTD should */ /* be as follows: */ /************************************************************************* */ <!Doctype service PUBLIC "-//CDN-GOV//DTD SERVICE E-FORM//EN" [ ]> /****************************************************************************/ /* */ /* History: */ /* */ /* V1.0 */ /* Date:March 22, 1996 */ /* Created By:Larry Osipenko */ /* InfoDesign Corporation */ /* */ /* Comments: 1. Wherever possible the element names were made identical */ /* to the names used on the e-form orginally created by */ /* Natural Resources Canada. It was not the intention of this */ /* project to develop naming standards for SGML elements. */ /* */ /* 2. Fields on the e-form which are radio buttons or checklists */ /* are defined in this DTD through the use of attributes. */ /* The value of the attribute signifies which radio button */ /* or checkbox has been selected. For checkboxes, anything */ /* other than a '0' or null means that it is checked. */ /* Typically '1' means checked. */ /* */ /* 3. All elements have been commented to contain the field # */ /* that the element represents on the form. Those elements */ /* which are reused within the DTD, such as LINE, NAME, etc. */ /* have not been given field numbers. The field numbers of */ /* reusable elements are defined by it's parent elements. */ /* Field numbers where provided to assist the e-forms vendors */ /* and reviewers of this DTD to understand how the elements */ /* map to the original form. */ /************************************************************************--> <!ENTITY % TEXT "(#PCDATA)" --<Title>TEXT-- > <!ENTITY % yesorno "NUMBER" --<Title>Yes or No-- > <!ELEMENT SERVICE - - (ORIGIN-USE, AUTHORIZATION)
> <!ELEMENT ORIGIN-USE - - (NAME, (EST-REQUEST | IMP-REQUEST), DATE, TELNO, SERI-NO?, FILENO?, PROJNO?, DESCRIP?, INV-ADDR?, DATE-REQ?, BUDGET?, SPEC-INSTR?, FIN-CODE?)
riginator.-- --Fields 1-25-- > <!ELEMENT NAME - - (%TEXT;)
> <!ELEMENT EST-REQUEST - o EMPTY
> <!ELEMENT IMP-REQUEST - o EMPTY
> <!ELEMENT DATE - - (%TEXT;)
> <!ELEMENT TELNO - - (%TEXT;)
> <!ELEMENT SERI-NO - - (%TEXT;)
> <!ELEMENT FILENO - - (%TEXT;)
> <!ELEMENT PROJNO - - (%TEXT;)
> <!ELEMENT DESCRIP - - (Line, (Line, Line?)?)
> <!ELEMENT LINE - - (%TEXT;)
ement.-- > <!ELEMENT INV-ADDR - - (LINE , (LINE, LINE?)?) --<Title>Invoice-to Address--
> <!ELEMENT DATE-REQ - - (%TEXT;)
> <!ELEMENT BUDGET - - (YEAR1?, YEAR2?, YEAR3?, TOTAL)
> <!ELEMENT YEAR1 - - (YEAR, AMOUNT)
> <!ELEMENT YEAR2 - - (YEAR, AMOUNT)
> <!ELEMENT YEAR3 - - (YEAR, AMOUNT)
> <!ELEMENT YEAR - - (%TEXT;)
> <!ELEMENT AMOUNT - - (%TEXT;) --<Title>Client's Budget for the Given Year-- > <!ELEMENT TOTAL - - (%TEXT;)
> <!ELEMENT SPEC-INSTR - - (LINE, (LINE, (LINE, (LINE, LINE?)?)?)?)
> <!ELEMENT FIN-CODE - - (%TEXT)
> <!ELEMENT AUTHORIZATION - - (NAME, DATE, TITLE, TELNO)
> <!ELEMENT TITLE - - (%TEXT;)
> <!ATTLIST SPEC-INSTR ATTACHMENT %yesorno #IMPLIED
> <!ATTLIST EST-REQUEST TYPE (ORIGINAL, AMENDMENT) #REQUIRED
> <!ATTLIST IMP-REQUEST TYPE (ORIGINAL, AMENDMENT) #REQUIRED
> <!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN" --<Title>ISOlat1-- > <!ENTITY % ISOgrk3 PUBLIC "ISO 8879-1986//ENTITIES Greek Symbols//EN" --<Title>ISOgrk3-- > <!ENTITY % ISOnum PUBLIC "ISO 8879-1986//ENTITIES Numeric and Special Graphic//EN" --<Title>ISOnum-- > <!ENTITY % ISOpub PUBLIC "ISO 8879-1986//ENTITIES Publishing//EN" --<Title>ISOpub-- > <!ENTITY % ISOtech PUBLIC "ISO 8879-1986//ENTITIES General Technical//EN" --<Title>ISOtech-- > %ISOgrk3; %ISOlat1; %ISOnum; %ISOpub; %ISOtech; ]> Service Agreement Sample Instance<!DOCTYPE SERVICE PUBLIC "-//CDN-GOV//DTD SERVIVE E-FORM//EN" "service.dtd"> <SERVICE><ORIGIN-USE><NAME>James Underhood</NAME> <EST-REQUEST TYPE="ORIGINAL"> <DATE>96-03-21</DATE> <TELNO>613 567-9587</TELNO> <SERI-NO>88888888</SERI-NO> <FILENO>123-45687-A0</FILENO> <PROJNO>ABC-987654-12</PROJNO> <DESCRIP><LINE>This is where you would enter a</LINE> <LINE>description of the service to be provided</LINE> <LINE>and where it is to be provided.</LINE></DESCRIP> <INV-ADDR><LINE>Accounts Payable</LINE> <LINE>Natural Resources Canada</LINE> <LINE>580 Booth Street, Ottawa, ON</LINE></INV-ADDR> <BUDGET><YEAR1><YEAR>96</YEAR> <AMOUNT>$1,000,000</AMOUNT></YEAR1> <YEAR2><YEAR>97</YEAR> <AMOUNT>$500,000</AMOUNT></YEAR2> <YEAR3><YEAR>98</YEAR> <AMOUNT>$750,000</AMOUNT></YEAR3> <TOTAL>$2,250,000</TOTAL></BUDGET> <SPEC-INSTR ATTACHMENT="1"><LINE>See the plans attached.</LINE> <LINE>Alternative plans can be viewed at my office.</LINE></SPEC-INSTR> <FIN-CODE>XYZ-FIN-CODE</FIN-CODE></ORIGIN-USE> <AUTHORIZATION><NAME>Mary Brown</NAME> <DATE>96-03-22</DATE> <TITLE>Supervisor</TITLE> <TELNO>819 993-9876</TELNO></AUTHORIZATION></SERVICE> Appendix C: Request for Translation
Request for Translation DTDNote: The DTD listed below was created using the previously recommended approach of content-specific DTDs per e-form. It was created at the start of this project and used during the pilot. As a result of the pilot, the DTD in appendix A is the recommended approach. This DTD, below, is included for completeness purposes only and is not recommended for use as an e-form exchange definition. <!DOCTYPE translat [ <!-- **********************************************************************/ /* */ /* File: translat.dtd */ /*Created By: Larry Osipenko larry@idc.com */ /* InfoDesign Corporation */ /* Owner: Government of Canada */ /* Function: Document Type Definition for the Request For Translation */ /* Electronic Form */ /* */ /* Comment: This DTD was created as part of the E-forms SGML test project */ /* As such, no redesign of the form was performed, the DTD */ /* elements and attributes should match identically to the */ /* existing e-form. */ /* */ /* Public Identifier: */ /* The doctype declaration for each instance of this DTD should */ /* be as follows: */ /****************************************************************************/ <!Doctype translat PUBLIC "-//CDN-GOV//DTD TRANSLATION E-FORM//EN" [ ]> /****************************************************************************/ /* */ /* History: */ /* */ /* V1.0 */ /* Date:March 16, 1996 */ /* Created By:Larry Osipenko */ /* InfoDesign Corporation */ /* */ /* Comments: 1. Wherever possible the element names were made identical */ /* to the names used on the e-form orginally created by */ /* Natural Resources Canada. It was not the intention of this */ /* project to develop naming standards for SGML elements. */ /* */ /* 2. Fields on the e-form which are radio buttons or checklists */ /* are defined in this DTD through the use of attributes. */ /* The value of the attribute signifies which radio button */ /* or checkbox has been selected. For checkboxes, anything */ /* other than a '0' or null means that it is checked. */ /* Typically '1' means checked. */ /* */ /* 3. All elements have been commented to contain the field # */ /* that the element represents on the form. Those elements */ /* which are reused within the DTD, such as LINE, NAME, etc. */ /* have not been given field numbers. The field numbers of */ /* reusable elements are defined by it's parent elements. */ /* Field numbers where provided to assist the e-forms vendors */ /* and reviewers of this DTD to understand how the elements */ /* map to the original form. */ /************************************************************************--> <!ENTITY % TEXT "(#PCDATA)" --<Title>TEXT-- > <!ENTITY % yesorno "NUMBER" --<Title>Yes or No-- > <!ELEMENT TRANSLAT - - (HEADER , ORIGIN-USE , (COORD-USE , BUREAU-USE?)?)
> <!ELEMENT HEADER - - (RG-REQ-NO2 , COTESEC)
> <!ELEMENT ORIGIN-USE - - (DEPART , BRANCH , DIVISION , TX-ORIG-FILE? , ORIGIN , AUTHOR? , TX-DOC-TITLE , TX-SUB-DATE , TX-WISH-DATE , SRCLANG , TGTLANG , DELIVERY , INCL , USE , PREVREQ? , SPEC-INSTR , AUTHORITY , NOPAGE? , CERT? , NAMELIB?) --<Title>Originator Use Fields--
> <!ELEMENT COORD-USE - - (DOC-TYPE , RCV-DATE , PRIORITY , REMARKS? , POLICY , COORD)
> <!ELEMENT COTESEC - O EMPTY
> <!ELEMENT DEPART - - (LINE , LINE? , TX-CODE) --<Title>Department Name-- --Fields 2,3-- > <!ELEMENT TX-CODE - - (%TEXT;) --<Title>Department Code--
> <!ELEMENT BRANCH - - (LINE , LINE? , TX-BRANCH) --<Title>Branch Name-- --Fields 4,5-- > <!ELEMENT TX-BRANCH - - (%TEXT;) --<Title>Branch Code--
> <!ELEMENT DIVISION - - (LINE , LINE? , TX-DIVISION) --<Title>Division Name-- --Fields 6,7-- > <!ELEMENT TX-DIVISION - - (%TEXT;) --<Title>Division Code--
> <!ELEMENT TX-ORIG-FILE - - (%TEXT;)
> <!ELEMENT ORIGIN - - (NAME , POSTIT , TELNO , ADDR) --<Title>Originator's Information-- --Fields 9-15-- > <!ELEMENT NAME - - (%TEXT;) --<Title>Person's Name-- > <!ELEMENT POSTIT - - (%TEXT;) --<Title>Position Title-- --Field 12-- > <!ELEMENT TELNO - - (%TEXT;)
> <!ELEMENT ADDR - - (LINE , LINE? , POSTCODE) --<Title>Postal Address--
> <!ELEMENT POSTCODE - - (%TEXT;) --<Title>Postal Code-- --Field 15-- > <!ELEMENT AUTHOR - - (NAME , TELNO) --<Title>Author's Information--
> <!ELEMENT TX-DOC-TITLE - - (%TEXT;)
> <!ELEMENT TX-SUB-DATE - - (%TEXT;) --<Title>Submission Date--
> <!ELEMENT TX-WISH-DATE - - (DATE , TGHOUR?) --<Title>Expected Return Date--
> <!ELEMENT TGHOUR - - (%TEXT;)
> <!ELEMENT SRCLANG - - (%TEXT;) --<Title>Source Language-- --Field 24-- > <!ELEMENT TGTLANG - - (%TEXT;) --<Title>Target Language-- --Field 25-- > <!ELEMENT DELIVERY - - (%TEXT;)
> <!ELEMENT INCL - O EMPTY --<Title>Inclusions Enclosed?-- --Fields 36,37-- > <!ELEMENT USE - O EMPTY --<Title>Intended Use-- --Fields 38,39-- > <!ELEMENT PREVREQ - - (REQ-NO, DATE)
> <!ELEMENT REQ-NO - - (%TEXT;) --<Title>Request Number-- --Field 40-- > <!ELEMENT DATE - - (%TEXT;) --<Title>Date--
> <!ELEMENT SPEC-INSTR - - (DISKNUM?, (SOFTWARE , VERSION)?)
> <!ELEMENT SOFTWARE - - (%TEXT;)
> <!ELEMENT VERSION - - (%TEXT;)
> <!ELEMENT DISKNUM - - (%TEXT;)
> <!ELEMENT AUTHORITY - - (NAME , POSTIT , SIGNATURE?)
> <!ELEMENT SIGNATURE - - (%TEXT;) --<Title>Signature-- --Field 54-- > <!ELEMENT NOPAGE - - (%TEXT;)
> <!ELEMENT CERT - O EMPTY --<Title>Certification--
> <!ELEMENT NAMELIB - - (%TEXT;)
> <!ELEMENT DOC-TYPE - O EMPTY --<Title>Document Type-- --Fields 55-62-- > <!ELEMENT RCV-DATE - - (%TEXT;) --<Title>Date Received--
> <!ELEMENT PRIORITY - - EMPTY --<Title>Priority-- --Fields 64-68 -- > <!ELEMENT REMARKS - - (LINE , (LINE , (LINE , (LINE , (LINE , LINE?)?)?)?)?) --<Title>Remarks-- --Field 69 -- > <!ELEMENT POLICY - - (Line, Line?) --<Title>Policy Complied To-- --Field 70 -- > <!ELEMENT COORD - - (NAME , SIGNATURE?) --<Title>Coordinator Information-- --Fields 71,72 -- > <!ELEMENT BUREAU-USE - - (TX-SEC-CLASS, TX-GEOG-CODE , TX-SRC-LANG , TX-TGT-LANG , RECEPTION , TX-TGT-DATE , SPEC-CODES , TX-RAT-PRTY , TX-TENT-WORD , TX-FINAL-WORD? , (TRANSLATION , FILENO , TX-NO-DOCS , CANCEL-DATE? , RETURN-DATE? , TRANSL? , REV? , TYPING? , PROOF?)? , RG-REQ-NO1) --<Title>BUREAU-USE--
> <!ELEMENT TX-SEC-CLASS - - (%TEXT;) --<Title>Security Class--
> <!ELEMENT TX-GEOG-CODE - - (%TEXT;) --<Title>Geography Code--
> <!ELEMENT TX-SRC-LANG - - (%TEXT;) --<Title>Source Language Code--
> <!ELEMENT TX-TGT-LANG - - (%TEXT;) --<Title>Target Language Code--
> <!ELEMENT RECEPTION - - (UNIT , DATE) --<Title>Received By--
> <!ELEMENT UNIT - - (%TEXT;)
> <!ELEMENT TX-TGT-DATE - - (%TEXT;) --<Title>Target Return Date--
> <!ELEMENT SPEC-CODES - - (TX-MAIN-SPEC1 , (TX-MAIN-SPEC2 , TX-MAIN-SPEC3?)?) --<Title>Specialty Codes--
> <!ELEMENT TX-MAIN-SPEC1 - - (%TEXT;) --<Title>Specialty Code #1--
> <!ELEMENT TX-MAIN-SPEC2 - - (%TEXT;) --<Title>Specialty Code #2--
> <!ELEMENT TX-MAIN-SPEC3 - - (%TEXT;) --<Title>Specialty Code #3--
> <!ELEMENT TX-RAT-PRTY - O EMPTY --<Title>Rated Priority--
> <!ELEMENT TX-TENT-WORD - - (%TEXT;)
> <!ELEMENT TX-FINAL-WORD - - (%TEXT;) --<Title>Final Word Count--
> <!ELEMENT TRANSLATION - - (UNIT , DATE)
> <!ELEMENT FILENO - - (%TEXT;)
> <!ELEMENT TX-NO-DOCS - - (%TEXT;) --<Title>Number of Documents--
> <!ELEMENT CANCEL-DATE - - (%TEXT;) --<Title>Cancellation Date--
> <!ELEMENT RETURN-DATE - - (%TEXT;)
> <!ELEMENT TRANSL - - (LINE , LINE?) --<Title>Translator Comments--
> <!ELEMENT REV - - (LINE , LINE?) --<Title>Revision Comments--
> <!ELEMENT TYPING - - (LINE , LINE?) --<Title>Typing Comments--
> <!ELEMENT PROOF - - (LINE , LINE?) --<Title>Proofing Comments--
> <!ELEMENT RG-REQ-NO1 - - (%TEXT;)
> <!ELEMENT RG-REQ-NO2 - - (%TEXT;)
> <!ELEMENT LINE - - (%TEXT;) --<Title>Single Input Line-- --Used when multiple lines of imput are allowed for a given element.-- > <!ATTLIST COTESEC CLASSIF (NONE , PROTECTA , PROTECTB , PROTECTC , CONFIDENTIAL , SECRET , TOPSECRET) #REQUIRED --<Title>Security Classification Radio Group-- > <!ATTLIST NAME --<Title>Person's Name-- MR-MS (MR , MS) #REQUIRED
> <!ATTLIST DELIVERY RTN-TYPE (CALL , MAIL , FAX , E-MAIL , MODEM) #REQUIRED
> <!ATTLIST INCL ENCL (INC , NOTINC) #REQUIRED
> <!ATTLIST USE --<Title>Material Use Checkboxes-- OUT %yesorno; #IMPLIED
WITHIN %yesorno; #IMPLIED
> <!ATTLIST SPEC-INSTR --<Title>Checkboxes for Instructions-- TRCH %yesorno; #IMPLIED
DRAFT %yesorno; #IMPLIED
SUMM %yesorno; #IMPLIED
DISK %yesorno; #IMPLIED
> <!ATTLIST CERT CERT %yesorno; #IMPLIED
> <!ATTLIST DOC-TYPE DOC-TYPE (CORRES , CIRCULAR , JOBD , REPORT , AGENDA , MANUAL , PUBLICATION , OTHER) #REQUIRED
> <!ATTLIST PRIORITY PRIORITY (1 , 2 , 3 , 4 , 5) #REQUIRED
> <!ATTLIST TX-RAT-PRTY PRIORITY (1 , 2 , 3 , 4 , 5) #REQUIRED
> <!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN" --<Title>ISOlat1-- > <!ENTITY % ISOgrk3 PUBLIC "ISO 8879-1986//ENTITIES Greek Symbols//EN" --<Title>ISOgrk3-- > <!ENTITY % ISOnum PUBLIC "ISO 8879-1986//ENTITIES Numeric and Special Graphic//EN" --<Title>ISOnum-- > <!ENTITY % ISOpub PUBLIC "ISO 8879-1986//ENTITIES Publishing//EN" --<Title>ISOpub-- > <!ENTITY % ISOtech PUBLIC "ISO 8879-1986//ENTITIES General Technical//EN" --<Title>ISOtech-- > %ISOgrk3; %ISOlat1; %ISOnum; %ISOpub; %ISOtech; ]> Request for Translation Sample Instance<!DOCTYPE TRANSLAT PUBLIC "-//CDN-GOV//DTD TRANSLATION E-FORM//EN" "translat.dtd"> <TRANSLAT><HEADER><RG-REQ-NO2>1019987</RG-REQ-NO2> <COTESEC CLASSIF="NONE"></HEADER> <ORIGIN-USE><DEPART><LINE>Natural Resources Canada</LINE> <TX-CODE>333</TX-CODE></DEPART> <BRANCH><LINE>Mines</LINE> <TX-BRANCH>55</TX-BRANCH></BRANCH> <DIVISION><LINE>Longlac</LINE> <TX-DIVISION>77</TX-DIVISION></DIVISION> <TX-ORIG-FILE>123456789</TX-ORIG-FILE> <ORIGIN><NAME MR-MS="MR">André Moore</NAME> <POSTIT>Executive Assistant</POSTIT> <TELNO>613 993-9998</TELNO> <ADDR><LINE>580 Booth Street</LINE> <LINE>P.O. Box 10, Ottawa, ON</LINE> <POSTCODE>K1P5G8</POSTCODE></ADDR></ORIGIN> <AUTHOR><NAME MR-MS="MR">Robert Burns</NAME> <TELNO>708 456-8765</TELNO></AUTHOR> <TX-DOC-TITLE>How to SGML E-forms</TX-DOC-TITLE> <TX-SUB-DATE>960316</TX-SUB-DATE> <TX-WISH-DATE><DATE>960512</DATE> <TGHOUR>1300</TGHOUR></TX-WISH-DATE> <SRCLANG>English</SRCLANG> <TGTLANG>French</TGTLANG> <DELIVERY RTN-TYPE="E-MAIL">larry@idc.com</DELIVERY> <INCL ENCL="NOTINC"> <USE OUT="1" WITHIN="1"> <SPEC-INSTR DRAFT="1" DISK="1"></SPEC-INSTR> <AUTHORITY><NAME MR-MS="MS">T. Brown</NAME> <POSTIT>Supervisor</POSTIT> <SIGNATURE>T. Brown</SIGNATURE></AUTHORITY> <NOPAGE>120</NOPAGE> <CERT CERT="1"> <NAMELIB>Jim Jones</NAMELIB></ORIGIN-USE> <COORD-USE><DOC-TYPE DOC-TYPE="PUBLICATION"> <RCV-DATE>960318</RCV-DATE> <PRIORITY PRIORITY="4"></PRIORITY> <POLICY><LINE>TBITS Standard 123</LINE></POLICY> <COORD><NAME MR-MS="MS">M. Rabinski</NAME> <SIGNATURE>M. Rabinski</SIGNATURE></COORD></COORD-USE> <BUREAU-USE><TX-SEC-CLASS>AA</TX-SEC-CLASS> <TX-GEOG-CODE>BB</TX-GEOG-CODE> <TX-SRC-LANG>01</TX-SRC-LANG> <TX-TGT-LANG>02</TX-TGT-LANG> <RECEPTION><UNIT>345</UNIT> <DATE>960320</DATE></RECEPTION> <TX-TGT-DATE>960430</TX-TGT-DATE> <SPEC-CODES><TX-MAIN-SPEC1>123456</TX-MAIN-SPEC1> <TX-MAIN-SPEC2>234567</TX-MAIN-SPEC2> <TX-MAIN-SPEC3>345678</TX-MAIN-SPEC3></SPEC-CODES> <TX-RAT-PRTY PRIORITY="4"> <TX-TENT-WORD>120</TX-TENT-WORD> <TX-FINAL-WORD>160</TX-FINAL-WORD> <TRANSLATION><UNIT>889</UNIT> <DATE>960427</DATE></TRANSLATION> <FILENO>987654321</FILENO> <TX-NO-DOCS>1</TX-NO-DOCS> <RETURN-DATE>960429</RETURN-DATE> <TRANSL><LINE>Everything went well.</LINE></TRANSL> <REV><LINE>Not quite.</LINE> <LINE>Could be better</LINE></REV> <TYPING><LINE>ok</LINE></TYPING> <PROOF><LINE>Good here</LINE></PROOF> <RG-REQ-NO1>7869875</RG-REQ-NO1></BUREAU-USE></TRANSLAT> Appendix D: PARTICIPANTS - Electronic Forms Interface Standardization Pilot ProjectParticipant OrganizationEd Buchinski Treasury Board Secretariat Carol Chambers Department of National Defence Neal Davies JetForm Corporation Robert Dupuis Public Works Government Services Canada Ernie Isaak JetForm Corporation Stan Jaknunas Department of National Defence Norman LeCouvie Novell Canada Ltd. Neil Levette National Energy Board Jim Lowe Public Works Government Services Canada Gavin McKenzie JetForm Corporation Dave Milne Department of National Defence David Nikkel JetForm Corporation Ernie O'Dell Department of National Defence Larry Osipenko InfoDesign Corporation Robert Rouleau Natural Resources Cananda Tim Sage Craig Technologies Sonia Schindler Public Works Government Services Canada Lothar Wegner Craig Technologies Observer OrganizationBruce Catley Public Works Government Services Canada Angèle Gosselin Public Works Government Services Canada John McDonald National Archives of Canada Kent McPhee Shana Corporation Wayne Malkin Shana Corporation Don Murphy Shana Corporation Mike Tardif Treasury Board Secretariat Russell Thomas National Research Council Michel Vulpe Infrastructures for Information |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
||||||||
|
 Top of Page |
Important Notices | ||||||
