| |
Table of contents | Author | City | Company | Country | State/Province | Term | Interchange | |
reuse Terris, John F.
, IT Program Manager, Allen Park , Valley Forge Technical Information Services, Allen Park Michigan U.S.A.
Email: john.terris@vftis.spx.com
Web site:www.vftis.com
John F. Terris graduated from Eastern Michigan University in 1991 with a B.S. in Computer Science. After graduation, he was employed by Ford Motor Company and worked for the Technical Publication Systems group. At Ford, he was involved in the development of many DTD's, SGML conversion projects and was the Project Manager of the Ford of Europe Technical Information System. He was also active in the J2008 DTD committee and was a speaker at the 1994 CALS EXPO.
Terris is currently the Program Manager of Information Technologies for SPX Valley Forge Technical Information Services in the Allen Park office, where he is able to continue his passion for developing SGML/XML Authoring, Publishing and Delivery systems for clients such as Ford Motor Company Technical Training, General Engine Products, Harley-Davidson, Hyundai, and others. His proudest accomplishments are his wonderful marriage of 10 years to his lovely wife Tracy and his two children Austin and Kyleigh.
GEP , a wholly owned subsidiary of AM General Corporation, produces OEM 6.5L diesel engines, both naturally aspirated and turbo-charged, for use in military, automotive, marine, and various other industrial and commercial applications. With GM's technical support, GEP developed a highly efficient engine assembly operation in Franklin, Ohio, to assemble and market an improved 6.5L diesel engine to continue to satisfy the market demand. There are three main documents used by the Franklin plant to assemble engines: PCP , Operator Instructions, and PAD .
These three manufacturing documents share elements, such as torque specifications, part numbers, tool numbers, textual instructions, and assembly order. Keeping these documents up-to-date, consistent, and accurate is very difficult because there is very little time to update all three documents and they are maintained by two groups, in three formats, in two locations.
GEP's vision is to have a system where both manufacturing and product engineers could develop and maintain the information they are responsible for while reducing the duplicate effort, increasing the overall quality of the information, and minimizing publishing latency. Once all the information has been completed, reviewed, and approved, the system would be able to deliver all three manufacturing documents, each with a very different presentation and formatting style, on paper and over the Web directly to the assembly line operator at the plant.
This paper describes the steps GEP has taken to structure and develop their data using SGML/XML to put themselves in a position where they are very close to realizing that vision. It will also explore different techniques that can be used when designing systems that require:
Definition:
using the EXACT same information object (image or text) in more than one “document”
Definition:
extracting and/or formatting the same piece of information in many different ways, usually producing a different document type targeted for a different user and/or purpose
Definition:
delivering multiple document types via different media and even to different devices
Adept Arbortext Astoria Chrystal Epic This paper assumes some level of knowledge in Arbortext’s Adept/Epic products and Chrystal Software’s Astoria.
General Engine Products Inc. ( GEP ), a wholly owned subsidiary of AM General Corporation, produces OEM 6.5L diesel engines, both naturally aspirated and turbo-charged, for use in military, automotive, marine, and various other industrial and commercial applications.
Hummer Humvee GEP was born out of the need to sustain the production of the 6.5L diesel engine for military and commercial use. GM , opting for a higher horsepower Isuzu engine for some of its vehicle lines, chose to support the transfer of their 6.5L production knowledge and technology to General Engine Products, Inc. With GM's technical support, GEP developed a highly efficient engine assembly operation in Franklin, Ohio, to assemble and market an improved 6.5L diesel engine to continue to satisfy the market demand. The 6.5 diesel will continue to be the heart of the Military HUMVEE® and the commercial HUMMER® vehicle, as well as a part of other current OEM products.
Production at the 92,000 sq. ft. Franklin, Ohio, assembly facility began in July 2000, reaching full production capability in March 2001.
HUMVEE® is a registered trademark of AM General Corporation
HUMMER® is a registered trademark of General Motors Corporation
operator instructions process control plan product assembly document As GEP began implementing the assembly operation in Franklin, Ohio, the engineering group reviewed the documentation requirements and noticed some potential concerns. Three main types of documentation are used at the assembly plants: Product Assembly Document, Process Control Plan, and Operator Instructions. Each is described in the following sections.
This document, the first to be developed, is created and maintained by the product design engineers. It contains information such as torque specifications, tool numbers, part numbers, assembly notes, and illustrations/visual aids that support each step in the assembly process. This is the primary communication method between the product design engineers and the manufacturing engineers. This document is available to the assembly line operators. However, it is difficult to control, update, and deliver to the plant floor.
This document is developed and maintained by manufacturing engineers and contains information such as torque specifications, tool numbers, part numbers, quality checks, the assembly order, and brief textual instructions. This document serves as the ISO control document, which means any changes to the manufacturing process MUST be reflected in this document or GEP could lose their ISO certification.
This document, usually developed after the PCP is complete, is also created and maintained by the manufacturing engineers. It contains detailed technical instructions for each step in the assembly process, including torque specifications, tool numbers, and part numbers. This document is used for the initial training of the assembly line operators. In reality, it is rarely used and usually the last document to be updated, if it is updated at all.
It should be apparent that much of the information contained in these three manufacturing documents is the same, specifically the torque specifications, part numbers, tool numbers, textual instructions, and assembly order. Keeping these three documents up-to-date, consistent, and accurate is very difficult because
timing is critical in a manufacturing environment, which means there is very little time to update all three documents, and
the documents are maintained by two different groups, in three different formats, and in two different locations.
Keep in mind that it is very common during the manufacturing cycle of a product for part numbers or tool numbers to change or new special tools to be developed to enhance a process. Even the assembly process itself may change if the manufacturing engineers feel the changes would increase quality and/or make the process more efficient. In addition to those opportunities, GEP felt that the format of the PAD’s was a problem for two reasons:
It was not easy to find the desired information because the PAD’s were organized by UPC , which typically means nothing to the line operators.
Many of the assembly procedures for different engines were identical, with the exception of part numbers and, in some cases, tools and torque specifications. Because the PAD’s put all the variants in one document, the line operator had the extra burden of identifying the appropriate information for the engine they were assembling.
Other factors that caused GEP to revisit the assembly documentation process were:
manufacturing cycle timeCycle Time Increase – The assembly plant is divided into three lines: base engine, fuel, and trim. Each line is divided into stations. One or more line operators work at each station and have one or more sequences or steps to perform. “Cycle Time” is defined as the duration that the engine is at any given station. In other words, it is how long the line operators have to do their job. Typically, cycle times in assembly plants are one or two minutes, maybe even less. In that case, each line operator would have only a few tasks to complete, such as “select correct seat and put it in the back of the car”. The Franklin plant was going to run at about a 10-minute cycle time. Each station would have many tasks to remember and to complete within those 10 minutes. Getting the appropriate assembly instructions quickly would be imperative.
product variantsLow Volume, High Number of Products/Variants – GEP’s production requirements fall into a low volume, high variance category. Each year, GEP was planning to offer 20 or more different engine type/variant combinations. To the line operator, this meant that he or she might build a particular engine only once a week and work on four to five different engines in a day. It would be very rare for the exact same engine to come down the line twice in a row.
With all of these opportunities and factors, it was obvious to GEP that a new process of creating, publishing, and distributing manufacturing documentation was needed.
document creation document distribution document publishing multimedia publishing GEP’s vision is to have a system where both manufacturing and product engineers could develop and maintain the information they are responsible for while reducing the duplicate effort, increasing the overall quality of the information, and minimizing publishing latency. Once all the information has been completed, reviewed, and approved, the system would be able to deliver all three manufacturing documents, each with a very different presentation and formatting style, on paper and over the Web directly to the assembly line operator at the plant.
handheld deviceThe paper delivery would be customized for each engine and organized to match the manufacturing process (engine type, line, station, and steps). The electronic delivery would work in conjunction with the barcode on the engine manifest. As the engine entered the station, the barcode would be scanned. Based on the engine type and the line/station where it was scanned, the correct information would be assembled and delivered to the line operator. The delivery platform would consist of a wireless network in the plant where each line operator would have his or her own handheld or hands-free device to display the information.
The system would also feed the future GEP Service Information Publishing System as well as support a “feedback” or “correction” system for documentation errors found by the end user.
This vision is certainly not revolutionary in the publishing and/or SGML/XML industry. However, in this author’s opinion, it is not very widespread in the manufacturing industry. The vision is certainly very revolutionary to GEP and automotive manufacturing.
Once GEP shared their vision with Valley Forge, we entered into a very detailed “information analysis”. Many people in the industry call this document analysis, but I like to call it information analysis because we do not limit the analysis to just documents or publication types. We look at processes, uses of the data, relationships in the data, sources from which the data is developed, and so on. It was obvious during the definition phase of the project that 80 percent of the information elements necessary to produce the current three publication types ( PCP , PAD , Operator Instructions) existed in the PAD . For this reason, and the fact that the GEP champion of the project was responsible for PAD’s , we decided to focus on the PAD’s and let the other publication types fall out later. During the information analysis phase, we identified all the information elements and processes required to meet the following objectives:
Allow the line operator to successfully perform his or her job.
Allow all GEP administrators to effectively manage variants and revisions.
Allow continuous, easy, and seamless updates during the life of a PAD .
Allow all GEP PAD writers to locate graphics during development.
Allow all GEP PAD writers to copy an existing PAD to assist in making other PAD’s .
The result is a system called GPAS (G eneral Engine Products P AD A uthoring S ystem). GPAS was developed using customized off-the-shelf software, as shown in fig01
GPAS System Overview |
In addition to the base authoring and development system, an entire composition (publishing) module and Web-based viewer were created.
authoring environment repository Once the DTD was developed to support the information element requirements, we chose to implement the authoring environment using Adept Editor/Publisher 9.0.1 on top of Astoria 3.4 (currently being upgraded to 3.6). There were two main reasons this solution was chosen:
Valley Forge has implemented two very successful Adept/Astoria solutions for other customers in the past ( MCC and Saturn)
Many of the GPAS requirements were similar to MCC and Saturn, which allowed us to use existing code as a base.
FOSIAdept uses FOSI's and ACL scripts to customize the authoring environment. In addition to the required DTD customizations, a few “hooks” were put into the environment to integrate the repository and authoring system a little closer. Some modifications were also made to the Adept/Astoria bridge. Below are some of the “hooks”:
When the writer inserts a tag that represents a relational or “re-use” object, they are automatically presented with the Astoria “Select Object” dialog. This is the dialog that allows users to make data relational (reuse objects).
A custom ‘Save’ button prompts users to enter extra revision information and assign a version status (Draft or Release)
Hooks into the docman and the graphman allow the writers to do all their work from a central interface.
The system also supports three different views of the data. Each one represents a different publication type. Writers can toggle between multiple views and publication types in the same SGML instance and authoring session, as shown in fig02 and fig03.
PAD Screen FOSI View |
Operator Instructions Screen FOSI View |
The document manager is a C++/Astoria SDK SDK application designed to provide a simpler user interface then the Astoria Navigator. By simpler, I mean two things. First, it exposes only the features that the users need. Second, it automates and extends some features. Below is a list of some of the features the Document Manager provides:
Copy/Move – Allows users to copy objects or move them to different folders in the repository. Users can chose between three types of copies: Normal, Relational, and Unique. (fig04)
Create Child Folders – Allows users to create folders to help organize their data.
Search/Replace – Allows users to perform global search/replace for part numbers while at the same time assigning a new version to each object affected. The GPAS system currently does not interface with the GEP parts database so this feature was necessary. Since tool names and numbers are stored as separate reuse objects, the writer can update the tool object and every place it is used will also be updated.
Show reuse – Allows users to select an object and see each place that object is used. It also marks the instance that is the original object, as shown in fig05.
Copy/Move Screen |
Show Reuse Results |
graphicsThe graphics manager is a C++/Astoria SDK application that facilitates the submission of graphics into the repository. One of the requirements was that the graphics, once put into the repository, would be easy to locate. This was accomplished in three ways:
If the user knows which PAD used the image they are looking for, a simple view of that PAD would indicate the name of the graphic used.
An “intelligent” naming schema was developed. The first two characters represent the OEM , the third represents the illustration category, such as engine block or intake manifold, and the remaining numbers are a sequential four-digit number.
Metadata is assigned to each image for searching. fig06 shows the sample metadata that is captured.
Graphics Manager Metadata Input Screen |
The graphics manager prompts the user to select the illustration to be submitted into the repository, ensures the filename is correct, gives the user a preview of the image, prompts the user for the metadata, then automatically submits the illustration into the correct location in the repository.
The publisher or composition engine is able to produce paper or PDF output in three very different flavors. This is all done by a combination of FOSI , ACL , and C++ code.
Sample PAD Page |
Sample Operator Instructions Page |
Sample PCP Worksheet Page |
Web Application Framework (WAF)The GPAS Web-Based viewer is built using the VFWAF . Index information is stored in Oracle or SQL Server, while the content is pure XML. Using JSP and XSL/XSLT, desired information is delivered to the client in HTML . The viewer supports many navigation, search, presentation and user configuration features. fig10 is a sample screen shot that represents the typical tree navigation view.
GPAS Viewer Tree View |
The left side is the navigation portion of the viewer and can be hidden by the user if desired. The right side is the content portion of the viewer that displays the content that represents the selected object in the navigation pane. The hierarchy of the PAD can be seen in fig10: PAD (e.g., OHM), line (e.g., base), station (e.g., Station 10), and sequence or step (e.g., Install the Rear Gallery Plugs). Along the bottom of the viewer, you will notice the following:
User Name – Identifies the user who is logged into the system. Each user is allowed to change user-specific settings such as default layout, user interface language, and content language. User-specific notes and bookmarks are also supported.
PAD – Identifies the current PAD represented in the content pane.
Note and Set Bookmark – Allows users to set content-specific notes and bookmarks.
Print – Generates a printer-friendly version using a special XSL.
Layout – Allows the user to switch the layout or presentation style. The current layouts supported are Inline view, similar to the PAD format; Operator Instructions view (fig11); Text Only, for low bandwidth (fig12); and Expert view, which shows only the image and specification table (fig13).
Operator Instructions View |
Text Only View |
Expert View |
searchingCurrently the viewer supports three types of searches. The first is a text search. Since the data is stored in XML, users can search for specific text located in document titles only or anywhere in the documents. The second is a part number search. This is shown in fig14.
Part Number Search |
The results of each search are presented to the user in the navigation pane, as show in fig15.
Search Results Page |
The last search type is by PAD , line, and station. This is the search mechanism that allows the barcode reader to deliver context-specific data to the user based on the manifest.
At this time, the viewer has not been deployed to the plant floor. The final delivery system has not been defined. However, the GEP PAD administration team has found the viewer to be very helpful. The next section takes a look at reuse, repurpose, and repackage in more detail and describes some of the implementation strategies used in GPAS .
Before we dive into these topics, we need to define what is meant by these terms. Re-use means to use the EXACT same information object (image or text) in more than one “document”, view, or content object. Re-purpose means to extract or format the same piece of information in many different ways, usually producing a different document type, view, or presentation. Re-package means to deliver each document type, view, or presentation via different media and/or delivery systems. fig16 gives an overview of how these three concepts relate to GPAS .
R3 Overview in GPAS |
relational copyRe-use has been around for many years. Re-use can be implemented simply as external image references or in a more complex manner such as Object Oriented database repositories, where each piece of text is stored only once. A common term used in conjunction with re-use is granularity. Granularity refers to levels in the SGML/XML hierarchy. The GPAS DTD supports the following hierarchical structure:
<pad>
<line>
<station>
<sequence>
</sequence>
</station>
</line>
</pad> This represents four levels of granularity; pad, line, station, and sequence. Assuming images and other elements are allowed somewhere in the <sequence> level, one could say there were five levels. The important thing to remember with re-use is the lower the level of granularity you support for reuse, the more expensive it is in terms of support, system maintenance, repository strength, and in most cases performance. However, the more re-use you can build into your system, the more savings you can realize in the costs of translation, content development, content maintenance (which usually takes a much higher skilled content developer), and in reduced content errors. The key is to find the right trade-off and not to over-engineer the repository.
GPAS allows re-use at the station, sequence (step), tool, and image level. This is the reason there are three different copy features on the document manager. Let’s assume the following PAD exists in the repository:
<pad>YAP
<line>base
<station id=st1>content
<sequence id=sq1>content
<sequence id=sq2>content
</station>
<station id=st2>content
<sequence idref=sq1>pointer to sq1
<sequence id=sq3>content
</station>
</line>
</pad> Images and tools are always re-use objects so no matter what type of copy is performed, they will always remain re-use objects.
| Results of a Unique Copy | Results of a Relational Copy | Results of a Normal Copy |
<pad>YAP2 <line>base <station id=st3>content <sequence id=sq4>content <sequence id=sq5>content </station> <station id=st4>content <sequence id=sq6>content <sequence id=sq7>content </station> </line> </pad> |
<pad>YAP3 <line>base <station refid=st1>pointer to st1 </station> <station idref=st2>pointer to st2 </station> </line> </pad> |
<pad>YAP4 <line>base <station id=st3>content <sequence refid=sq1>pointer to sq1 <sequence refid=sq2>pointer to sq2 </station> <station id=st4>content <sequence refid=sq1>pointer to sq1 <sequence refid=sq3>pointer to sq3 </station> </line> </pad> |
Remember, another form of re-use is reusing something as a template. Who out there develops code, proposals, procedures, etc. starting with a blank page?
Re-purposing is just starting to become more then simple format changes. One of the major benefits of SGML and XML is the separation of content and presentation/format. A few years ago, as long as a publishing system could compose the same instance in at least two ways (e.g. single column and two-column) we said the system supported re-purposing. Now the re-purpose standard is higher. The challenge is to develop content management systems and standards that enable content developers to create information for many purposes, not formats, at the same time. The good systems and content development standards do not even know how the content will be used. It might appear in a marketing brochure, a service procedure, an installation guide, a training manual, an assembly procedure, and an owner’s manual or any combination thereof.
GPAS currently supports the following three publication types: PAD , Operator Instructions, and Process Control Worksheets. The content development process and DTD were designed to support the following additional publications:
XML and its family of standards have really enabled this feature. Typical target media include paper, Web Server (electronic), and CD-ROM/DVD. Platforms are becoming more diverse and, in some cases, impact the composition engine very much. They include desktops, laptops, PDA’s, Palm PCs, tablet computers and other handheld devices, hands-free devices, and even phones. The way you present information on a 21-inch desktop with unlimited bandwidth is very different from the way you present data on a phone or PDA.
The GPAS system can deliver information in paper format, PDF, and via the GPAS Web viewer. The viewer is able to detect device-specific information, which allows it to customize the view based on the browser version, Operating System, and display context.
The following are a few implementation techniques that can be used to enable re-use, re-purposing, and/or re-packaging in your system. Some of these techniques were used in GPAS .
This technique, in its literal form, displays or prints the text using the font color that matches the background. By doing this, the text is hidden. This works great for tests or forms. For tests by displaying both the questions and answers in the default color, you have yourself an instructor’s answer key. Display the questions in the default color and answers in the background color and you have the test itself. Depending on what type of information you design into the form, you could make a blank form, a sample form, or even a training guide from the same instance. This technique does not work well when pagination is dependent on the existence of text.
In profiling, the style and even content of a displayed document is changed based on the value of elements and/or attributes and the profile selected. This technique can be applied to both SGML/XML elements and attributes, or to the combination of the two.
In the element implementation, the composition engine is developed to use a subset of the tags depending on the purpose. Entire constructs or hierarchical levels may be included or excluded. Elements that are used may also require different processing depending on the purpose.
In the attribute implementation, usually one common attribute is added to every element. The value of the attribute determines how and when the content should be used. Profiling this way can be used to identify the following:
Effectivity – What specific configuration (feature set, language, market) must be satisfied before this content applies.
Delivery Platform – There are many things you can do in an electronic presentation that you cannot do in paper. There are also many things you can do with computer-based diagnostic equipment that you may not be able to do manually.
Purpose – If the purposes (publication types) are finite and defined, this may be the most effective way of denoting what content goes with what.
User skill or knowledge level – The information you give users with 20 years of experience may be different from what you give beginners.
late-link bindingI have found this technique to be the single most powerful technique I have ever used. I first implemented it in 1991 and have used it ever since. The easiest way to describe it is with a very common example: DNS . DNS resolution is one implementation of late-link binding. When you enter the URL , somewhere that URL is mapped at run-time to an IP address. As long as the DNS mapping between URL name and number are up-to-date, the IP address associated with can be changed with no impact on the end user.
With late-link binding, there can be many levels of indirection. The following table illustrates this idea.
| Level of Indirection | 1 | 2 | 3 | 4 |
| IP address identifies a physical machine | URL | Value in your local host table | Query or search on Yahoo |
With each level of indirection you risk being directed to multiple destinations. In some cases that is OK, but in the ideal world you design the system and content to resolve to exactly where the user wants to go.
What is so special about late-link binding? With it you are able to maximize re-use and re-purposing because the content does not have to be re-created just because an image is modified or the external reference is different due to the content’s context. Lesson numbers, section numbers, steps and items in ordered lists do not have to be rewritten just because they are first in one context and last in another. Yes, auto-number features in your composition engines are another form of late-link binding.
One late-link binding technique involves implementing a “smart” referencing ID schema. I sometimes call this a “promise ID”. This technique facilitates late-link binding, and also allows content that is dependent on other content to be developed concurrently, including the inclusion of references to content that is not yet developed. By having the “promise” that the content you need is at a predefined address, you can include your reference even if it has not been created yet. Here are some tips in developing such a schema:
If possible, develop a master outline that contains all possible hierarchical nodes or branches.
Create the referencing ID by concatenating the ID's from each level in the hierarchy.
Find some way to separate or denote each level of the hierarchy within the schema. This will pay big dividends later in case a referencing error handler is necessary. I will let the reader think about that.
The ultimate late-link binding schema in my mind is one that implements HyTime addressing schemas such as queryloc. In this implementation, instead of referencing graphic IDs, writers encode queries based on some standard such as XPointer, XQL, or SQL, or some custom language better suited for the writer. As with all late-link binding implementations, the late-link binding engine interprets the addressing schema, applies current context information, and resolves to the correct information object.
pre-delivery transformations request-time transformations run-time transformations Re-Use, Re-Purpose, and Re-Package techniques are performed at three different points in the delivery cycle. First there are Request-Time Transformations. These transformations are done on the server side only and usually require some sort of XSLT, COM, Java, Perl, Omnimark, or ASP/JSP process to be done prior to delivering content to the user. The results of the transformations usually depend on one or more factors such as user preferences (skill level, knowledge level, language, etc.), user selections, current context, and client browser. If currency of the data is the most important factor and your system supports a very high level of reuse, repurpose, and repackaging, your delivery system will need to implement these transformations.
Next there are Run-Time Transformations. These transformations are limited to presentation styles and some late-link binding referencing resolution. They do not provide the power of the Request-Time transformations but are much faster. The transformations can be done by server- and/or client-side XSL, CSS, or DHTML. They can also be implemented by custom browser extensions using ActiveX, Java, COM, etc. When people describe solution that support “style-sheet switching”, they are typically describing these type of transformations.
Finally there are Pre-Delivery Transformations. This implementation provides the fastest solution possible. However, it requires that all possible variants of the data be defined prior to delivery. Because each of these variants is prepared in advance as a separate file, this method requires more space on the server than the other methods. Most often, you implement Request-Time transformations for a defined set of variants prior to publishing on the delivery system.
As GEP’s vision of reuse, re-purposing, and re-packaging is developed and implemented, new technologies also mature and can be utilized. Some of these are described below.
SVG Scalable Vector Graphics
SVG
brings XML to vector graphics. The fact that
SVG
is expressed in XML means that
SVG
graphics can be just as dynamic as XML text. Also, the fact that it supports scripting increases the flexibility.
Extensible Metadata Platform XMP XMP has been developed by Adobe Inc. to provide Adobe applications and partners with a common, Standards-based metadata framework that standardizes the creation, processing and interchange of document metadata. The XMP software development kit allows programmers to integrate XML metadata packets within application files. These packets can be used in metadata exchange and resource discovery, creating opportunities for digital rights management, job processing, workflow automation, and other areas of production where metadata is critical.
XSL XSL Formatting Objects XSL-FO XSL-FO is an XML-based markup language that lets you specify the pagination, layout, and styling information that will be applied to your content. XSL-FO markup is complex and verbose, and there are currently few tools to process it effectively. For these reasons, XML-FO has been slow to catch on. Will we ever get to the point where one “style-sheet” will really support multiple output formats? Will XSL-FO be the technology that gets us there?
Analysis of GEP’s business needs helped define a more efficient documentation system, where information could be written once the re-used for multiple engines, re-purposed in multiple manual types, and re-packed for several delivery platforms. Applying a known technology, SGML/XML, in an existing industry has been fruitful. As new technologies appear, their applicability to the problem of document distribution can be evaluated.
GEP’s vision is to have a system where both manufacturing and product engineers could develop and maintain the information they are responsible for while reducing the duplicate effort, increasing the overall quality of the information, and minimizing publishing latency. The techniques outlined in this paper are helping GEP get closer to this vision.
First of all I would like to thank Jeff Dowell for his never-ending support and confidence in Valley Forge and me. Without that, this project would not be where it is today. I would also like to thank my mentor Denise Feil who taught me everything I know about SGML/XML and publishing. I would also like to thank my colleague Janet Erickson. Without her endless technical and non-technical edits, this paper would not be fit for publishing.
Finally, I want to especially thank my family for all their support and love they have given me over the years. Tracy, Austin, and Kyleigh, I love you.
| |
Table of contents | Author | City | Company | Country | State/Province | Term | Interchange | |