| Extranet SGML editorial system for encyclopaedias | Table of contents | Indexes | Hypermedia Database | |||
| Elovainio Kimmo |
| Kunz Jürgen |
DOCSTEP - Technical Documentation Creation and Management using STEP |
Abstract: |
| Good quality documentation is identified by manufacturing industries as an important asset to push their products on the market. More and more companies sell their products all over the world and are requested to provide localized product documentation. In this context, controlling - through creation, translation and maintenance - the consistency of huge documentation produced in different places, on different tools by people with different skills is a real challenge. Moreover, reducing the effort of document creation and management by help of powerful software tools, will cut down the costs of complex products significantly. |
| Goal of the DOCSTEP project, which is presented here, is the usage and integration of beneficial technologies and standards for product modeling, natural language processing and document management in order to improve the process of product documentation creation and management. The DOCSTEP approach is based on the integration between the product data standard ISO 10303 STEP and the documentation standard ISO 8879 SGML. It is the aim of the DOCSTEP project to develop an Authoring System where documents are based on the generic model of the product, with language independent semantic layer plus integrated tools allowing the end user to access document/product relevant information efficiently. |
| The presentation shows the current results of the DOCSTEP project. DOCSTEP is promoted in the context of the Telematics Research Program (Language Engineering) of the Commission of the European Community. |
Introduction |
Problematic of documentation creation and management |
| The components of large machinery are oftendistributed manufactured in geographically different places, delivered separately and assembled at the customer site. Also the manufacture of the product components and the production of related documents are distributed between the production units. Typically the customer's documentation is produced in a multisupplier environment which in practice means that the documentation is supplied by several subcontractors and consultants. |
| Geographically distributed documentation shows the importance of common requirements, an understanding of the needs, an awareness of the current situation and cooperation between the different documentation units in planning, manufacturing and delivering customer-specific products. To assemble, manage and deliver the data from different sources to different endusers, the predefined and commonly accepted methods are needed to communicate and to manage the data flow. |
| One aspect of the information management of heavy industrial products is thelife-cycle requirement . The life-cycle of industrial products is much longer than the service life time of information management systems. This means that product-related information (e.g. documentation) must be accessible, usable and processable during the whole life span of the product. |
| Themultitude of non-standardized documentation formats used by documentation suppliers complicates the production and assembly of customer documentation. A common format for document production and delivery simplifies and speeds up the documentation process. This means that the number of documentation formats equals to the number of filters which are needed between the formats. A widely accepted, standardized and reusable documentation format simplifies the transformation and assembly of multisupplied documentation. |
| The manufacture of large machinery is complicated because there is a great choice of product variations and numerous component alternatives. Each delivery is an independent and an individualized process. The configuration management of the delivered products shows the complexity of themanagement of product-related documentation . The management of the huge product variation documentation, including revisions is a challenging task. |
| Coherent and modular documentation methods are needed for the controlled production of a huge number of document contents to develop new products. Links are needed between the documentation and the product variations to assemble the customer's products and to collect the documentation for the delivery to a customer. The question is how the documents can be managed in product planning, product development, document production and document assembly. Sophisticated information retrieval methods are needed, with product-related descriptive information stored in the documentation. |
Background |
| The problematics of product-driven documentation has being reported in the pilot-project"DOCUMENT MANAGEMENT BY PRODUCT MODELS" . The project was carried out by VTT Information Technology, Multimedia Research Area between 1995-96. The project was financed by the Technology Development Centre (TEKES), Valmet Corporation, 12 other Finnish companies in engineering, paper, shipbuilding, crane, power plant, mining and automation industries, and some Finnish Defence Establishments. |
| The pilot-system of the project was carried out in close-operation with Valmet Corporation. The problematics of product modelling and product-related documentation was presented in a large industrial manufacturing environment as well as the models to describe and produce product-related data. The documentation model, presented in the project, was achieved with the structured information modelling techniques introduced in the SGML standard. The product modelling was based on an object-based approach to implementing STEP constructions. A practical, graphics-based prototype tool, STEPDocs was also presented for managing product structures in a close relationship with SGML documentation. The project covered also the interoperability issues between STEP and SGML. |
| The result of theFODATEC project, a european research project funded in the framework of the ESPRIT programme, was the development of an integrated system prototype for the creation, storage, and exchange of product documentation based on ISO 8613 Open Document Architecture (ODA). RPK was involved in the development of a software component to incorporate STEP compliant product data representations into documents. The FODATEC project was performed between 1990 and 1993. |
The DOCSTEP project |
| The DOCSTEP project is partially funded by the Commission of the European Communities in the context of LANGUAGE ENGINEERING in the TELEMATICS APPLICATIONS research programme . NOTE: |
| The TELEMATICS APPLICATIONS research programme is supported under the European Union fourth framework programme. It has a budget of 898 Million ECU. It is a user-driven research programme, focusing on the societal applications of information and/or communication technologies. |
| The aim of LANGUAGE ENGINEERING is to facilitate the use of Telematics applications and to increase the possibilities for communication in and between European languages. Research and Technology Development (RTD) work focuses on pilot projects that integrate language technologies into information and communications applications and services. A key objective is to improve their ease of use and functionality and broaden their scope across different languages. |
| Goal of the DOCSTEP project is the usage and integration of beneficial technologies and standards for product modelling, natural language processing and document management in order to improve the process of product creation and management. |
| After analysing the problem area in a one-year feasibility study in 1995, the second phase of DOCSTEP is now focusing on the implementation of a software system to reduce the known problems in product documentation. |
Approach |
| The aim of DOCSTEP is to provide the means to bridge the gap between the document and its content . Accessing relevant document resources directly and efficiently is therefore a key requirement. |
|
| The project develops an Authoring System with the following characteristics: |
| As far as possible the authoring environment will make use of commercial tools. The overall architecture of the DOCSTEP system is shown in . The DOCSTEP system will be integrated and validated in the documentation process at the user sites of AIRBUS Industrie and Valmet Corporation. |
 |
Project Profile |
| The DOCSTEP project was started in November 1996 and has a duration of 2 years. It has an effort of 194 Manmonth respectively a budget of 2,75 Million ECU, from which a share of 55% is funded by the Commission of the European Communities. |
| The DOCSTEP consortium gathers five partners having competence in the domains of Natural Language Processing, Product Data Management and Document Management. The partners are the following: |
Technology Background |
The Product Model of ISO 10303 STEP |
| ISO 10303 STEP PRODUCT DATA REPRESENTATION AND EXCHANGE is an International Standard for the computer interpretable representation and exchange of product data. Product data represents information about a product in formal manner suitable for communication, interpretation, or processing by human beings or by computers. The objective of STEP is to provide a neutral mechanism capable of describing product data throughout the life cycle of a product independent from any particular system . The nature of this description makes it suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases and archiving. |
| The core of STEP consists of a collection of conceptual models which describe the content and structure of product data items. These data models, also called information models, are formally specified in the modelling language EXPRESS. |
 |
Structure of STEP |
| ISO 10303 STEP is organised as a series of parts, each published separately. The parts of ISO 10303 fall into one of the following series : |
| The0-series contains introductory documents describing the goal and structure of STEP. The first document of this series is ISO 10303-1Overview and Fundamental Principles . It gives a general introduction to STEP and defines some basic terms. |
| The10er series (Product Data Description Methods ) comprises documents on the specification methods, which are applied to define the information elements (entities) in the STEP standard. |
| In the20er series (Implementation Methods ) unambiguous rules were specified to map the information models to an implementation. Implementation forms are e.g. Physical File, Standard Data Access interface. |
| The30er series (Conformance testing methodology and framework ) describes methods to check the conformance of implementations. |
| The generic resources contained in the40er series (Integrated resources: Generic resources ) define the application-independent information models. Together with the100er series (Integrated resources: Application resources ) they build the so-called integrated product model. |
| The documents200er series (Application protocols ) comprises information that specialise the integrated resources to meet the information requirements of specific applications. The specialisation is achieved by selecting the appropriate integrated resources, refining their meaning, and specifying any appropriate constraints. The DOCSTEP work is based on AP214 CORE DATA FOR AUTOMOTIVE MECHANICAL DESIGN PROCESSES. AP214 is described more detailed below. |
 |
| Abstract test suites (300er series) contain the set of abstract test cases for application protocols to support the conformance requirements. Each abstract test case provides an implementation-independent specification of the actions required to evaluate part of one or more conformance requirements. |
| Application Interpreted constructs (500er series ) provide components of the integrated resources for the usage in multiple application protocols. |
AP214 Core Data for Automotive Mechanical Design Processes |
| The development of AP214 was initiated by the automotive industry in order to provide a STEP-based solution for their problems in exchanging data either internally between the departments or externally between car manufacturers and part suppliers. Moreover AP214 based data storage is a step towards more independence with respect to application system. |
| The scope of AP 214 is focusing on the development process of mechanical parts and assemblies of a vehicle and the tools to manufacture those components. AP 214 covers data to manage information about product definition, configuration control, process plans, change processes, release/approval, shape representations, technical draughtings, product document references, simulation data, surface conditions, and tolerances. |
 |
| The analysis at the beginning of the DOCSTEP project turned out, that AP214 fits best for the product model requirements specified in the Airbus and Valmet user environment. AP214 provides a powerful configuration control mechanism which is able to manage complex product structures of aircraft and paper manufacturing machines. |
| The standardisation process of AP214 is currently ongoing. It is planned to have a draft international standard version of AP214 end of January 1998. Nevertheless the important part of the document is already stable. |
Product Documentation in the Product Model of STEP |
| Product documentation is not completely integrated in the current version of STEP. Examining the current APs, e.g. AP214, one can find out that there exists a very simple mechanism to reference documents in the outside world of STEP. This mechanism is independent of the document format. |
| On the other hand there is a fundamental need to integrate product data and document data more closely, in order to avoid redundant information, which makes it difficult to keep documents up-to-date. So far two approaches have been developed to integrate document and product data, the Technical Publication Information Model and the SGML_STRING concept. |
The Technical Publication Information Model (TPIM) |
| The TPIM allows for modelling hierarchical structure, to represent the content and structure of product documentation in a STEP database . In order not to reinvent a new document representation standard those structured elements are containers, which may incorporate document data compliant to existing standards like |
| These standards permit the logical structuring of documents and support the intelligent identification of text, as document content at any level of granularity. References between document components other product data entities, like 3D shape, can be established. |
| The TPIM is a very generic approach. Details of the approach have to be further developed, e.g. the way of referencing product data including data transformation for publication purposes. |
| EXPRESS-G |
| NOTE: |
| EXPRESS-G is the graphical representation of ISO 10303-11 EXPRESS. |
 |
| Work on the development of the TPIM has been interrupted, since the more practical approach of SGML_STRING was introduced. |
The SGML_STRING concept |
| The basic idea of the SGML_STRING concept is to replace the STEP string type, which is used in almost every STEP schema, by a more powerful extended construct , which allows for specifying SGML compliant information. The content of the SGML_STRING is a string of character codes. These character codes may include the character codes that SGML recognises as defining mark-up. The SGML_STRING references a DTD fragment, which defines any of the mark-up codes found in the SGML_STRING content. It also provides a reference to SGML declaration and if necessary to HyTime processing instructions. |
| By minimal effort, the SGML_STRING enables existing STEP schemas to handle SGML compliant data. But it will not provide capabilities to compose those SGML components to a hierarchical document structure. It only provides a SGML container construct. |
 |
The Document Model of ISO 8879 SGML |
| The Document Model of ISO 8879 SGMLSGML is defined as the ISO 8879 standard "Information Processing -- Text and Office Systems -- Standard Generalized Markup Language (SGML)". The standard was released in 1986. |
| SGML is a system-independent metalanguage. SGML can be used to describe and create documents that are not dependent on any hardware, software, formatter, or operating system. The SGML data can be produced, used and distributed independently between different systems and applications that conform to this standard. |
| SGML defines a syntax and rules for describing document data. This is implied in a document type definition (DTD) which describes the data representation components, such as the elements and their relationships. Each individual data element can be recognized and named separately, which guarantees the consistency of the data and its controllability. |
| The document type definition is a structural description of the document data. The DTD does not contain any information about how the data must be presented in the media or how it must be processed by the information systems. Its purpose is to serve as an instruction for document creators, e.g. to show which structural elements could be used and in which order. |
| As a descriptive coding language, SGML separates the logical structure of the document from its presentation. DTD defines the logical structure of the document. It tells that documents produced according to the same structural description conform to each other. There are content-oriented or layout-oriented document type definitions, depending on the granularity of the information and on the naming rules used. |
The Hyperlink Document Model of ISO 10744 HyTime |
| HyTime is defined as the ISO 10744 standard "Hypermedia/Time-Based Structuring Language (HyTime)". The standard was released in 1992. HyTime was developed as a result of the work on developing Standard Music Description Language (SMDL). The development of HyTime was based on the idea of independence of media. Also one main target was that producers of information could reference to other information easily. It will say that the new information could be integrated into existing information without changing the existing one. |
| HyTime is an extension to the SGML standard and an application of it. It means that HyTime is modelled by the syntax of SGML and all the properties and structures in a SGML document are inherited to a HyTime document. It defines models for structures of hypermedia documents. |
| HyTime supports a model of an integrated open hypermedia information system where hyperlinking could be implemented between any objects independently on presentation, location and timing of objects. This is possible if any object could be referenced without modifying it. An object needs not know to be a target of a link. |
| Any SGML document could also be a HyTime document. HyTime defines structures e.g. for linking objects in the same document or between documents. The linking mechanism could be direct or indirect. The document type definition requires that SGML element types acting as HyTime element types must be declared with pre-defined structures. This is done by architectural forms which are classified into six modules: Base Module, Hyperlinks Module, Measurement Module, Location Address Module, Scheduling Module and Rendition Module. Architectural forms describe elements' content model, attribute lists and semantics. |
Linguistics |
| In many industry fields the market area of products is wide-spread across all over the world and the production of product components is distributed in several countries. This means in many cases that the production of documentation is localized and produced with local language. However the product documentation must be delivered in customer language. This increases the dimensionality and complexity of document management like version control. It also requires sophisticated linguistics tools for producing translations from master documents. |
| About 150 organizations - private companies as well as universities and state-run research institutes - in Europe are actively concerned with the development of Natural Language (NL) resources and linguistics tools. |
| Different linguistics tools provide services for producing control language. Writing in a controlled language means using a consistent and clearly defined set of terms as well as applying predefined grammer rules. Tools have not been an integrated part of word processing tools, they have been more batch oriented tools - run at the time they are called. If they could be more on-line applications they learn the writer e.g. in selecting correct terms, in spelling, in checking a grammar or in producing translation. The tools are offering services like text proofing (spelling correction, grammar checking), hyphenation, translation and terminology management. In order to achieve a good quality of natural language processing capabilities the tools must support a high level of morphological and syntactical analysis. |
| In the DOCSTEP project one objective is to provide authoring aids to increase the language quality of documentation and increase the relevance of document content and consistency. |
Application Scenarios |
| In the DOCSTEP project there will be two applications which share the common understanding of modelling processes of the product definition, product configuration and product documentation creation and management. The application area targeted by DOCSTEP covers the creation and management of product documentation in the industry sectors where severe constraints in terms of quality requirements impose a structured approach to define the documentation production system according to multiple factors: link with product data and product data management, controlled language, workflow management. |
Valmet application |
| The goals of the Valmet application are to accelerate the development of Valmet's customer documentation processes, especially the production and maintenance routines of the maintenance and operating documentation in the multivendor environment. In addition to that the goals are to introduce new methods and applications to maintain distributed documentation production and to compile customer deliveries more efficiently. |
| The goals of the Valmet application belong closely to the concepts of a product model-based and a construction of an information model-based documentation processes. In the application development special attention is put on the content-related document modelling and hyperlink-type relations within and between the documents. The results of the application specifications could act as a basis for the further development work of the subcontractor-supplier-customer documentation chain. |
| One problem in the documentation process is that several different units within a company as well as outside subsuppliers are usually involved in major machine and plant deliveries. The problem here is respective customer documentation which has to be collected from a number of contributing units and subsuppliers and supplied to the total customer product delivery. At present, there is no systematic method in use, to compile customer documentation from various sources of information. |
| The manufacturing of paper and paper finishing machinery is mainly an export industry. That is why the documentation has to be translated into more than 20 customer's languages. This increases the volume and the complexitiy of the documentation which must be managed. |
| As the life-cycle of heavy machinery products is well longer than the lifetime of a typical computer solution there is a definite need to keep the documentation available, usable, editable and revisable throughout the product lifetime. This concerns the initial creation of documents, revisions done by the manufacturer and revision work carried out by the end user. For example the typical life-cycle of a paper machine is over 20 years. The customer documentation needs to be kept accessible and editable during the whole lifetime of products. |
| The customers' requirements lie mainly in managing and revising the documents once the product, e.g. part of a paper machine or a revision to an existing machine, has been delivered. Current problem area is the multitude of formats that different constractors use to produce and maintain the documents associated with their products. Industrial products such as a paper machine require periodic revisions and the documents have to be kept up-to-date. |
Airbus application |
| In the scope of the Airbus Concurrent Engineering (ACE) program, AIRBUS Industrie has launched the Airbus Technical Information System (A.T.I.S.) project in order to decrease the costs for Technical Information production. The Airbus application scenario covered explicitly in the DOCSTEP project is focussing on a document called Technical Information Document (TID). |
| The TID is part of the customer documentation when an aircraft shows differences with the ones of previous deliveries and when these differences in the definition of the aircraft have an impact on the procedures described in the documentation of the aircraft. In this case all the elements necessary to update the related procedures - operation, maintenance, etc. - are listed under the description of the difference. To write the TIDs, the technical authors use different source documents. For the description, the technical author uses information like graphical representation of product parts or textual descriptions created by design office engineers or technicians. In today's environment there is mainly a paper-based information flow between technical authors and engineers. Technical authors re-input the paper-based information in the TID system by hand or by scanner. |
| Moreover there is a need to adapt and check the received textual information since the engineers, who have authored the text, are typically non-native English writers, who master the English language imperfectly. Furthermore the final text has to be compliant to the rules of AECMA |
| NOTE: |
| AECMA (Association Européenne des Constructeurs de Matériel Aérospatial). Simplified English. The production of the TID is therefore concerned with terminology consistency and Controlled Language. |
Requirements |
| Regarding the two application areas one can extract a set of common requirements. |
Product Configuration and Documentation |
| In many industries product configurations are managed with varying success. The increasing demand for customized products sets great requirements for the production and management of product configurations. Existing product model configurations and product subpart descriptions should be used to define a new customer product configuration or to change the parameters of an existing configuration. |
| The choice of product configuration should be described in a basic product model. The basic product model contains all the configuration alternatives with descriptions of the relationships between the subassembly parts. These relationships describe the connections within an assembly model in terms of connectivity. The design of a new customer product model is based on a basic product model which controls the decision process to make up a new customer-based model. |
| The management of the customer documentation should be connected with the customer-based product configuration. The management of the product configurations and the management of product documentation are typically separate processes without any common links. |
| It will say that each part of the customer-based product model should have a connection with the corresponding customer documentation. This approach brings the planning of the product configuration closer to the customer documentation management and production processes. |
Reuse of Product Data |
| The possibility to reuse product data, it will say manufacturing and engineering data, within the documentation should be possible. This feature falls under the objectives of linking the product documentation structure with the product structure or somehow manage the linking mechanism between the product structure and documentation structure. |
Storage of document data in the product model |
| During the design phase of a product a lot of documentation relevant information and knowledge is available. Currently this knowledge is not explicitly documented by the product designer. Document authors are therefore forced to contact the design department in order to retrieve necessary information. |
| Creating methods and tools which allow the product designer to explicitly store documentation relevant information in the product model on the fly will increase the efficiency of document authoring. |
Terminology Management |
| The terminological information units should be organized in order to allow for the identification of, on the one hand, conceptual anchors to attach the information referring to the product definition, on the second hand, anchors to attach the linguistic information used by the language tool, e.g. morphological and syntactic information for lexical items of each language. |
Controlled Language Checking |
| Controlled language tool has been seen as a key natural language application that could benefit from the terminological information and the product models to check not only the correctness of the morphology and syntax of the text, but also its semantic consistency. |
Workflow Management |
| A workflow management system enables the routing and distribution of information among related tasks in a business process. The tasks included in a workflow system are those activities that employees perform in doing their jobs. |
| The need to integrate the documentation system with the workflow is vital. This should provide the machinery designers an automatic connection to the documentation system as an elementary part of their design work, also for maintaining the documents while upgrading their products. Also connections to the sales, manufacturing and customer project management, e.g. tools should provide more automatic follow-up between those essential functions of the organization and the corresponding documentation phases, production, maintenance and delivering. |
The Concept of the Authoring system |
Basic approaches |
| The DOCSTEP concept is based on three major approaches. First the interoperability between SGML and STEP. Second, the product model driven documentation process. And third, the use of product model data as a linguistic resource. Those three approaches are described in the following sections. |
Interoperability between SGML and STEP |
| The term "product model" refers also to a standardized system of structuring product information for digital data transmission and processing with application software. There are two generic models for describing product-related technical information. The ISO 10303 STEP was developed to describe product data contained in the product model, while the ISO 8879 SGML was designed for structured information. Until now the relation between the two models has been studied very little, even though its significance has been acknowledged on several occasions. |
| The benefits of the coexistence of STEP and SGML data are obvious. First of all, STEP is better suited for describing the product model, configuration and product representation and version data than any other standard. SGML is the only standard to describe the structured document data in a consistent way, that is to say in a usable form. For example SGML-based encoding is more suitable for the production of operating and maintenance documentation and STEP is preferred for representing product data and its structure. |
| The product model for complicated equipment is often well defined. With the product model data and applying the methods for processing structured documentation, it is possible to produce delivery-related customer documentation faster and more economically. |
| Product design and documentation have often been two separate processes which do not operate together. In many cases different persons are involved in these processes. The product data is produced during the product design and production. Generally the product documentation is associated to the data that is used during the product operations and management. This data is produced by the documentation people on the basis of the design and manufacturing data, e.g. the design people produce the operating and maintenance data, but the dedicated documentation people interpret and translate it into a form suitable for the customers. |
| The two models for presenting product data, STEP and SGML, have interconnections. For example, while operating with the product there is sometimes a need for, in addition to the enduser documentation, information about the product assembly or dimensioning. By integrating the STEP and the SGML data, the whole product-related data -- the design, manufacturing and documentation data -- is accessible, usable and under control in a consistent way. |
| In practice the SGML and the STEP data could be interchanged in the applications supporting the respective standards. For example, the assembly information described in the STEP-compliant environment could be transferred to the SGML-based technical documentation. The technical requirements for the implementation and for the necessary data abstractions are being worked out by the ISO working group ISO/TC184/SC4/WG3/T14 . |
Product model driven documentation process |
| In the DOCSTEP approach, the structuring depends on how a product can be divided into separate, physically realizable parts. According to the structure of product parts, the documentation e.g. the operating and maintenance documentation, can be divided into logical and consistent components. A documentation component covers only the scope of one product part. Therefore it can be produced without any knowledge of the surrounding system or of the connections to any other products. The document component will be linked with the respective product part. |
| Starting from the basic product model, which consists of all possible product configuration alternatives (alternative or optional parts), a customer specific configuration of the product will be specified, which extracts a set of product parts from the possible set of parts. Evaluating the links from the selected product parts to the document entities will compose the documentation package for customer specific product configuration . |
 |
Product model and linguistic resources |
| A basic requirement of terminology management in document creation is accessibility to the basic components of terminology. The author must be able to navigate through the network of concepts (represented by terms) and corresponding explanations. Until now this has been established by analysing existing documents in the relevant field of application or in consultation with experts. The product specifications conforming to the STEP model represent an additional source of terminological information. The STEP model is a source for domain knowledge. |
| From a technical point of view, the products specified therein can be broken down into assemblies and individual parts. And from terminological perspective, these components can also be interpreted as concepts. By the way of example, shows that the product "car" is made up of various components, each of which is related to a terminological concept. |
 |
| Thus the product specification conforming to the STEP model can on the one hand be used to present logical connections (in the example in there is a close relationship between rim and wheel), and on the other hand it conveys descriptive information (the graphic representation, for example) to explain a terminological concept. |
Technical Solutions and Authoring system |
| The authoring system allows to access the components integrated in DOCSTEP. Main components in the DOCSTEP architecture are : |
| Thedocument editor , to produce SGML-compliant, structured documents. The development of the document editor will be based on a commercial editing tool. The commercial tool will be extended in order to interact with the product data management system, the workflow management system and the linguistic tools of the authoring environment. The document editor will be closely integrated with the document data repository. |
| Theterminology management system supports the implementation of terminology rules. Furthermore it is a resource for the controlled language checker. The user of the DOCSTEP system can retrieve explanatory information about the meaning and usage of technical terms. The terminology management system will access the product data management system to extract terminology-relevant information from the data model of the product. |
| Thecontrolled language checker facilitates the production of documents against the terminology rules and help further translation of the documents. It uses resources of the terminology management system. |
| Theproduct data management system manages the product database. It provides a user friendly graphical interface to visualize and navigate the structure of a product including assemblies and variations. It gives access to descriptive information about a product component and allows to link product components with document components and vice versa. External applications will access the product data management system via an application programming interface (API). The Product Data Management System will be developed based on the ECCO |
| NOTE: |
| ECCO (Express-C Compiler). The ECCO- Toolkit is a development of RPK, University of Karlsruhe. -Toolkit . The main goal of the ECCO-Toolkit is to reduce drastically the effort needed to develop IT applications whose conceptual models are specified in EXPRESS. ECCO consists of a set of tools that supports the development and user-oriented evaluation of STEP Application Protocols as well as the development of computer applications based on these ups. |
| Theworkflow management system routes and distributes the information among related tasks in the documentation process. It is the backbone of the authoring environment. |
| TheSGML product documentation repository stores the documentation components. The documentation is produced against a document type definition, and the repository uses this information while storing, versioning and otherwise managing the documentation. The document editor is warmly integrated with the document repository by offering adequate functionality's, e.g. for checking in and out document components, attaching versioning information. |
| TheSTEP product database handles the product data. The product data will be represented in a format based on AP214. Nevertheless the data model of AP214 has to be extended in order to fulfill the documentation requirements. For referencing document components it must be capable of dealing with bi-directional links from and to the document database. |
| All the components will be integrated in the DOCSTEP authoring environment during the project. There are also application specific requirements regarding in the selection of software solutions. |
Conclusion |
| The DOCSTEP projects aims at improving the process of product documentation creation and management. It is the goal to increase the quality and in parallel reduce the costs of the documentation. The basic idea of the DOCSTEP approach is to integrate product documentation environment and the product modelling environment with respect to document content and workflow. |
| Although the development is driven by the two DOCSTEP users and their requirements, the DOCSTEP results will be usable for a broad range of users, since the DOCSTEP software/concepts are based on a modular approach. A first software prototype will be shown end of 1997. The final DOCSTEP system will be ready end of 1998. |
| The DOCSTEP developments are validated in two user environments. Furthermore DOCSTEP is establishing a user group, which will serve as a platform to distribute the results gained. Moreover the user group is a forum to discuss today's problems in documentation creation and management and to exchange experiences. On the other hand the user group will give broad-ranged users feedback to the DOCSTEP developers . If you are interested becoming a member of the user group, see the DOCSTEP Webpage (http://rpkhp9.mach.uni-karlsruhe.de/Kunz/DOCSTEPII ) for details. |
BIBLIOGRAPHY |
| Extranet SGML editorial system for encyclopaedias | Table of contents | Indexes | Hypermedia Database | |||