It is with
great sadness that T14 noted the death of their chairman Yuri Rubinski. Yuri had
been a part of T14 for many years and a guiding light in the area of SGML.
Yuri's warm friendship, enthusiasm and expertise will be greatly missed.
|
|
Attendees:
| Wey Tyng Chang | YSII | USA |
| Marc W. Durnin | LMAS | USA |
| Mike Evanoff | MANTECH | USA |
| Ivan G. Fuchs | Naval Engineering | CANADA |
| Lee LeClair | Texas Instruments | USA |
| Shiang-yu Lee | Boeing Aircraft | USA |
| Helium Mak | National Research Council | CANADA |
| Reiner Reschke | EuroSTEP GmbH | GERMANY |
| Hugh Tucker | Documenta ApS | DENMARK |
| Juerg Walser | J. Walser Consulting | SWITZERLAND |
The meeting was opened on Monday, Jan. 22, 1996 following the plenary by Hugh Tucker, deputy chair of T14. The attendees introduced themselves and the agenda was discussed, modified and accepted. T14 was invited to attend and make presentations at:
A chair gave a short summary for newcomers of previous work, meetings, and activities. (SGML_STRING, White paper development, technical problems and requirements, etc.)
The minutes from the Grenoble meeting covered many of the essential points of work of T14 and a discussion of the minutes would therefore entail longer discussions. It was decided to take the discussions of the Grenoble Minutes together with the work items rather than to try and discuss the minutes as a whole.
The following points were on the agenda for the Dallas meeting:
·That the white paper be edited as instructed and sent to WG3 to obtain official publication status.
·Shiang-Yu Lee be contacted and asked to present the ATA 2100 data model.
·That T14 make a presentation (of the white paper) to the WG10 group at Dallas.
·That we follow up on the recommended contacts.
·That the EXPRESS models of SGML_STRING and DOCUMENT be worked on by EXPRESS experts.
·Interact with WG10 (STEP architects).
The following work items, guests, and presentations (not ordered chronologically) followed during the meeting:
| Section | Work Item / Presentation | Presented by |
| 3. | Presentation of ATA 2100 activities and plans. Presentation of a document model in EXPRESS-G | Shiang-Yu Lee |
| 4. | Discussion of SGML/STEP projects EuroSTEP | Reiner Reschke |
| 5. | Presentation of the T14 White paper | H. Tucker |
| 6. | Presentation and discussion of Technical Data Packaging proposal. | G. Ziolko |
| 7. | Development work on Infrastructure model - furthering "white paper" | All |
| 8. | Development of modular approach for APs DTD construction using HyTime architectural forms | All / proposal from H. Tucker |
| 9. | Presentation of Information Mapping for technical documentation | H. Tucker |
| 10. | Presentation of T14's technical requirements for WG10 | H. Tucker |
| 11. | Presentation of T14's activities for CALS/PDE group | R. Reschke / H. Tucker |
|
Editor's note: The Grenoble meeting had suggested that Shiang-Yu Lee present some of his work and the ATA2100 activities in light of the T14 work. Shiang-Yu was approached and agreed to make a presentation. |
Shiang-Yu Lee presented the ATA 2100 DTD and STEP model that are under development by Boeing. The presentation described the maintenance engineering data model and was discussed in the group as a pragmatic example of the needs of industry. Shiang-Yu described the history of information handling within ATA starting with the ATA100 standards.
The ATA100 standards are the early efforts of defining commonality of terminology and classifications within technical manuals, e.g., ATA100 defines such things as: task parts, illustrated parts catalogues, maintenance manuals, etc. There was no data modelling and was generally based on experience and common sense.
ATA100 developed a numbering system, similar to the ECMA classifications, which were characteristic of all manuals. This produced a structured set of manuals organized by subjects and cross-indexed by task. A further development of this was the AMTOSS which was a more detailed classification and description of tasks.
Next came the PMDB system which was an attempt to provide a way of describing and organizing electrical data. Its format was a large flat file where the fields are all one big table. It was found to be very difficult to denormalize and encode all of the information. The specification was very loose as it was found to be very difficult to use the data consistently.
ATA2100 adopted the use of SGML and encoded product data in a set of DTDs structured for example as: task / sub-task / procedure / cycles / flight hours / etc. ATA2100 provides only for simple data element encoding, there is no specific associations and companies encode the content and structure. ATA2100 contains some solutions for creating databases but no data modelling.
Started in 1989 with QUANTA defining the first ATA data model for maintenance systems. Later CANADIAN used the same model to produce their maintenance systems. However, these models were never globally accepted.
Ron Sørensen (formerly from CANADIAN - made presentation to T14 in Newport Beach together with John Anderson) has been working on furthering the modelling and for example, including the electronics in ATA2100 with graphics, text, and multi-media. There are now three groups working:
The question was asked how mappings from the models to the DTDs was accomplished. The answer was that ATA2100 is providing a data dictionary with lists of terms from both areas and maps to align them.
Shiang-Yu is working on the modelling of information applicable to different maintenance models with the purpose of structuring the commonality of information in a way that one manual (at the top level) may apply to many different aeroplanes, the next level of manual may apply to several aeroplanes, the next level to one aeroplane and so on.
This implies that the logical structure is dependent upon the operating conditions and the documentation is built up of conditionals, e.g. for structure:
747
& 300 | 200
& COMBI
& GE engine
&
Sundstrand generator
If (ETOPS) then do this....
If (non-ETOPS) then do
this....
Shiang-Yu then presented the STEP model of
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.)
Dr. Reiner Reschke, EuroSTEP, presented a short review of some of the activities that they are involved in. The work is in the industrial segment of Defense Suppliers and is concerned with the support of product repair and maintenance. It covers mainly Workshop and Operator's manuals and Crew material as well as some Maintenance and Service information.
Dr. Reschke described the current publishing process and the problems that were evident from the working environment. He stressed the need to change our documentation environments from authoring assembly and disassembly to authoring documentation in the context of system breakdown and maintenance tasks such as described in the Integrated logistics support (13882b) functional description.
He pointed out that what you want to achieve is an integrated working environment which is product model driven. High priority is being given the following:
The project has several other considerations worth noting:
The designs where based on the following:
The information structure is built up about the FMV "Grund-DTD" which is comprised of 24 different types of information modules. These contain the descriptive information about an object and are marked up specific to the meaning of the descriptive information, not to the structure of an intended publication. In this project, re-usable information fragments can be combined into information products for publishing.
Dr. Reschke presented how the Information Model associated the descriptive information to core objects. He then outlined the System Environment that the project was aiming to construct.
During the past 1½ years the T14 group has been working on a white paper to express the areas of focus within group and to point out some of the technical requirements that were felt were required. 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.
The Grenoble meeting had instructed the editor (H. Tucker) to make editorial changes and to release it for publication. (The Minutes of the Grenoble meeting contain a history of the development white paper.)
From the Grenoble meeting:
"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."
Points left to be worked on:
Examples, should be produced to explain the models and architecture.
The models should be worked on by EXPRESS experts and full Express statements be produced and documented.
Glen Ziolko presented the AP proposal: Technical Data Packaging Core Information and Exchange (TDP).(1) 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 presentation concentrated on the ability of transferring formatting information from one STEP environment to another. The interchange of formatted tables (which is a major consideration for the TDP proposal) such as parts lists need to be accompanied with an indication of how they are to be presented.
It was pointed out that the transfer of formatting information was a non-trivial problem. Formatting for screens is quite different from paper and is also affected by country and cultural preferences.
There was an international standard group working on the problem: ISO/IEC JTC1/SC18/WG8 - Document Processing and Related Communication—Document Description and Processing Languages. The proposed standard is at draft status: DIS 10179.2 Document Style Semantics and Specifications Language - DSSSL.
It was also suggested that much of the tabular information could be encoded with SGML using the CALS table tags. The reason for this is twofold: first, it is an widely accepted and supported format with many software tools available for creation, distribution, and conversion. Second, it would allow the attachment of DSSSL instructions and formats ensuring a broad range of formatting facilities that are likely to be widely accepted and supported, e.g., WWW.
There had been several suggestions for improvement of the T14 White Paper:
The meeting felt that the suggestions were correct, but that it was more important to further the work on the infrastructure at this time rather than wordsmith more on the white paper. It was also pointed out that the white paper had served its purpose in that it had generated interest and communicated some of the work items that T14 is working on.
It was decided to work on the infrastructure of the storage methodology (as suggested in point 4) and to try and develop a more complete system integration. The work was aimed at developing a technical "way-forward" in the integration of STEP and SGML information structures.
It was decided that the work done during the meeting should form a separate paper. H. Tucker and R. Reschke volunteered to work on writing this paper. The following points were developed during the meeting and form part of this paper.
The STEP definitions use the concept of different "representations" or "views" of a product, e.g., a product can be defined by a sketch or a detailed design. Part 41 defines a methodology for defining product data representations. The STEP papers most frequently exemplify the "representations" of product data with references to geometric constructs.
There are several important conceptual points that need to be understood in association with the defining of compatible information structures.
A product can be defined using text—in the same manner as it can be defined using a geometric representation. Thus, text can be considered as another "representation" of a product.
Text can be configured into a product definition using Part 44 and can be modelled using EXPRESS.
Similar to the inherent structures of geometry, text has inherent structures.
For example, in Part 42 geometric constructs are defined using the traditional Euclidean geometry. A vector is defined with inherited geometric properties and a magnitude and direction. The data content (the values of the points, magnitude, orientation, etc.) of a vector has only meaning when it is recognized as belonging to the "vector" construct.
Similarly, a procedure (a procedure is structured into steps) for disassembling a motor has data content that is only meaningful when recognized in context. Similar to the numbers (the Xs, Ys, ...) of the vector data that need to be interpreted and presented (drawn on the screen or paper) before the vector is perceived as meaningful so does the text for each step of the procedure need to be interpreted and presented, e.g., indented, numbered, capitalized, etc.
The presentation of geometric (numeric-based) objects such as points, vectors, circles, etc. have a direct counterpart in the presentation of (character-based) procedures, processes, descriptions, warnings, etc.
The SGML_STRING provides an entity construct allowing structured text to be modelled using EXPRESS. An SGML_STRING is not at the level of a vector or point but rather closer to a geometric_representation_item which has the property of an associated context.
It was determined that to harmonize the STEP-SGML it would be necessary to develop information structures which did not limit the facilities of either SGML or STEP. The object is to allow the full functionality of both STEP and SGML to be applied to the SGML_STRING objects.
A STEP schema must be developed for defining Documents Internal to STEP
The requirements defined in the white paper determine the overall strategy of developing information structures. Thus the STEP information structures must be used to define products, i.e., documents. Documents can be defined (& modelled) using STEP entities—this requires a need to investigate the document schema as defined in Part 41.
However, STEP entities are not defined at the level of granularity needed for documents, i.e., at the character code level. This is reflected in Part 41—which defines the document schema as referring to external documents (in external formats, e.g., SGML, ODA, ASCII, RTF).
The SGML_STRING will be the "representation_item"(2) entity for text. This will be developed to have the appropriate attributes and relationship entities needed to represent strings of structured text. The representation of structured text will be in the form of SGML tagged strings, i.e., strings of standardized character codes, e.g., ISO 646, ISO 8859-1, ISO 10646.
One of the basic "problems/features" of SGML is the use of non-standardized tags. (SGML standardizes a method of describing text structure not the tags used to mark-up the text.) Thus many different applications have developed their own "tag sets" which means that interchange of structured text between applications is not possible without conversion. There are emerging however, sets of tags for specific entities, such as tables where the complexity of tagging has brought a great measure of harmony and many different applications have decided to support one tag set, e.g., the CALS tables used by ATA, military, Automobile, etc.
T14 will propose a scheme for developing standard tag sets for STEP applications, i.e., T14 will not develop a standard set of tags for STEP. The purpose of the T14 scheme will be to allow structured text to be used in any STEP application that complies with the method.
The proposal for this methodology will be based on the technique used in defining HyTime (ISO 10744) which developed a method for defining "standard" templates of SGML structures that can be embedded into a DTD. These templates are called "architectural forms".
The proposal will look into the possibility of developing a "standard" set of templates for STEP that could be used to encode structured text for any application and thus ensuring that it could be used in many different applications (DTDs).
Information Mapping is based on the idea that the paragraph is inadequate for efficient communication because it is too ill-defined to "provide a precise, useful way to organize and transmit complex, technical information".
Instead, "information blocks" are brought together under strict guidelines into what is termed "information maps". Information maps use a hierarchy of "chunks" with "labels" which organize small, relevant units of information into a hierarchy, and provide the larger groups with a label.
Information should be grouped into small, manageable units, called "chunks".
All the information in one chunk should relate to one main point based on that information's "purpose" or "function".
· "Like" things should be placed together.
· unrelated items should be excluded from each chunk.
After organizing the information into chunks, a label should be provided for each. Labelling facilitates comprehension and information retrieval. Labelling provides "advance organisation" for the reader. Labelling facilitates "quick scanning".
For similar subject matters, use similar words, labels, formats, organization and sequences. Consistency reduces ambiguity and focuses on content rather than form.
A procedure is a set of step which a person performs in order to obtain a specified outcome.
A process is a series of events or phases that takes place over time and usually has an identifiable purpose or result. Some processes include multiple conditions and results.
A structure is a physical object or something that can be divided into parts and has boundaries. It includes the description of whole systems such as companies and organizations and their environments.
A concept is a class or group of items which share a unique combination of critical attributes not shared by other groups, and can be referred to by the same generic name or symbol.
Such items may be:
A principle map is one in which a given body of knowledge presents an important:
Facts are statements asserted without supporting evidence.
Classification is sorting a group of items into classes or categories by the use of one more sorting attributes.
A sorting attribute is a quality that is used as the basis for classification.
Information Mapping can be used to provide a way of organizing and categorizing similar types of information across the boundaries of the many different application areas found in STEP. Information Mapping has refined the types of information down to seven classes. These classes can be used to categorize application information into "generic" types and represented using architectural forms.
Using the Information Mapping principles as the major classification provides a well thought-out (25-30 years of development) and accepted technology for classifying information types. These types could form the basis of a group of templates which APs could base the development of specific documentation.
At the Grenoble meeting, a member of WG10 had been invited to a discussion round within T14. This had resulted in an invitation to present the views and requirements of T14 to the WG10 group in Dallas.
This invitation was followed up and the T14 chair presented the following two points that were considered as absolutely necessary for STEP / SGML co-existence:
· This is required for external environments (such as documentation) accessing STEP constructs, e.g., extracting STEP data for insertion within a publication.
The WG10 group discussed these points and their implications and decided that both points were basic and essential to the total STEP environment. WG10 would therefore assume responsibility for the establishment of these facilities.
Editor's note: This was a very acceptable solution from T14's viewpoint as it removes the responsibility of a considerable amount of lobbying from T14. It will no doubt also be the quickest way of getting results.
The chair and several other members of the CALS/PDE group attended a T14 meeting and had subsequently invited T14 to present the current state of our work to the whole CALS/PDE group. R. Reschke and H. Tucker volunteered to create a presentation and to hold a seminar for the CALS/PDE group.
The following are the slides used at the presentation (unfortunately the diagrams did not translate into WORD format):
· information about design/manufacturing - the production of an enterprise
· describes many aspects of product data
· also describes processes such as: operation, maintenance, use,
· effective, timely, & accurate descriptions of products
Advantages are not realized today for lack of an integrated information system.
Product documentation undergoes the same processes: design, manufacture, production, distribution
Similar distinction between data associated with a product and its representation
Product documentation is fundamental to the product life-cycle and is part of the product itself.
T14's goal is an information architecture based on the international standards of STEP and SGML integrating product documentation and product data throughout the life-cycle of a product.
SGML environments are well-established (10 years) & has extensive software support
· neutral, platform-independent
Granularity of modelling and data representation well suited to the design and presentation of product documentation
· character based representation of information
· up-to-date design, manufacturing data
Integration of Product Documentation as part of product life cycle management
· Version control
· SGML data to and from STEP-compliant systems
· product documentation contains references to product data
· need to be able to model product documentation representations
The following points were raised at Grenoble and some of them were discussed however, all were considered important enough to be put on the agenda of the next meeting. The Dallas meeting spent much of its time in developing the information infrastructure models and many of these points were not discussed. They are therefore tabled until the next meeting.
The following list was made to direct T14 activities in the direction felt appropriate:
This was discussed at length during the meeting and a paper is being prepared to reflect the results.
Many of the points presented by R. Reschke are aimed at developing methodologies.
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:
"Prepare mechanisms(3) to enable the modelling, storing, and interchanging of electronic documents(4) within a framework of product data organization and management."
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.
Suggestions from Grenoble Meeting
The following points were not discussed in detail, even though there were questions raised from the floor. They were therefore tabled until the next meeting.
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.
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.
It was discussed in depth and all agreed:
It was suggested that T14 prepare a questionnaire to be circulated to APs. The following points were added:
Several questions that could be part of a questionnaire are:
IPO April 21-26, 1996 - The chair will inform attendees if it will be possible to hold a meeting. (The financial situation is very uncertain at this time.)
ISO June 9-14, 1996 - It is unlikely that T14 will hold a meeting, due to the expense of travel.
IPO/ISO Oct. 6-11, 1996 There will definitely be a T14 meeting.
Note: R. Reschke and H. Tucker will try to organize an ad-hoc meeting (to discuss topics related to T14's work) in Munich prior to the SGML Conference in May. More information will be forthcoming
(1) This topic was also presented at Grenoble and had been discussed at Newport Beach.
(2) Similar to the geometric_representatin_item of Part 43.
(3) the word constructs was considered to technical.
(4) 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".