T184/Sc4/WG3/T14 Product Documentation Group

Minutes: Grenoble meeting

October 23-27, 1995

Attendees:

Hélène Herbault, Aerospatiale, FRANCE
Jürgen Kunz, University of Karsruhle, GERMANY
Helium Mak, National Research Council, CANADA
Nicole Modiano, Cap Gemini Innovation, FRANCE
Hugh Tucker, Documenta ApS, DENMARK
Juerg Walser, J. Walser Consulting, SWITZERLAND


Meeting Activities

The meeting was opened on Monday, Oct. 23, 1995 by Hugh Tucker, deputy chair of T14. The following activities, guests, and presentations (not ordered chronologically) followed during the meeting:

J. Fowler

Discussion of STEP architecture and T14 positioning

H. Herbault

Presentation of ATA 2100 DTD and STEP model.

N. Modiano

J. Kunz

Presentation of DocSTEP

H. Tucker

Presentation of the T14 White paper

B. Warthen

Presentation of SC4 and WG3 work and related topics.

G. Ziolko

Presentation and discussion of Technical Data Packaging proposal.

ATA 2100

Hélène Herbault presented the ATA 2100 DTD and STEP model that had been produced by Shiang-Yu Lee of Boeing. The presentation described the maintenance engineering data model and was discussed in the group as a pragmatic example of the needs of industry. Aerospatiale is in a major move aimed at bettering the quality and enhancing the functionality of technical documentation. Co-operation and participation with ATA is central to the project plans in Aerospatiale.

It was a very good exercise for the participants to work with the STEP model and the corresponding DTD. (The participants of T14 are traditionally either experts in documentation or STEP and an example of the intersection was therefore very enlightening.)

The participants felt that working with the example was very beneficial and that if possible that it should be continued and expanded. It was pointed out that the documents were difficult to comprehend without more explanation, particularly of the intentions behind the model. It was thereby resolved to ask Shiang-Yu Lee, who is an active member and frequent contributor to T14's work, to present the ATA 2100 Data Model at the Dallas meeting.

DocSTEP

Jürgen Kunz presented the DocSTEP project briefly on the first day of the meeting. It was decided to continue with a more in-depth presentation on the second day.

Nicole Modiano of Cap Gemini Innovation presented the DocSTEP project. DocSTEP is a proposed project in language engineering under the Telematics Sector (a European Union research program). DocSTEP is aimed at enhancing the environment of the production of documentation for technical writers, especially those whose tasks include documentation in "foreign" languages and for translators of technical documentation. The project will use the STEP APs and IRs concepts and terminology to construct a semantic base where from users (technical writers) can retrieve background information e.g., from EXPRESS models, to help in explanations.

T14's White Paper

Hugh Tucker presented the latest version of T14's White Paper:

During the past year the T14 group has been working on a white paper to express the interest areas and to point out some of the technical requirements that the group felt were necessary. This paper is intended for distribution to members of the STEP community and other parties interested in the harmonization of STEP product data and SGML document data.

White paper Development

Prior to the Grenoble meeting the white paper had been through several versions. The initial input was received from two workshops sponsored and organized by SwedCALS, the Swedish CALS group. These workshops pointed out some of the basic technical requirements for STEP / SGML harmonization and developed some preliminary models that are needed to integrate SGML constructs into STEP-compliant environments.

The SwedCALS contributions triggered an activity from the members of T14 to integrate the SwedCALS contribution with the previous work of T14 and to produce a working paper for distribution. The purpose of this paper was twofold: first, a part of T14's mandate is to co-ordinate the requirements of APs concerning documentation. This paper would support this activity. Secondly, it would be very useful for new members of T14 or other interested parties to have access to a paper explaining some of the aims and resources of T14. A white paper was drafted at the Newport Beach meeting in Jan. 1995 reviewing most of the work, concepts, and ideas of the past years work in T14.

The Newport Beach paper was edited prior to the Washington meeting in June 1995 and presented at the meeting. During this meeting it was further edited and an enhancement was drafted of an architectural framework showing possible data flows between a STEP and SGML environment.

The results of the Washington paper were edited and distributed to members of T14 whom had been contributing to its content. It was also distributed to persons expressing interest in attending the Grenoble meeting. The feedback from all parties was very positive and during the Grenoble meeting it was decided to submit the paper as an official SC4/WG3 document. The chairman was charged with editing the changes agreed upon at the meeting and to submit it to the WG3 convenor for inclusion in the WG3 working document registry.

Discussion of the WHite Paper

The consensus of feedback from other parties (participants in T14, other STEP working groups) was that the white paper made a needed contribution to the work of T14 and made it easier to explain the goals of T14.

There were several points raised and discussed about the purpose of the white paper and the significance of its content. It was pointed out that the white paper concentrates mainly on the technical requirements needed for an SGML/STEP co-operation and that many of the issues of product documentation were not discussed. As well, the paper concentrates solely on the SGML standard format for documents.

These discussions resulted in several decisions (see the following sections).

Work resulting from the white paper

The content of the paper was considered ready for distribution to the other participants in the STEP standards activities, however there were some editorial changes that needed attending.

A change to the architecture was indicated which simplified the diagram was suggested. As well, editorial word-smithing needs to be done before distribution.

Other, more time consuming points, were not considered important enough to delay the publication of the white paper, but should be worked on.

Changes to be made prior to publishing:

Points to be worked on:

The models should be worked on by EXPRESS experts and full Express statements be produced and documented.

Decisions Taken from the Discussions of the White Paper

1. Concentrate on SGML for Document Formats for Product Data

It was discussed if the group should include a broader approach to document formats, as has been the original mandate of T14. It was unanimously decided that T14 should concentrate on SGML as the format of documents for integration with STEP-compliant systems.

This does not preclude that other formats will be considered eventually.

2. Discussion of Product Documentation contra Technical Problems

In respect to the discussion of product documentation problems, it was decided that:

The white paper should be published with its current content as it was felt that the technical requirements needed to be made known.

That the problems of product documentation would benefit more from the distribution of the white paper at this time rather than wait for further contributions to be edited and accepted. It was felt that the work of communicating with the APs would be enhanced by the immediate distribution of the white paper.

A list of ways in which T14 can support the documentation of product data throughout its full life-cycle was started. The aim of this work will be to provide concrete ways in which documentation which includes product data can be fully integrated with the STEP processes of life-cycle support, enhanced with constructs allowing new documentation features to become part of the product documentation, e.g., multimedia object definition and scripting, external referencing via global addressing, etc.

SC4 and WG3 Work

Barbara Warthen, convenor for SC4/WG3 presented the work and activities of the SC4 and WG3 bodies. The discussion was aimed at placing the work of T14 and product documentation into the hierarchy of the STEP work. Barbara suggested that the work of T14 was (quite possibly) aimed at a broader group than just the STEP standards and that contact should be taken with the Parts libraries group and MANDAT, Manufacturing Management Data Exchange. She also suggested contact with Technical Data Package (TDP) group which is dealing with exchanges of dissimilar information by creating data "packages".

Chair/Editor's note:

Contact was made with Parts Libraries through Juerg Walser and they have received a copy of the white paper and have promised to send a copy of their tutorial notes.

Contact was also made with Albert Colin of the MANDAT group who also received a copy of the white paper and a promise to send material from their group and to organize a common meeting, perhaps in Dallas.

Glen Ziolko of the TDP was invited to make a presentation, which he did (see notes).

Technical Data Packaging Proposal

Glen Ziolko presented the AP proposal: Technical Data Packaging Core Information and Exchange (TDP). This application protocol is aimed at providing a structure for the packaging and association of groups of (dissimilar) product data. The aim is to allow configuration controlled exchanges among Product Data Management (PDM) systems.

The resulting discussions brought up several points of interest to T14:

Presentation of STEP architecture and discussion of T14 positioning

Julian Fowler (member of WG 10 and one of the architects responsible for STEP) joined the meeting for an afternoon of discussion on how T14's work could best be integrated into the STEP activities. Julian answered questions concerning the "new" directions in STEP, however, it was not clear what the best route would be for T14. Julian was completely convinced that Product documentation would play a large role in the future of STEP, but admitted at the same time that the focus of most APs was on level 1 and (some) 2 (design & manufacturing). Julian made several suggestions for the future:

Chair/Editor's note:

The plant process group has made a presentation to T14 at a previous meeting (Newport Beach) however, it could be useful to contact them again.

Discussions

The following points were raised during the discussions. Some of them were raised several times and modified during the meeting. There are reported here as items of interest to involved parties.

Levels of Documentation

Fundamental to many of the following points is the distinction between levels of documentation. There are repeated here to facilitate reading:

Primary level

Documentation resulting from the design process. Commonly referred to as a "definition of the product after its final production state".

Secondary level

Documentation describing how to reach production state. It usually includes descriptions of production processes and methods. There are often many secondary documents for any one primary document. Secondary documentation also includes documents such as legal documents.

Tertiary level

Documentation describing how to use a product. This level of documentation includes operations, repair, maintenance, re-cycling, disposal, etc. It may also include data capture about the use, e.g., statistical information.

APs and Documentation

It has been a point of mystification to the members of T14 why the APs have not deluged T14 with document specifications and requests for document formats.

The answer was brought forward during discussions: APs are mainly concerned with creation and manufacturing data (levels 1 & 2), not with operations, maintenance, distribution, etc., i.e., level 3 documentation.

The Environments of Documentation and STEP are Distinct

It was discussed in depth and all agreed:

Questionnaire To APs

It was suggested that T14 prepare a questionnaire to be circulated to APs. The following points were added:

Scope

The scope of T14 was, once again, under fire. This was not considered a waste of time (as previous attempts have been). It was pointed out that the title of T14 "Product Documentation" had nothing whatsoever to do with the subjects being discussed. The scope was therefore discussed thoroughly and with help of external visitors (Barbara Warthen & Julian Fowler).

The results of the discussions were:

Explanation of Scope

It was suggested that the scope be accompanied by a paragraph or two clarifying and expounding upon the ideas and concepts in the scope statement.

Definitions

It was suggested and accepted that the work on the scope be accompanied by a set of definitions. This set would also be useful in explaining the scope.

T14's place in STEP

This was discussed several times, including with almost all the visitors. A general consensus (no binding decision) was that the resources (technical constructs, framework, architecture, methodologies, etc.) produced by T14 should support a broad base: STEP, Parts libraries, and MANDAT.

T14 Activity List

The following list was made to direct T14 activities in the direction felt appropriate:

Results of the meeting

Resolutions from Presentations

·That the white paper be edited as instructed and sent to WG3 to obtain official publication status.

Action: H. Tucker
·Shiang-Yu Lee be contacted and asked to present the ATA 2100 data model.
Action: H. Herbault
·That T14 make a presentation (of the white paper) at Dallas.
Action: H. Tucker
·That we follow up on the recommended contacts.
Action: all
·That the EXPRESS models of SGML_STRING and DOCUMENT be worked on by EXPRESS experts.
Action: all - to impress any resources known (with necessary knowledge) to attend meetings (or work off-line).
·Interact with WG10 (STEP architects).
Action: H. Tucker

Resolutions from Discussions

·That a questionnaire be constructed for distribution to APs.

Action: To be worked on.
·Produce an explanation of the new scope.
Action: To be worked on.
·Produce a list of definitions.
· Action: Juerg Walser offered to submit a copy of a list of documentation definitions that he has been compiling.
  1. the word constructs was considered to technical.
  2. the following definitions were suggested: "computer interpretable" - a specific format that allows a document to be read and stored by a computer, i.e., "computer processable".