Figure 3 - The Hierarchy of a Memorandum Document Type Definition
The objective of the project was to investigate the potential for developing an electronic forms specification, processing and interchange environment which would comply with applicable international standards - ISO 8879, the Standard Generalized Markup Language (SGML) and ISO 10744, the Hypermedia and Time Based Structuring Language (HyTime). Since standards facilitate intersystem communications and forms data interchange, the investigation summarized the inherent characteristics of open systems and SGML in order to contrast the standards-based approach with more traditional automated forms systems. To meet the needs of a complete electronic forms environment, it was assumed that the impact of SGML and HyTime had to be considered with respect to: forms design; edit rule specification; forms filling; forms printing; forms interchange, and; forms information storage.
Since implementation of electronic forms should not be regarded simply as an exercise in replacing paper forms with their electronic counterparts, this project used a formal methodology and approach to investigate the electronic forms environment. A more comprehensive approach was used to analyze the semantics (or "meaning") of the data captured within forms, as well as to understand how users see, access, use and manage the form's contents. The Document Development Life Cycle (DDLC) framework provided the context for examining the roles and responsibilities that contribute to efficient and effective use of electronic forms based on SGML.
This project examined some of the unique properties that the SGML and HyTime standards can contribute to an electronic forms environment. It included an analysis of the Government of Canada Training Application and Authorization form within a SGML demonstration implementation. The demonstration implementation consisted of multiple SGML products running on heterogeneous hardware platforms connected by several telecommunications networks to illustrate that an electronic forms environment can be supported through standards-based technology.
The investigation results indicate that a formal approach to electronic forms implementation offers opportunities for rationalizing a form's contents and structure based on the meaning of the data. In addition, available SGML-compliant products can support, to varying degrees and effectiveness, the requirements for forms design, forms filling, forms data formatting and distribution as well as forms data storage and management.
In light of the demonstration environment and the contracted findings, the Project Advisory Group made a number of observations and recommendations regarding additional initiatives which could be undertaken to address issues that fell outside the scope of this study. In conclusion, the vendor, platform and network independent environment, assembled for this demonstration, implies sufficient benefits to justify a joint government private sector pilot implementation of an SGML-compliant electronic forms project.
More specifically, this project provides an opportunity to demonstrate how forms-based applications could be renewed and re-engineered to deliver government services through the innovative use of standards-compliant information technology.
The demonstration system configuration, which will be based on an analysis of two representative forms (1) and a knowledge of current electronic forms technology, is meant to illustrate the nature of processes that could be performed on forms data within an SGML-based environment. Although representative of forms processing, it is not meant to reflect a full-featured electronic forms user environment.
The project scope, methodology, demonstration system strategy, and findings were discussed with the Project Advisory Group, an EDSWG sub-group, to incorporate advice and reflect issues identified in earlier electronic forms studies and pilots undertaken by government departments.
Ben Bloommesteijn TBS Robert Boissonneault PWGSC Daniel Boucher TC Ed Buchinski TBS Martin Flood TBS Nadene Grattan RCMP Andrea Keele DND Lorraine Léger Canadian Heritage Andy Morgan DND Lise Potvin TBS Jean Pruneau HC Michael Pyefinch PWGSC Robert Rouleau NatResCan Russell Thomas NRC John Whelan INAC
A forms application consists of a form layout or definition, the set of processes and procedures used to enter, validate and interchange the information contained on the form and copies of the filled-in forms (i.e. also referred to as an instance(s) of a form). Typically, the information on a form is well defined and highly structured - for example, codes are widely used to represent textual values that are displayed to the user. The information is also frequently organized in such a way that exceptional situations are highlighted for special attention and processing.
Forms applications usually involve more than one person, with each person contributing information, validating or revising existing content, authorizing a payment, a request or follow-up activity, etc. .
Historically forms applications were designed for a paper-environment and the paper paradigm is still evident in most of the automated forms systems that have been implemented thus far.
Open systems are enabled by adherence to international standards. Users can achieve an open system environment by demanding vendor fidelity to standards specifications and choosing technology solutions to meet explicit user needs without compromising data interchange and system portability. In so doing, the user community can be protected from proprietary data encoding inherent in vendor software/hardware implementations and thereby ensure data usability beyond the commercial life span of individual vendors or their products.
Although arguments have been made to the contrary, vendor adherence to international standards does not inhibit feature differentiation in commercial products, but rather, enhances the competitive environment. Vendors can compete for "best of breed" status without sacrificing innovation, data interchange or system inter-connectivity capability. Government and industry has an opportunity to demonstrate its commitment to open systems policies by using applicable international standards within electronic forms-based applications. Specific areas within a forms environment to which standards could be applied include:
- forms design;- edit rule specification;
- forms filling;
- form printing;
- forms interchange, and;
- form information storage.
The international standard for SGML provides the potential to reduce costs, decrease processing time and increase the value of forms-based data. By using the descriptive markup capabilities of SGML, processing systems may be designed in a more generic fashion and may be deployed on a wider scale. This would result in cost reductions for both development and maintenance processes. More emphasis could be placed on information content rather than on procedural issues and thereby contribute to job enrichment opportunities. To illustrate how these benefits may be achieved, the following paragraphs describe the concepts of document coding or markup and document structuring that are supported by SGML.
All electronic documents contain some form of markup. Documents that are created by word processing programs typically contain additional instructions that indicate formatting controls which are to be applied to the data content whenever it is presented on a screen or a piece of paper. This type of markup, which can contain a wide range of process control instructions, is referred to as Procedural Markup.
An alternate form of markup, named Descriptive Markup, is used to identify the semantics (i.e. the meaning or purpose ) of the content to which the markup is applied. Descriptive markup can be hierarchically structured, identifying those pieces of information that are components of other pieces of information. For example, a paragraph is contained within a section which in turn may be contained within a chapter. This hierarchy, or "tree structure" (also referred to as arborescence), is a top to bottom breakdown of a document into its constituent units.
The following paragraphs highlight the characteristics of systems that support each of these two types of markup and the ways these systems influence the processes and uses for which the encoded information is used.
When utilizing descriptive markup, procedural instructions (e.g.: display formatting commands) are normally applied by separate processes to the marked up information components. This allows the content that is descriptively marked up to be accessible, validatable, reusable and variably processable.
While typical word processing and desk top publishing systems utilize proprietary procedural markup, SGML provides a descriptive markup capability that is platform and product independent, enabling a large variety of tools from different vendors for information creation and manipulation.
Procedural markup does not, typically, address or attempt to eliminate platform dependencies such as the machine character set. For example, the encoding of accented letters will vary among systems and a file created on an Apple[ Macintosh or UNIX[ system will not be directly processable by an IBM-PC[, due to character set incompatibilities.
Figure 1 provides an example of the kind of procedural markup that may be embedded in an office memorandum. Note how the markup within the document, as defined by the vendor, is oriented towards the presentation or the processing (hence "procedural") of the information content contained between the markup.
[Centre] MEMORANDUM [Hrt][Hrt]To:[Tab][Tab][Bold]John Smith[bold][Hrt][Hrt]
From:[Tab][Bold]Noël René[bold][Hrt][Hrt]
Subject:[Tab][Bold][UND]Future Memoranda Use[und][bold]
[Hrt][Hrt]This is a note regarding the future creation of
memoranda.[Hrt][Hrt]Please ensure that memos are concise.
Figure 1 - An Example of WordPerfect® Reveal Codes
Problems will arise when an organization's information is encoded using procedural markup. If it becomes necessary to change vendors or to process legacy data with different applications, one can not be assured that vendor-specific markup will necessarily be correctly interpreted by the new or different product. Similarly, if a revised process must be used with legacy data created for one particular purpose, one can not be assured that the process-specific markup will necessarily be correctly interpreted.
Descriptive markup allows information to be identified by its purpose, thereby making the information accessible and available for processing as intended by the information creator. Document components that are accessible can be re-used by multiple process and applications without invoking data conversion routines.
Processes may differ due to user preference (e.g.: one user desires lists numbered with digits while another prefers roman numerals), due to medium (e.g.: paper printing, interactive screen delivery, or CD-ROM distribution), due to purpose (e.g.: database loading or report printing), or due to some other characteristic.
Figure 2 illustrate how an office memorandum could be markup up descriptively. Note how the markup identifies the semantics of the content that is contained between each set of markup codes. Note also that the system dependencies are removed. For example, character set encoding conflicts may be eliminated through descriptive markup (i.e. the substitution of character entities representing non 7 bit ASCII data). In the example, the accented character "e" is represented as "é" in standard SGML coding. It is the responsibility of the processing system to interpret such substitutions into the forms required by the local system.
Figure 2 - A Descriptively Marked Up Memorandum Document Instance<memo>
<header>
<to>John Smith</to>
<from>Noël René</from>
<subject>Future Memoranda Use</subject>
</header>
<body>
<para>This is a note regarding the future creation of
memoranda.</para>
<para>Please ensure that memos are concise.
</para>
</body>
</memo>
The information contained within a document is defined in a top down manner using the descriptive markup. The resulting definition portrays the structure of a document as a hierarchy of document components. For example, the first set of tags (i.e. <memo> and </memo>) apply to the entire document. They are followed by tags for the next level of components (i.e. <header> and <body> which are in turn subdivided into their constituent information items. This process of specifying successive components is applied during the analysis phase for each type of document. Figure 3 provides a graphical representation of the information structure that is applicable to a descriptively marked up sample memorandum.
Figure 3 - The Hierarchy of a Memorandum Document Type Definition
Automated formatting was originally performed by using specific coding that mimicked typesetting commands (e.g.: "space 3 lines", "use Times font", etc.). In the late 1960's, generic coding was developed for the publishing industry by IBM's GENCODE project. This project created a suite of generic tags for use in documents (e.g.: "heading", "paragraph", etc.). In 1982 the ISO sub-committee responsible for Document Processing and Related Communication began to develop the specification for SGML in order to overcome the limitations of GENCODE (e.g.: restricted tag set, etc.). By abandoning the suite of generic tags established by GENCODE, SGML allows users to define customized tagging structures.
Two language specifications make up the standard, one to specify the markup language for a class (or type) of documents, and another to markup instances of a class of documents. The document class is described by the Document Type Definition (DTD). Individual content files that follow a Document Type are called document instances.
HyTime, standardized in 1993 as ISO 10744, is the Hypermedia and Time-Based Structuring Language, and is based on the SGML language. HyTime is used to express certain semantic relationships between information components. Of interest to forms are constructs related to lexical specification (i.e. the ability to specify specific content values or ranges for a given information item) and location addressing (i.e. the ability of indicate a specific location within a document).
Similarly within the word processing and desk top publishing sector, commercial systems utilize customized formats that are geared to effective formatting and laying out information. Each vendor has typically chosen a format of their own that combines content and layout in an efficient way. Documents conforming to these formats are procedurally marked up and are typically flat and unstructured. The gradual use of styles may convey some notion of semantic meaning to documents, - styles are not hierarchical (one cannot typically have styles within styles) and styles are very often merely used to capture packages of formatting instructions.
As illustrated in Figure 4, each use or process applied to data is very often tied to the data formats optimized for that process. Each vendor that adopts a process-biased data format, in turn, provides a unique document creation environment to the user.
Figure 4 - The Traditional Approach to Documents
While commercial software is available to interpret the customized codes embedded in other packages, the data conversion is never guaranteed and is rarely totally successful. Typically the source information comprises indivisible format and content data and the conversion software lacks the ability to isolate and separately exchange any one of the two components.
The successful interchange of content and format between different hardware platforms or vendors' packages relies on the ability of vendors to successfully interpret the procedural markup defined by others. At times, platform dependencies are built into the forms, most notably with regard to character set encoding. An example of incompatibility is the coding of an accented letter on an IBM PC platform. This differs from that on either a Macintosh or UNIX platform. Successful translation must accommodate platform as well as vendor created data incompatibilities.
The benefits of the traditional approach to document systems are rooted in the dependencies of vendor-specific procedural markup. The packages that support this approach can make the focused task of the user very simple to execute and quick to perform. As a result, the vendor can move their package into the mainstream and support the resulting large installation base well.
The drawbacks of these systems are also rooted in the application dependencies in that the markup is too focused to the task at hand to be flexible for other purposes. The content and procedural information are too tightly combined to be separated easily. The "shelf life" of the information may be directly related to the vendor remaining in business or even the length of time that a specific version of software remains supported by the vendor. Vendor demise or extensive version changes can result in costly product upgrades or data conversions.
The contents defined and contained within a organization's collection of paper forms is typically defined and managed within a traditional forms application by using a database system. Flexible forms packages allow the user to select a database system from many vendors. The form filling component provides the user with the means for creating content and presenting that content in a paradigm familiar to the user of paper forms. Figure 5 depicts two communities of users and the form filler programs supporting two traditional forms environments.
Figure 5 - A Traditional Approach to Forms
To accommodate user specific access to form contents, forms systems can separate layout from content. The form layouts can be customized to meet the needs of different users in creating, editing or viewing forms contents. These layout specifications are vendor specific in much the same way that proprietary markup is used in traditional document systems. Each vendor utilizes a format best suited to their view of processing and their software packages. Consequently, there is no guarantee that the layout of forms can be successfully interchanged between packages created by different vendors. Typically one community of users using one vendor's software can not share form layout information with a community of users using a different forms package or hardware platform.
The benefits of traditional forms systems centre around the ability for a community of forms users to successfully accomplish the task at hand. The homogeneity of the environment within the community ensures successful creation, use and interchange of forms data within that community.
Drawbacks are coming to light as users recognize the need to interchange the contents of the forms and to share the layout of forms between communities of users. Differing database implementations of form content, differing community formats of database records, and differing vendor implementations of form layout present obstacles to successful interchange of this information. It is becoming increasingly evident that vendor and system dependencies can require total redesign of content and form layout information.
Figure 6 - The Structured Approach to Documents
The model for a document is expressed in a markup grammar. When that expression mechanism is standardized, vendor applications that endorse the standard are obliged to conform to and understand this markup in a consistent and predictable fashion. Standards compliant software may run on different platforms and free data from platform dependencies (e.g.: character sets). By adopting a common denominator for data representation, a standard syntax allows platform dependencies to be accommodated (e.g. accented characters are encoded independent of the character set implementation used on specific platforms).
Users of standardized markup are free to choose software products from different vendors for creation and subsequent processing of data. Communities of users that choose to share specific document models can realize added benefits by being able to interchange documents directly between their respective systems. Legacy documents will remain usable as the standard generalized markup will ensure that new and enhanced systems will process the old conformant data.
As users' requirements evolve, it may become necessary to change vendors or hardware platforms. User information investments will be safeguarded by the standard syntaxes and they will be able to take advantage of enhanced suites of features and user interfaces built upon commonly used technology.
The specifications of processes that act on structured data may or may not themselves be standardized. Users can accelerate this process and realize added benefits by encouraging vendors to adopt standardized processing specifications such as the recently finalized layout specification - the ISO standard for Document Style, Semantics Specification Language (DSSSL).
The benefits of structured document systems are closely linked to the flexibility provided by the standardized expression of document structure and document content. This flexibility protects the users investment in their information resources while giving them a choice of vendors products and hardware platforms.
The drawbacks that exist today for these systems center around the infancy of the technology. Higher "front-end" costs are usually borne by earlier adopters of international standards. Since the standard syntaxes and associated processes are necessarily complex, it may still take a little time before user interfaces and products are available that have been designed to hide this complexity. In the meantime, user training and consulting services may be required to achieve successful implementation. While an innovative vendor base for these technologies is growing, it is still true that the mainstream vendor of proprietary document management have been slow in adopting structured document standards. As a result, implementation costs are higher than that those associated with popular word processing or desktop publishing systems. These disadvantages will diminish as the markets grow and the technologies mature.
Figure 7 - A Structured Approach to Forms
In order to realize these benefits, structured forms systems must use a standard syntax to create, display and interchange the forms information as indicated in the following paragraphs.
The structure of forms information will have to be expressed in the same way as the content structure for documents. These specifications will enable users to capture the content through a process which is analogous to those currently followed in, "filling-out" proprietary electronic forms. However, they will be able to do so using software from different vendors running on various platforms.
A critical success factor for the widespread use of electronic forms is the appearance or layout of information within a form. Successful implementations of electronic forms must be able to replace the use of paper forms without unduly compromising established forms processing and creation practices. The ability for users or entire communities to customize the layout design is a key capability for an electronic system. The necessity to customize the layout, in turn, brings about a need to be able to interchange layout designs or specifications within and across user communities.
The many processes to be executed on forms content can also be specified to be independent of vendors or systems. Form editing, printing, and database loading are examples of different processes that act on forms content, which could potentially be supplied by different vendors and which could run on different hardware platforms.
To ensure interchangeability of layout design and process specification, common mechanisms will need to be employed. The figure depicts this concept by using a common layout model between the two layout descriptions used by two different communities. Since standards for layout or process specifications are lacking for forms users and systems, there is an opportunity to contribute to such a standardization effort.
The benefits of a structured forms environment are analogous to all the benefits of structured documents and should exceed the paybacks of traditional forms systems due to the flexibility provided by the standards approach and the reusability of the forms information. Central databases of structured information can be created, forms content can be easily interchanged within a community and between communities, printing can be made flexible, and layout specifications can be interchanged both within and between communities. Other benefits of descriptive markup approach to electronic forms will likely become apparent as implementations become more advanced.
The drawbacks of this approach also parallel the very drawbacks of structured documents implementation due to the infancy of the technology. Users and vendors may need to collaborate to ensure timely and effective implementation of standards-based technology in electronic forms applications.
It has been recognized that traditional systems address as little as 10% of an organization's total information holdings - that 10% being the very structured or tabular (i.e.: database) information. Much of the remainder is buried in documents, and is difficult to access using traditional systems approaches. Within the past decade, new efforts have been initiated towards making use of information that is buried in documents.
A Document Development Life Cycle exemplifies these new initiatives and provides a useful methodology for analyzing, identifying and organizing the information contained in documents.
One perspective of the DDLC is as a framework composed of six phases: planning, analysis, design, creation, distribution, and management. Such a framework is depicted in the Computer Aided Document Engineering (CADE[) document management framework.
The following describes the nature of the steps of the DDLC in the context of an organization's documents. For each phase the first paragraph explains the essential aspects of the DDLC methodology while the second indicates the type of tools that are available to perform the essential tasks.
Planning
Planning ensures that document projects are built on a firm foundation. It encompasses the scope, objectives, resources, timelines, budgets, responsibilities, and deliverables of the project. As well, Planning includes decision-making about business re-engineering opportunities, business-case development, pilot projects, tool selection, and critical success factors.
The output of Planning is a set of requirements, goals, budgets, and tasks. The tools available for the Planning phase include groupware and office-automation products (like word processors and spreadsheet programs).
Analysis
In Analysis the business requirements discovered by Planning are used to identify required information objects. Objects can be collected and categorized, using a collaborative, consensus-building approach to provide an electronic central repository of objects and decisions that is used as a "data dictionary" for enterprise-wide use and for later DDLC phases.
This approach allows subject-matter experts to participate in the analysis without requiring them to know such underlying technologies as SGML. Analysis can use groupware software tools to facilitate decision making without relying on face-to-face meetings.
Document Design
In Document Design, objects identified in Analysis are arranged into document models - summaries of document structure. Alternative models are considered and the design is finalized.
Tools used include the repository established in the Analysis phase and an interface which allows maintenance of ASCII files with structure described by SGML document type definitions.
Instance Creation
Instance Creation uses models created in Document Design to guide the creation of new document instances, or to convert existing information into document instances.
Structured editors and legacy-document conversion products are commercially available from various vendors and could be used effectively and efficiently within this phase. The outputs of this phase are structured documents, such as SGML document instances.
Instance Distribution
The Instance Distribution phase addresses the storage, retrieval and publishing of structured information. Structured documents can be used to develop a single-source repository from which multiple forms of output may be generated.
This phase uses tools such as printing systems, electronic viewers, and CD-ROM publishers. Central to the Distribution phase are information repositories and text retrieval facilities.
Management
Management completes the knowledge accumulation and dissemination process that is embodied in the DDLC. Examples of management activities are the determination of which types of documents will be created and which purchased, who will be responsible for acquiring and managing the documents, and which documents shall be discarded and which archived.
Tools for Management control information access, workflow, and archiving. Carefully managed repositories ensure that an organization gains knowledge to continuously feed the DDLC cycle. The iterative nature of the DDLC results in an ongoing process of improvement.
Because a form is a type of document, the Document Development Life Cycle is applicable to the development and use of forms as well, with minor adjustments, to reflect the more specialized forms environment.
Therefore, in the context of forms, the Form Development Life Cycle (FDLC) would be comprised of the phases: Form Planning, Form Analysis, Form Design, Form Instance Creation, Form Instance Distribution, and Forms Management.
This brings to the forms world the advantages that the DDLC brings to the document world. For example, the Form Analysis phase results in a shared element repository of information objects related to forms. Thus, in the design of any new forms, these objects could be re-used, with a corresponding reduction in form creation effort and cost.
Infrastructure is the underlying foundation which supports the daily activities of an organization or system. It includes:
It is recognized that the on-going government-wide efforts to restructure government and to re-engineer service delivery while maintaining a technologically adept civil service will have a major unspecified impact on the first three elements of infrastructure. However, these are outside the focus of this analysis.- the organization and the way it is structured;
- the functions, processes and procedures through which work is performed;
- the people and the way they are assigned to roles;
- the technical environment and;
- organizational standards relating to these items.
Examples of components of the technical environment include building and workstation layout, communications tools (telephone, FAX, computer network hardware and software), and central computing hardware and software.
Those components that are germane to the use of SGML in electronic forms are related primarily to the software tools selection or development for the FDLC (all other issues are orthogonal). The platform independence and data transparency of SGML allow forms encoded using SGML to be communicated easily within existing networks and communications infrastructure. System resources such as information repositories or database lookup tables may also come to bear on the FDLC, perhaps by facilitating document creation, editing and content validation.
SGML enables information to be represented in a platform and vendor independent fashion, thereby ensuring long term utility and transportability across environments.
It should be noted, however, that the product feature differentiation (e.g.: ease of use, hardware platforms supported, etc.) available from vendors is an important consideration when selecting SGML-enabled software to utilize within a particular environment. Not all products that support SGML are necessarily applicable or desirable in automated forms. SGML is not a panacea for electronic forms, but only a technology that offers certain critical benefits for an electronic forms environment. How vendor products or custom solutions deliver those benefits will impact on the software selection.
These repositories could also hold, maintain and disseminate the following types of information in a shared environment at a departmental or government-wide level:
- document type definition components or fragments;
- layout and presentation descriptions;
- departmental standard information sets (valid field values, look-up tables, etc.) and
- form instances.
An information repository may be maintained centrally or in a distributed fashion.
The Treasury Board Secretariat report Requirements Definition for Structured Document Registry and Repository addresses some of the issues related to the implementation of libraries of structured documentation, especially SGML documents, and the provision of open access to the libraries for the purpose of electronic dissemination.
A training application and authorization form must be completed whenever an employee is provided with formal training totaling one day or more. Various individuals, including those that take, administer and, that provide the training are required to supply the information identified in the form. These individuals include, training service suppliers such as the Public Service Commission (PSC), and the various staff in government departments that are part of the staff training and development functions within these departments.
Copies of this training form are appended as Attachments A & B to this report.
- Attachment A consists of a reproduction of a blank Training Application and Authorization plus the corresponding instruction sheets- Attachment B provides a sample of a completed form to illustrate the kind of information that would normally be supplied by a user.
The structure, contents and use of the Training Application and Authorization Form was analyzed and the results are summarized in Appendix A.
This form is used to record information concerning the identity of a training applicant, the course for which the application was made, and the authorizations that are required to administer the training process. This information is recorded in blocks on the form in sequence. In SGML terminology this sequence represents the document's structure and the individual items of information within these blocks are considered the document content. The following information blocks are presented on the form:
(a) Unique identifier and status of the training application (unnumbered fields and field 1); (b) Identification of the applicant, including supervisor's authorization (fields 2 to 16); (c) Description of the training course (fields 17 to 28); (d) Financial information, including the cost(s), and associated expenditure authorizations for the training course (fields 29 to 32); (e) Training control information (fields 33, 34 and fields on the back of the form) that is provided by departmental staff responsible for training program administration; (f) Applicant's evaluation of the training (unnumbered field on the back of the form), and; (g) Departmental use codes to be devised and applied as necessary within individual departments.
These activities could be categorized as determining who has to provide what information in order to advance the process to the next step. These represent a typical set of forms handling activities that can be generalized to include any kind of form. To represent these activities within an SIGMA-based electronic forms environment this demonstration was organized according to the Forms Development Life Cycle methodology (as derived from the Document Development Life Cycle described earlier in this report). The use of this methodology is illustrated in the following paragraphs.
Based on the inherent capabilities of the analysis tools selected for this activity, the resulting information objects could be easily accessed by subject experts and revised as necessary. The analysis methodology, enforced by the selected tools, should normally result in a set of information objects that are simpler to understand and manage than their counterparts in most existing paper and automated forms environments.
The end product of the analysis process was a central repository, which was implemented as a database of object declarations and model descriptions. This database could be used to support the development of other forms and to promote the use of the standardized names, values and definition for information objects that are common to various forms.
Ultimately, the seven blocks on the original form were reduced to the following five in the electronic version:
Once each editing environment was created, the respective SGML software packages could be used to create, to display and to modify form contents.
The result of this process was a demonstration site that could be used to capture, display, modify and store forms-based information and to encode this information as fully-compliant SGML documents. In a normal situation the instance creation process is carried out by each of multiple participants.
To accommodate the distribution requirements, the demonstration environment was configured to store SGML-encoded forms and associated contents as data files and to exchange them among the forms users using electronic mail applications that communicated over local and wide area networks.
The results of this process was an multi-vendor software and hardware facility that could successfully interchange SGML-based forms and also produce physical copies of the forms on paper.
This methodology was used in this project to illustrate that the strategy was useful in planning and controlling the implementation of the demonstration environment as well as to support creation, distribution and archiving of copies of the forms contents. The result of this process is the successful operation of the entire demonstration environment.
Figure 8 is a graphical summary of the steps that were followed in establishing the demonstration environment and in processing a sample training form through an entire life cycle. These steps are also summarized in Appendix B - Summary of Feasibility Demonstration. This summary names each step, identifies the type of participant that performed the task, lists the tools chosen for each step and gives a reference to attachments displaying the information relating to the step (for example, the information contained on the form following completion of the step is presented, both in the tool's layout format and through a listing of the SGML instance as an ASCII file).
Figure 8 - Overview of Feasibility Demonstration
To illustrate how the workflow associated with the training application and authorization form could be managed, the demonstration defined a scenario with associated roles to be performed by the following four types of people or groups:
- a Team, consisting of systems, SGML and subject matter (i.e. training) experts, to develop the forms application; - Al Applicant, an applicant for training; - Sue Supervisor, who is Al's boss and - Chris Coordinator, who manages the organization's training program.
The team defines the environment in which the workflow takes place. In summary, the workflow consists of the applicant filling out a form and forwarding it to the supervisor, the supervisor authorizing it and forwarding it to a submittal area for training applications, the training coordinator approving it and returning it to the applicant for final evaluation and archiving.
The demonstration did not employ any kind of mechanisms to validate digital signatures. Adequate authorization was deemed to be provided simply by typing a name within the appropriate signature field.
To support exchange of the training information between the three role players, four fictitious accounts were established to identify various e-mail addresses. Al Applicant was assigned the user ID "AAPPLIC" and Sue Supervisor the user ID "SSUPER" for use in the Windows environment. Chris Coordinator was given an account in UNIX and the UNIX account "TASubmit" (for Training Application Submission) was created as a pseudo-address. This communications infrastructure required the applicants to be informed of the address to which training applications were to be forwarded via e-mail. An automated e-mail handler accepted the mail message and accompanying, properly completed, training form and deposited the application in a directory common to those responsible for training. Chris Coordinator was given access to this directory.
The model is displayed in Attachments C and D (the graphical display in Attachment C corresponds exactly to the SGML coding in Attachment D), SGML elements and named groups are listed in Attachment E and SGML attributes are listed in Attachment F.
Al Applicant performed this step using Microsoft Word on a Windows platform. The layout of the form is presented in Attachments G (blank) and H (completed) and the resulting SGML instance is listed in Attachment I.
This transmission took place over the local area network which was used by both Al Applicant and Sue Supervisor. The form instance, created by Al, was directly accessed by Sue.
This is an editing step which was performed using InContext, a different brand of software than that used for creating the initial instance. This illustrates the vendor independence of SGML-based forms applications.
A screen copy of part of the input layout of the form is presented in Attachment J, Attachment K is a report of the information from InContext, and the SGML instance resulting from the editing is listed in Attachment L.
This editing step was performed on a UNIX platform (a different hardware platform) using ADEPT Publisher (yet another different brand of software). This desktop facility was chosen to illustrate both the platform independence and the vendor independence provided by the use of SGML-based technology.
Attachment M is a view of the editing environment provided by ADEPT Publisher. Attachment N is a report of the information from ADEPT, and the SGML instance resulting from the editing is listed in Attachment O.
This is an editing step in which the applicant enters an evaluation of the course. It illustrates that the data, having been modified on other platforms and by different software packages, can still be transferred and modified by yet another package running a completely different hardware and system environment.
Each vendor package, however, handled the DTD in a different fashion. One package allowed the DTD to be wholly contained within the prologue of the document instance, while the others required the DTD to be a separately processed, prepared and compiled entity within the system before being able to manipulate instances of the model.
In an open electronic forms environment, where users of the form models will not have the form's DTD before needing to create or modify instances of the form, it will be crucial to have the form model travel with the document itself. Two mechanisms that allow this to happen are the inclusion of the DTD declarations within the prologue of the instance, and the packaging of the DTD as a separate file with the instance. The SGML Document Interchange Format (SDIF), ISO-9069, could potentially be used to support the latter option.
It should also be noted that one of the editing environments successfully presented the content fields in a manner approaching the appearance of an actual printed version of the Government of Canada form. Further, it was established that the nature of the processes required for a forms environment is different from that represented in a typical SGML environment. While a typical document environment presents the SGML concepts of optionally, repeatability and alternation (choice) following sequential document writing paradigms (e.g. which of the following valid editing elements do you wish to edit at this point in the document), context is more explicitly controlled by the user in a forms environment (e.g.: point and click the mouse on a particular form field). In addition, in a forms environment there is opportunity to present the concepts of optionality, repeatability, and alternation using user interface dialogue constructs familiar to users of GUI interfaces (e.g.: radio buttons, check boxes, etc.).
<!NOTATION HyLex PUBLIC "+//ISO/IEC 10744:1993//NOTATION HyTime Lexical Model Notation//EN"><!ELEMENT GoClex - O RCDATA>
<!ATTLIST GoClex HyTime NAME #FIXED lexmodel
ltn NAME #REQUIRED
notation NAME #FIXED HyLex
tokens (tokens|notokens) notokens>
Using the above element declaration, the following two lexical types "pri" (for a 9 digit Personal Record Identifier) and "postcode" (for Canadian-styled postal codes) can be created:
<GoClex ltn=d>([0-9])</GoClex><GoClex ltn=a>([a-z]|[A-Z])</GoClex>
<GoClex ltn=an>([0-9]|[a-z]|[A-Z])</GoClex>
<GoClex ltn=pri>(d,d,d,d,d,d,d,d,d)</GoClex>
<GoClex ltn=postcode>(a,d,a,d,a,d)</GoClex>
Using these lexical constructs it is possible to provide the following specification for a postal code element:
<!ELEMENT POSTCODE (#PCDATA) --<title>Postal Code--><!ATTLIST POSTCODE --<title>Postal Code Attributes--
lextype CDATA #FIXED "#CONTENT postcode"
lexmodel NAMES #FIXED GoClex>
The use of this form of lexical modeling requires a management infrastructure supporting repository facilities which could facilitate and encourage easy access and use of the associated model. The lexical model specification syntax is an instance of a simple DTD fragment and, therefore, cannot be specified wholly within the DTD itself. To allow for simple document instantiation (the creation of a document from scratch), one cannot expect the user to have to include the lexical model within a new instance.
There is no requirement for the lexical model instance to be part of the user document instance, therefore, the lexical information can be kept elsewhere in the "system".
An example of two objects requiring the specification of a dependence follows:
Note, in the following SGML syntax, how the attributes of GROUPC and CMPC2 point to GROUPA and CMPA2, respectively.
<!DOCTYPE FORM [<!ELEMENT FORM - O (GROUPA? , GROUPB) >
<!ELEMENT GROUPA - O (CMPA1 , CMPA2? , CMPA3) >
<!ELEMENT CMPA1 - O (#PCDATA) >
<!ELEMENT CMPA2 - O (#PCDATA) >
<!ELEMENT CMPA3 - O (#PCDATA) >
<!ELEMENT GROUPB - O (CMPB1 , GROUPC?) >
<!ELEMENT CMPB1 - O (#PCDATA) >
<!ELEMENT GROUPC - O (CMPC1 , CMPC2? , CMPC3) >
<!ELEMENT CMPC1 - O (#PCDATA) >
<!ELEMENT CMPC2 - O (#PCDATA) >
<!ELEMENT CMPC3 - O (#PCDATA) >
<!ATTLIST GROUPA ID ID #REQUIRED >
<!ATTLIST CMPA2 ID ID #REQUIRED >
<!ATTLIST GROUPC linkwith IDREF #REQUIRED
refrange CDATA #FIXED "linkwith B"
reflevel CDATA #FIXED "linkwith 2"
reftype CDATA #FIXED "linkwith GROUPA" >
<!ATTLIST CMPC2 linkwith IDREF #REQUIRED
refrange CDATA #FIXED "linkwith B"
reflevel CDATA #FIXED "linkwith 3"
reftype CDATA #FIXED "linkwith CMPA2" >
]>
The HyTime-aware validation processes run on instances of form content can report non-compliance to the specified dependencies. As well, during form creation time, HyTime-aware editing facilities can mandate compliance to dependencies to ensure forms are complete before being saved.
One issue which deserves resolution is whether and to what extent uniform naming and coding of identical information across multiple forms is required or beneficial. A related issue is whether standard and proprietary systems alike could effectively use these common naming and coding conventions to make systems easier to learn and use while facilitating information exchange between independent applications and among separate organizations whenever the information needs to be exchanged.
Although various benefits might be realized through uniform naming and coding conventions, it is essential to recognize that this information is being gathered and specified in accordance with program needs rather than systems efficiencies. (4)
In addition the electronic form designs will have to meet all statutory and policy requirements, including those related to the Privacy Act, the Official Languages Act, the Communications policy, the Federal Identity Program policy, the Government Security policy and the information collection requirements of the MGIH policy
Version control is another aspect of forms design and management that poses a challenge, especially in decentralized systems and geographically dispersed departments. Explicit identifiers and controls are needed to ensure that everyone is using the proper version of a form at any given time. Older design specifications and revision justifications must be retained to ensure that archival data can be interpreted correctly when needed.
Data dictionaries associated with proprietary electronic forms systems allow forms managers to define and control the names assigned to specific content areas on the form. However, these designs can not be shared across the respective systems since, the proprietary data dictionaries can't receive or transmit the dictionary contents. The definitions embedded in the forms applications may also be duplicated in data dictionaries supporting other departmental applications.
As noted in the analysis phase, the layout of information on paper forms is influenced somewhat by the media as well as workflow considerations. Both of these aspects are impacted by the electronic environment and the opportunity of moving to electronic forms could be used to examine the significance and need for certain information.
Recommendation: - The potential for using common guidelines and standards for defining and sharing data dictionary content for forms should be explored and aligned with related initiatives on common reference data definitions and data dictionary standardization within the federal government while respecting existing policies which are relevant to forms design such as the one on official languages. This potential should also be explored with forms software vendors in order to arrive at the optimal solution for designing standard electronic forms and for exchanging these design specifications.
Available commercial forms applications provide a user-friendly interface to assist the user in recognizing what information is required and in supplying accurate values. In addition to the familiar forms layout, user help routines, pop-up menus of valid data values and post entry edits may be provided to support requisite and accurate data entry. The applicable values and associated explanatory information may be held in the supporting data dictionary. Various kinds of explanatory information could also be supplied through database look-ups.
By comparison, an SGML DTD provides a means of designating forms content as mandatory, repeatable and optional information. The presence of forms contents can be enforced by SGML-aware forms applications. However, it will be impossible to validate specific values for fields on the form until software is commercially available which supports the HyTime standard and which will enforce values defined in the DTD for each form. SGML applications software could be customized to invoke the appropriate validation rules whether these are located in the document type definition, in a database or a document.
Signature validation and verification remains a major challenge within electronic forms systems and vendors are devising unique solutions to fulfill this need. Various options for data encryption are available to ensure that a signature is valid (e.g. bit check sums on existing fields, challenge/response key methods, etc.) Selection of the best option may also be complicated by the need for multiple sign-offs and the requirement to delegate authorization authority to subordinates. The signatures must be auditable for many years in the future depending on requirements set by law or regulation. The algorithm, procedures and techniques must be robust enough to ensure non-repudiation by the signing parties.
The "e-forms" should have data entry points to indicate the designation / classification of the information contained there in. Only certain entries should be permitted such as Protected-A, Confidential, Secret etc. The determining factor in applying security measures is dependent on the sensitivity of the information processed and the environment where the data is stored and / or transmitted. Hence a threat / risk assessment should be conducted relative to the implementation of e-forms that contain data sensitive to disclosure, integrity and availability.
A signature encoding and authentication solution that may become common to government departments is being prepared by Government Telecommunications and Informatics Services (GTIS). The prospective solution includes a public crypto-key infrastructure to support assignment and management of "public keys" and "private keys" within the electronic directory system. Such services will become indispensable as government initiatives expand to include electronic filing of confidential documents such as income tax forms. Since the GTIS service is designed to encrypt and decrypt data for interchange purposes, it should also be capable of authenticating signatures on forms.
In addition, various working groups established by the CAR ITS Steering Committee are presently addressing issues associated with electronic authorization and authentication, firewalls and gateways, public key infrastructure, smart cards, privacy and confidentiality, legal issues and accountability all of which affect. A final report by the WGs, slated for June 1995, is expected to define a common security solution for federal government departments which should be equally relevant to electronic forms applications.
Recommendation: The need and opportunity to utilize common mechanisms to validate values and signatures in forms applications should be shared with government groups concerned with common reference data definitions, data dictionary standardization and security. In addition, the authorities for the electronic directory pilot should be encouraged to explore the potential support that a public crypto-key infrastructure and associated service could provide to forms applications.
Whereas open systems supporting SGML do not impose a specific "look-and-feel" on the user interface, the opportunity exists to develop a standard means of prompting the user for the required forms data. In effect the user might be provided with the electronic equivalent of a blank paper form or preferably with prompts managed by an "expert system" interface. The standard specification would be analogous to a document layout which is currently provided by a Format Output Specification Instance. The major difference is that the layout would consist of empty "boxes" which remain to be filled out by the user and this specification might be based on the newly developed ISO standard for document layout specification.
Regardless of the technological option that is used it will be essential to ensure that the "forms" are clearly presented and that they are easy to understand and use as required by government Communications policy. This policy applies especially to forms where the quality of the communication will invariably impact on the quality of the input and the overall transaction. The factors to be considered include the terminology used, the flow and structure of the information, the presentation of the various components and the clarity of the instructions, or prompts.
Recommendation: A pilot project should be developed to investigate possible options, including the use of the recently standardized Document Style Semantics Specification Language, for guiding and assisting users in providing the required information. Regardless of the technological option that is used it will be essential to ensure that the "forms" are clearly presented and that they are easy to understand and use as required by government Communications policy. Electronic forms vendors should be encouraged to participate in this investigation and to validate that such specifications could be used effectively without unduly compromising existing user interfaces.
The ability to specify document layout in a standard compliant way has been defined by the ISO standards for Document Style Semantics Specification Language and Standard Page Layout. An added requirement may include the ability to specify fonts and graphic elements using corresponding standard specifications. In addition, it seems appropriate that forms display should be customized to show only those fields that contain data and to omit those which are empty.
Since there are no pressing requirements to interchange common print or screen display specifications for electronic forms, commercial applications are free to provide attractive, proprietary displays in various media. However, the ability to reproduce archived electronic forms on paper and on the screen may become an issue since the proprietary print and display codes, in use today, are unlikely to run on future hardware platforms or forms applications. Archived forms data may have to be converted automatically or manually to ensure its useability in the future.
Recommendation: The need for consistent display of forms on electronic and hardcopy media needs to be examined further. Opportunities for specifying these types of displays in an applications and hardware independent manner should be explored with the appropriate standards bodies and the private sector.
As verified by the demonstration project, SGML provides a vendor and application independent means of specifying and encoding the contents of electronic forms. The underlying open systems strategy facilitates the interchange of forms information among all systems that are capable in processing the SGML syntax and offers a specific interchange format for commercial forms vendors.
To implement SGML-based forms data interchange, standard document type definitions (DTD's) would have to be developed for each form that is in common use. Conventions would also need to be specified to ensure that the corresponding DTD was available to all the interchange participants.
Recommendation: Dicument type definitions (DTD's) should be developed for a representative sample of government forms to verify that departments could effectively meet their forms interchange requirements and that commercial e-forms systems could efficiently generate the SGML-encoded data.
The data storage provisions must also meet government guidelines on information access and privacy. Thus the information in an entire form or selected portions may have to be locked using security codes, encryption and other access controls. SGML coding could also be supplied to indicate the conditions under which data was collected and under which it may be accessed.
Other requirements related to archival retention and disposition (e.g. selective purging of entire forms or portions thereof over time) imply added complexity. To meet the retention needs the electronic forms-based information can be output to microfilm but this option complicates selective purging and the legal requirement to delete personal information over time. The other alternative may be to use store this data on optical disk and to remaster the disk contents periodically while deleting the outdated information.
Recommendation: A a major requirement for forms data is that it be maintained in a medium independent information storage format. This format must be maintained throughout the entire forms life cycle in accordance with government access, privacy and archival legislation.
For example, the information which identifies a training applicant could reside in a personnel management system or in an electronic directory. Furthermore, the regulations defining employee entitlements, obligations and conditions under which training may be provided are typically specified in administrative manuals issued by the Treasury Board Secretariat and qualified, if necessary, by department training programs. These instructions could be accessible to the applicant, the supervisor and the program coordinator in a seamless manner using systems that integrated forms and documents. This information could be entered once and reused as necessary to support forms data entry, validation and information interchange.
Recommendation: Since the Treasury Board Manual includes various details concerning employee benefits and entitlements plus the forms to support the administration of various programs, there is an opportunity to coordinate the definition of forms contents with corresponding instructions and constraints given in administrative manuals. The benefits and challenges of doing so should be investigated closely as the Treasury Board Secretariat proceeds with its effort to convert its manuals to SGML.
Originally, the HTML-based forms were devised to prompt users for terms to be submitted to an information retrieval application. More recently this capability has been extended to support ordering of documents and services. Nevertheless, this functionality falls short of the e-form functionality investigated in the demonstration.
Although, ODA might represent a more efficient coding mechanism than SGML and while simultaneously providing a means of specifying form layout, commercial ODA-compliant applications aren't readily available at this time. This situation may change and the possible use of ODA may have to be examined further at a later date.
Recommendation: Both Intrernet forms and Open Document Architecture appear inappropriate and inadequate to support the evolving electronic forms environment. Therefore, neither option is recommended for serious consideration for government-wide implementation at this time.
Recommendation: The best way to introduce a degree of commonality to manage forms workflow, is to ensure that the electronic forms replicate the required control points. For example, the training application and authorization form requires specific information from various individuals plus their signatures. The requisite information plus the associated signature enable the workflow to be controlled and managed.
- Field and Content - The purpose of the values in these columns is to unambiguously identify the field and/or location which is being addressed;- Lexicon - This describes the structure and length (if it has been defined) of the information to be entered into the field;
- Values - This is a list or reference to a list of valid values (if available) for the field content;
- Opt - Optionality - This shows whether entry of information in the field is mandatory (M), optional (O) and/or repeatable (R) and
- Comments - This contains other information about the field, including reference to special validation requirements.
Note that the information presented in the lexicon and comments columns of the table reflects assumptions made during the analysis of the form.
- Lexical Analysis - The structure of the information to be entered into a specific field is described. The following symbols will be used to represent valid character patterns:X - any character data (a 12 digit string of characters is represented as "X(12)")
9 - numerical data (a 5 digit number is represented as "9(5)" or "99999")
A - alphabetic data (a 2 character alphabetic string is represented as "A(2)" or "AA")
An example of lexical analysis is the validation of a Canadian postal code - valid codes must appear as "letter number letter space number letter number", or "A9A 9A9".
- Multiple Fixed Values - There is a list of allowable values for the contents of a field that are known at design time. An example are the values Male and Female, used for a person's sex.
- Table Look-ups - There is a list of allowable values for the contents of a field that are known at the time the information is entered or accessed. Examples are the Special Needs coded values and the Province coded values.
- Reasonability Checks - This is especially appropriate in validating dates and times. An example involves the "from" and "to" dates of a training course. In this case, the check would be that the "from" date is the same as or earlier than the "to" date.
- Formulae - This type of validation deals with relationships between values in different fields on the form. For example, there would be validation that a total cost was the true sum of the itemized costs making it up.
- Validation of Authority - This applies to the sign-offs required by the form processing. The person who is signing-off must be in a position of enough authority to do so. This could be established by a cross-reference (i.e.: a list of names or positions, specifying the authority of each) or a set of rules. The most likely case is a set of rules, and an example of such a rule is "anyone whose position is this classification or higher and belongs to the same organization may sign this" for each possible signing of the form. This example would involve links to information related to the classification and position areas.
Field Content Lexicon Values Opt Comments
n/a (distribution PUBLIC M
instructions) SERVICE
- pre-printed on COMMISSION,
the bottom of each DEPARTMENT
part of five-part
form
n/a (FOR PSC USE ONLY) X(12), O - administrative use
- at top of form X(3),
X(2)
n/a (Application Original, M - if original, must
Status) Amendment, not refer to existing
- check boxes near Cancellation file number
top of form - if amendment or
cancellation, must
refer to an active
file number
- if there are
changes, it must be
an amendment
1 File number A9(7) M - pre-printed,
example A1906212
2 Special needs 99.00 01, 02, 03, O 01-Blind, 02-Deaf,
99 03-Physically
Disabled, 99-Other
3 Family name, text O
Given name and
initials
4 P.R.I. X(10) O
5 Sex Male, Female O
6 Classification X(2), samples CS, M
SM, AS, EL
X(3),
X(2)
7 First official English, O
language French
8 Position Title text O
9 Employee's office 999-999-99 O
telephone number 99
10 Department name text O
11 Department Code XXX M
12 Branch/Division text O
13 Office, text O
workstation,
mailing address
13 City text O
13 Postal code A9A 9A9 O
14 Supervisor's name text O - supervisor must be
and title employee of same
organization as
applicant
Field Content Lexicon Values Opt Comments
14 Supervisor's 999-999-99 O
Telephone number 99
15 Supervisor's text O
office,
workstation,
mailing address
15 Supervisor's City text O
15 Supervisor's A9A 9A9 O
Postal code
16 Objective of text O
training
16 Supervisor's sign-off O
signature
16 Signature date date
16 Employee's sign-off O
signature
16 Signature date date
17 Course code X(7) O - if source of
training (field 25)
is Training Program
Branch of the Public
Service Commission,
then this code must
be from the Schedule
of Courses
18 Course title text O - if source of
training (field 25)
is Training Program
Branch of the Public
Service Commission,
then this code must
be from the Schedule
of Courses
19 Location of text O
training
20 Date of course date, O
(from, to) date
21 Departmental 999.00 as listed on M - allowable courses
training program instruction depend on HR class of
code sheet applicant
22 Time of training Yes, No M
23 Duration of 999.00 greater than M - must be consistent
training 0 with from/to dates of
(person-days) course
24 Language of course English, O
French,
Bilingual,
Other
25 Source of training TPB/PSC, M
Departmental
Interdept'l,
University/
College,
Other
26 Transit time 999.00 greater than O
(person-days) 0
27 Province (code) XX as listed on O
instruction
sheet
Field Content Lexicon Values Opt Comments
28 Location text O
29 Tuition fee / None, O
Reimbursement Half,
Full
29 Tuition Fee valid OR
- Financial code responsibilit
y centre
codes
29 Tuition fee money greater than O
- Estimated cost 0
29 Tuition Fee money greater than M
- Actual cost 0
29 Travel / Living valid OR
- Financial code responsibilit
y centre
codes
29 Travel / Living money greater than O
- Estimated cost 0
29 Travel / Living money greater than M
- Actual cost 0
29 Other valid OR
- Financial code responsibilit
y centre
codes
29 Other money greater than O
- Estimated cost 0
29 Other money greater than M
- Actual cost 0
29 Total money greater than O - derivable from
- Estimated cost 0 itemized costs
Total money greater than M - derivable from
- Actual cost 0 itemized costs
30 Responsibility valid O - RC either here or
centre (collator) responsibilit in particular cost
code y centre type
code
31 Financial sign-off O
authority
31 Financial date O
authority Date
32 Manager's approval sign-off O
32 Manager's approval date O
Date
33 DEPARTMENTAL text O
TRAINING
COORDINATOR
Remarks
Field Content Lexicon Values Opt Comments
33 DEPARTMENTAL sign-off O
TRAINING
COORDINATOR
Signature
33 DEPARTMENTAL date O
TRAINING
COORDINATOR
Signature Date
34 DEPARTMENTAL USE X(10) - 6 OR
CODES fields
X(1) - 9
fields
n/a FOR USE BY Application OR
DEPARTMENTAL received,
TRAINING DIVISION Candidate
Action enrolled,
etc.
n/a FOR USE BY text OR
DEPARTMENTAL
TRAINING DIVISION
Notes
n/a FOR USE BY date OR
DEPARTMENTAL
TRAINING DIVISION
Date
n/a FOR USE BY sign-off OR
DEPARTMENTAL
TRAINING DIVISION
Initials
n/a Evaluation of text O
training
n/a Evaluation of sign-off O
training
Signature
n/a Evaluation of date O
training
Date
Appendix B - Summary of Feasibility Demonstration
Ste Description By Tool Type Tool Platform Attachment
p
1 Plan Project
Team
2 Analyze Project Groupware CADE® Groupware Windows C
Team
3 Design Project DTD Editor NEAR & FAR® Windows C, D, E, F
Content Team
4 Author Applicant Instance Microsoft Word Windows G, H, I
Instance Editor
5 Send Instance Applicant Network Novell
6 Edit Instance Supervisor Instance InContext Windows J, K, L
Editor
7 Send Instance Supervisor E-mail Internet
8 Edit Instance Coordinato Instance ADEPT Publisher UNIX M, N, O
r Editor
9 Send Instance Coordinato E-mail Lotus Notes Internet
r
10 Edit Instance Applicant Instance Author/Editor Macintosh P, Q, R
Editor
11 Archive Applicant Printing Windows P
Instance Mechanism