| Marc W. Durnin | LMAS | USA |
| Betty Harvey | SoftQuad | USA |
| Helium Mak | National Research Council | CANADA |
| Ernie O'Dell | Dept. National Defence | CANADA |
| Nigel Shaw | EuroSTEP plc | ENGLAND |
| Masaru Suzuki | Nippon CALS Research Partnership (NCALS) | JAPAN |
| Hugh Tucker | Documenta ApS | DENMARK |
| King Yee | Boeing Aircraft | USASWITZERLAND |
| Juerg Walser | J. Walser Consulting |
The meeting was opened on Monday, Oct. 7, 1996, following the Sc4 plenary, by Hugh Tucker, chair of T14. The attendees introduced themselves and the agenda was discussed and accepted.
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 Dept. of National Defence (rep. Ernie O'Dell) and the National Research Council of Canada (rep. Helium Mak) had arranged a seminar on the previous day (Sun. Oct. 6). The topic of the seminar was "SGML, STEP, and Internet Integration". Their were 3 invited presentations given by: Joe Gollner, from the Canadian Dept. of National Defence, Nigel Shaw, from EuroSTEP and the chair of T14, Hugh Tucker. The presentations looked at the future of the integration / harmonization / interoperability of data encoded in the SGML and STEP standards and the dissemination of this material via Web tools.
NOTE: The presentations are available on our web for viewing / downloading. See http://www.eccnet.com/step/ courtesy of ECC and Betty Harvey.
As mentioned in the opening some of the work of the past 2 years in the T14 group has been documented in a white paper. This paper expresses some of the areas of focus within the group and points out some of the technical requirements that were felt were required for a harmonization of SGML and STEP. 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 chair of T14 has been active in presented the T14 white paper and has developed a presentation to show some of the details of the paper. This presentation has been given at:
SGML Europe,
Munich, Germany : May 1996
VTT Information Technology sponsored seminar on STEP/SGML
Espoo,
Finland : June 1996
TCIF meeting (Telecommunications Industry Forum),
Denver, Colorado :
July 1996
SGML, STEP, and Internet Integration seminar,
Toronto, Canada : Sept.
1996
The presentation is also available on the WEB site (see above).
This presentation was taken very early in the meeting due to time problems with Mr. Suzuki's other activites.
Masaru Suzuki of the Nippon CALS Research Partnership (NCALS) gave a presentation of the project that they are working on with "Application of AP208 ARM schema to the life cycle management system of a power plant." The following diagram was exhibited in CALS Japan '96 and shows the architecture that they are working on for the integration of SGML and STEP.
The discussion of the presentation by Mr. Suzuki lead into the discussion of the T14 goals and future. It was pointed out that the presentation was a very good example of what T14 should be concentrating on. The goal of T14 should be to produce output that can support architectures as in the proposed life cycle management system of a power plant. This is a very important area for industry.
It was pointed out that the answers to architectures such as the proposed one from the NCALS group may vary - depending upon the application.
It was suggested that T14 should work on:
Several of the participants declared that they were ready to support "proof of concept" projects in this area.
It was noted that one of the essential goals (besides the future ideas that are being worked on) should be to provide an architecture for interoperability with legacy data, i.e., data that is stored in other repositories and in other formats.
Requirements that are primarily needed are:
Note: Ernie O'Dell noted that technical writers used to have to start from scratch when reproducing graphics. Today, 3-D models are available that can be rotated and snapshots produced for useful documentation.
During the past two years T14 has been concentrating on:
It was discussed if the goals of T14 ought now to be changed-given that the above goals are well under way to being achieved. Suggestions were put forward for the "next" phase, or for the new goals for T14:
A suggestion was put forward that perhaps the focus needs to be relaxed a bit and to look at other types of data besides product data, e.g., geographic data.
After the presentation at the Dallas meeting, Reiner Reschke and Hugh Tucker volunteered to elaborate on the ideas and concepts that were discussed at the meeting. There was a short workshop arranged in Germany in May and the resulting papers have been edited and revised over the summer. The present version, which is still being worked on, is available on the Web site. (see above).
The mandate of the new papers were:
These papers were the focus of the discussions during the Toronto meeting. The following is a short review of the discussions and the papers:
(This paper is available in WORD, for downloading, and HTML, for viewing, on the WEB site: http://www.eccnet.com/step/ )
The paper presents the architectural background for configuring product documentation into a hybrid environment that could provide management of information using the same tools as are used for product data management.
The fundamental thesis of the paper points out that providing these facilities are dependent upon three architectural features:
Information Objects
Information objects are presented in the paper as the essential building blocks that are needed to move documentation information from product models to publishing models. Information objects are used as the lowest level of granularity in the product data model. They are the mechanism for moving information between the information structures of STEP and SGML.
Information objects are application specific SGML strings representing semantic blocks of information. There are two key points with information objects:
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.
Point 1: Text can be a representation of a product.
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.
Point 2: Text can be part of a product definition.
Text can be configured into a product definition using Part 44 and can be modelled using EXPRESS.
Point 3: Text has inherent structure-similar to geometry or other representations.
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.
Point 4: The SGML_STRING construct is the container object for text entities.
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.
These topics have been brought up for discussion during the past meetings and have been tabled for future meetings.
It is planned that T14 will meet at each of these activities.