T184/Sc4/WG3/T14
Product Documentation Group
Minutes: San Diego Meeting

June 1-6, 1997

Attendees:

Peter Fiander UK MOD pf@dpmils.demon.uk UK
Betty Harvey Electronic Commerce Connection, Inc. harvey@eccnet USA
Helium Mak National Research Council Helium.mak@N C.CA CANADA
Nigel Shaw EuroSTEP plc Nigel.shaw@eurostep.co.uk ENGLAND
Masaru Suzuki Nippon CALS Research Partnership (NCALS) suzuki@ncals.cif.or.jp JAPAN
Hugh Tucker Documenta ApS hugh@documenta.dk DENMARK
King Yee Boeing Aircraft King.g.yee@boeing.com USA
Daniel Rivers-Moore RIVCOM daniel.rivers-moore@rivcom.com UK
Gerry Radack Concurrent Technologies Corp. radack@ctc.com USA
Eric Lebegue ESPRI CONCEPT France
Raimar Scherer Univ. of Techn. Dresden, Inst. f. Baumechanik and Bauinformatik Scherer@cib.bau.tu-dresden.de Germany
Julian Hardenberg Directorate of Naval architecture and Future Projects, Ministry of Defence hardenberg@dnaandfp.demon.co.uk UK
Tony Stewart RIVCOM tony.stewart@rivcom.com USA
Ken Tanguay Accurate ktanquay@accurate.com USA
Margaret (Peggy) Ayers Honeywell IAC Peggy.Ayers@iac.honeywell.com USA
Martin Philipp Dik Tech. Univ. of Darmstadt Philipp@dik.xxx.th-darmstadt.de Germany
George Touchette EXCEL Management Systems Inc. toucheg@wpdis01.wpafb.af.mil USA
Bruno Shilli ABB Corporate Research bruno.shilli@decrc.abb.de Germany
Ed Bastek Motorola, SSTG P11859@email.mot.com USA
Jim Crawford Lockheed Martin crawf03@ibm.net USA
John Dunford NATO CALS office nco@cals.nato.be Brussels
Madeleine Isenberg Northrop Grumman isenbma@mail.northgrum.com USA
Chia-Hui Shih IBM chshih@unet.ibm.com
Rusty Weaver McDonnell Douglas Aerospace rweaver@msgate.mdhc.mdc.com USA
Alan Peltzman DISA, CFS peltzmaa@ncr.disa.mil USA
George Elwood SAIC george_elwood@dayton.SAIC.com USA
Ralph E. Ferris Fujitsu Software Corp. ralph@fsc.fujitsu.com USA
Eric Lebegue ESPRIT CONCEPT eric.lebegue@esprico.fr France

A. Opening

Hugh Tucker, Chair of T14, opened the meeting on Monday, June 1, 1997, following the SC4 plenary. The attendees introduced themselves and the agenda was presented and accepted.


B. Agenda

The Agenda outline which T14 has used for the past few meetings has proven to be successful and was adopted for the San Diego meeting.

Monday was planned to start with the opening and presentation of the agenda followed by a session for newcomers and to bring people up-to-date.

Tuesday was arranged as an "presentation-day" with presentations from experts in fields that are of interest to or have direct influence on the work of T14 .

The presentations that were planned for Tuesday were mainly concerned with XML the new "version" of SGML and included presentations by Betty Harvey and Daniel Rivers-Moore. A presentation by Ralph Ferris of Fujitsu Software was also scheduled. Two demonstrations of software in XML / HyTime / DSSSL were also scheduled.

Wednesday was scheduled as a "working day" with topics from previous discussions on the table for ratification or amendment.

Thursday is the "summing up" day and planning for the next meetings.


C. Minutes from previous meeting

The chairman went through the minutes of the Chester meeting pointing out the highlights for those who had not attended the meeting.

The minutes were accepted.


D. Other Business

SEDS

The chairman reported that he had prepared a SEDS for WG12 and sent it to the exploder. No feedback has been received.

Recent Presentations of T14 Results and Requirements

The Chairman presented the results and requirements of T14 to the WG10 meeting in Chester following the T14 meeting. The WG10 group decided to initiate a project to carry out some of the ideas presented (undetermined). Berndt Wenzel volunteered to prepare a draft for the SC4 plenary in San Diego. This topic is reported on within these minutes.

A paper on T14 and other SGML/STEP activities was presented by Betty Harvey and Hugh Tucker at the SGML conference "SGML Europe 1997" in Barcelona in May. It was well received with over 100 participants attending the session.

The presentation is available on our WEB site along with the other presentations from previous meetings and conferences. The presentations are available on the web for viewing downloading at: http://www.eccnet.com/step/ courtesy of Electronic Commerce Connection, Inc. and Betty Harvey.

WG10 Resolution

In Chester, following the T14 meeting, a presentation was made to WG10 (the STEP architects) asking for support to fulfill some of the tasks that T14 deemed necessary to progress. WG10 accepted the task of initiating an SC4 activity and it was decided that a draft resolution be prepared for SC4 at the San Diego meeting.

Unfortunately, the resolution was not finished in time for submittal to SC4 prior to the opening of the meeting (June 1). However, the draft was prepared and sent to T14 for ratification, with the understanding that WG10 would present it at the close of the meeting (June 6). (discussions follow on this point.)

Although WG10 had been asked to hold the meeting during the period when the T14 participants were able to attend, the request was denied. There was a very limited number of T14 participants able to attend the meeting. Nigel Shaw and Daniel Rivers-Moore volunteered to co-chair the activity.


E. Newcomers Presentation

The Secretary and Chairman presented the Newcomers / UP-TO-SPEED presentation for T14. There were many attendees and a lot of questions. In evidence there were a number of participants from industry and the military. The questions were so numerous that a special presentation session was arranged to get the input from these delegates.


F. Discussion of the WG10 Resolution

Following the newcomers presentation there was a discussion of the proposed WG10 resolution, called a Preliminary Work Item (PWI). This activity had been initiated at the WG10 meeting:

Daniel Rivers-Moore gave a summary of the WG 10 meeting.

Background

The T14 chair has presented its views to WG10 at a number of occasions. The following is a short resume of the T14 activities over the past 2 years concerning this topic.

Grenoble, October 1995

A presentation was made to representatives of WG10 pointing out some of the problems of SGML_STRING, global addressing. The ensuing discussions resulted in the following:

· The T14 scope was re-worded to:

"Prepare mechanisms(1) to enable the modelling, storing, and interchanging of electronic documents(2) within a framework of product data organization and management."

· The T14 work on technical issues of STEP integration, e.g., the work at the workshops sponsored by SWEDCALS, and the work, on producing the white paper, was essential. However, it was agreed that the emphasis should now be replaced with an emphasis on product documentation problems. It was agreed that WG10 would pick up the issues concerning STEP, such as SGML_STRING and global addressing.

Dallas, January 1996

(Note: At the Dallas meeting, inquiries by T14 showed that WG10 had not done anything following the Grenoble meeting, however, we were invited to make a presentation to the WG10 meeting.)

The invitation to make a presentation 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.

Editors note: This was a very acceptable solution from T14s 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.

Toronto, October 1996

T14s position was presented at a workshop at the Toronto meeting and again at the WG10 plenary. Nigel Shaw presented the position to the WG3 plenary. The points were similar to the previous, the need for the SGML_STRING and global addressing.

WG10 Workshop, NIST January 1997

The Canadian Department of Defence sponsored the Chair of T14 to attend the WG10 Workshop in Washington and to present the T14 viewpoints.

Hugh Tucker made a one and a half hour presentation to the WG10 group at the NIST on the requirements of T14. This presentation (again) emphasized the SGML_STRING, global addressing and the need to obtain feedback from other STEP groups.

Chester, April 1997

The T14 chair was invited to make a short presentation to the WG10 plenary. This presentation again pointed out the need for SGML_STRING and global addressing as well as the need for input from the STEP community as far as information objects were concerned. The results were that WG10 agreed to initiate a procedure / project which would be presented to the SC4 plenary at San Diego.

Summary

The efforts of the past 2 years put into the presenting the T14 requests for requirements are showing signs of maturing. Our case is quite strong. The requirements from T14 that we have been presenting have not changed -- thus the requirements are a clear and understandable goal.

WG10 did not prepared the draft of a promised project in time for the SC4 plenary meeting prior to the San Diego meeting, as promised. However, a draft was presented to the WG10 meeting. This meeting was held before the main meeting and the news of such an activity was received too late by the T14 chair or secretary to attend (T14 was not notified prior to the meeting). A request by the T14 chair to postpone the discussions of T14 business until T14 members could attend was refused. The meeting was held and the draft presented: Nigel Shaw, a WG10 member and T14 attendee and Daniel Rivers-Moore, the only other T14 member present at the meeting were appointed co-chairs for the WG10 sponsored project. The chair and secretary were invited to be members of the project team.

Discussion of the WG 10 Project Draft Proposal

The proposal and their interpretation of its mandate from WG10 was presented by the co-chairs, Daniel Rivers-Moore and Nigel Shaw. The following points were agreed upon informally as a result of the discussions. (The WG 10 draft proposal was subsequently modified and is available for viewing.

The group appointed by WG10 should:

Managing the Project Team and the Text

Daniel Rivers-Moore suggested using the XML model for managing the proposal text. The XML papers were produced by 2 editors. However, there is an editorial board which meets weekly by telephone. There is also a participants list which produces comments. The editorial board is committed to considering / answering all comments.

The CALS model of control was also discussed in this model the responsible people were committed to maintaining the standards and sending out changes to the discussion forums.

The general feeling was that this situation is different than the HTML/XML groups as we are writing a management document not a technical discussion/paper/standard. Telephone meetings would also be impractical. As far as the CALS method was concerned, the issue here is bring things together not to change anything so it probably needs a different form.

It was decided that to start with the secretary, Betty Harvey, will host a forum to discuss the activities on the Web site exploder based. Interested members may subscribe to the activity by sending an e-mail to step-pwi@eccnet.com if anyone is interested in participating. It is requested that only individuals who are interested in participating in the PWI effort subscribe to this forum. Individuals who are interested in the general T14 Working Group can subscribe separately to the Working Group exploder list by sending a mail message with the word SUBSCRIBE in the subject line to step-request@eccnet.com.

Issues

There needs to be a breakdown of the issues listed in the WG10 proposal. These need to be expanded and then compared to the requirements that we are aware of. Finally, the proposals need to be prioritized.

We might need some technique for assembling documents which may be a requirement to the SGML world.

Following is a statement of the mission (or it should be):

Requirement is to establish relationships & exchange data/information in a standardized way.


Industrial Requirements

There were a number of participants from industry who were very interested in T14s activities and plans. They offered to provide an insight into their requirements. The following section is a collection of notes taken during the presentations.

There were several discussions of what the industrial participants considered were the important points for documentation and product data.

Industrial Requirements and Priorities. (Jim Crawford, Lockheed Martin)

(Editors note: Jim Crawford presented the majority of the following, in several different sessions. These have been edited into one at an attempt to make them more comprehensive. There are many contributions from other participants who also made presentations and as well many comments from the audience and from smaller discussion groups.

The attempt has been to arrive at a set of requirements that can be used to base further T14 activities.)

There were several major requirements brought forward:

Two "types" of Management Needed

Configuration Management and Date Management are similar in functionality but address different "widgets".

Data Management

Data management requires that a data architecture be developed. This architecture must accommodate three types of information for product identification:

  1. object (what it is),
  2. instance (what number it is)
  3. storage scheme (where it is stored) -- unique identifier

Configuration Management

  1. ID (what it is),
  2. configuration (which one), what type what is it, e.g., ship engine.
  3. location (where used), the same pump can be used in 50 different locations. This affects installation etc.

On the surface data management and configuration management appear the to be the same. Many people try to use the same tools for both cases.

There is a need to capture information about reference information, just as is done with a product.

There is a requirement to understand the conceptual framework

On the information object side:

Management of Relationships

What is it

What it composed of

Where used

The requirement is, given data and configuration management is that "relationships" need management. One needs to mange relationships in order to manage objects.

The important point is relationships between information objects and what they refer to (other objects, )

Definition of term: Object

Object: element of perceived or conceived reality consisting of a set of characteristics.

Type of relationships:

One problem is to define a interface specification (using the data and configuration management requirements).

As we relate to /develop an information model, we need to be able to describe the relationships between the information objects and the instances. Where in the product models do we need the references?

Where do we capture the relationships?

We need several different 3 constructs SGML (SGML_STRING), HyTime, Style sheets, hopefully using DSSSL.

Jim Crawford has been asked to write a paper on "Data management / configuration management", this should be input into T14.

Just as we define a product we need to define a info object

(NB in STEP there is no instantiation model. (in any case not in 203). They may be defined in 221 (EPISTLE). Question (to be answered) - Do they (at all) define instances of objects? If so, where?

Partial answer: In AP 221 (Life-cycle support) the typical model defines the instantiation, however the other APs have not have this clear model.

We are working on two fronts: the syntactical elements needed to implement the models of 221.

Classically, the information in life-cycle end up in documentation entities.

The results of T14 should produce the above constructs, they are at two different levels.

  1. SGML_STRING, a syntactical construct to allow structured text to be put into EXPRESS models, e.g., design notes, HyTime queries,
  2. A. Information objects, structured text
    B. Links, relationships, queries, based on HyTime
    C. Behavior / style

G. Other Business

What is the target that T14 is aiming at AP? Integrated resource? AIC?

There was a general feeling that an AP seems to be too specific to satisfy the needs of contacted users (Boeing, NATO, )

H. Business cases

Automatic document generation

Vendor supply of components

Exchange (across multiple enterprises)

There is a lot of product data for maintenance / spares etc. that needs to be handled by referencing right back to requirements (similar to analysis/engineering notes)

missing from diagram: share and exchange

Mil 31000 - AP232 (Jim) NATO has tried 31000 and has found that it does not support the needed information modeling

I. Models

A basic problem is that there are no standards for creating models.

J. Peter Fianders Presentation

Info flows:

Product ID
Configuration managment
Initial provisioning / Spares/ organization
Maintenance / Repair
Training
LCC
Product documents
Requirement
Disposal

UK - DEF STANDARD 0060 is an integration of 1388/100d/20000

Documentation is the area where the UK can save a substantial amount of money. The key to solving this problem is to apply data model and organization of (Jim Crawford's talk)

The UK are mandating SGML & IETMs

The UK has done a study of the similarities between APs and have found that there is an 85% fit between the APs of Shipbuilding, Aircraft manufacture, and Tank construction.

K. Peggy Ayers

Peggy stated that the same problems (as presented by Jim and Peter) in the process industry.

Abnormal Situation Management

Provides information to the operators in times of catastrophic failure. If you have a catastrophe that will occur in 5 minutes then you don't give the operator 15 minutes of information. They need information from different sources merged. Also, after the problem occurs and is resolved they need to report the information to the necessary authorities.

L. Betty Harvey

XML and SGML

Presentation available at http://www.eccnet.com/step/xml/

M. Presentation of XML-link by Daniel Rivers-Moore

Daniel's presentation explained how the XML working group is currently looking at creating hyperlinks.

N. Presentation of Hytime / HyBrick by Ralph Ferris (Fujitsu Labs)

Ralph stated that the WG8 had adopted a technical corrigenda that would enable the adoption of XML by the SGML community. He stated that one of the problems with XML is that it doesn't have a clear business case yet! "Making it easier is not good enough!" We need to know what is the market for XML / SGML / DSSSL / HyTime? Need a very carefully chosen market to be able to choose the subset of SGML! The acceptance of XML will depend upon a good application.

Fujitsu Labs are in the process of integrating the latest HyTime corrigenda and DSSSL processors they will be interested in finding partners to develop applications, e.g.., IETMs


1. Documentation (Information) Objects

Hugh Tucker presented a framework for the EXPRESS modelling and mapping into SGML. This model is based on the information object, or (proposed) the documentation object, as the pivotal point. The documentation object is the lowest level of EXPRESS entity and the highest level of SGML (architectural form) element structure. This is where the SGML and STEP data types meet!

The modelling of structured documentation is quite straight forward using EXPRESS down to the level of the content models. For example, a technical document may have a structure composed of chapters, sections, sub-sections, etc, which is a simple hierarchical structure. The contents of the document can be encapsulated in documentation objects (see slides) as the lowest level entity. The documentation objects have semantic meaning, e.g., procedure, process, requirement and they can be used for the content of EXPRESS modelled documentation.

1.1 TEXT IN STEP

Re-usable text

One of the basic "features" of SGML is the use of user defined "tag sets". Typically, applications develop tag sets directly relating to the terminology of their own application. This means that interchange of structured text, even though it may be exactly the same type of information and structured in the same way, it is not possible without some type of 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.

Standard templates using Architectural Forms

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.

1.2 DOCUMENTATION OBJECTS

Documentation objects can be used to provide a way of organizing and categorizing similar types of information across the boundaries of the many different application areas (APs). These classes can be used to categorize application information into "generic" types and represented using SGML architectural forms.

These types could form the basis, such as a set of integrated resources or templates, which APs could base the development of their more specific documentation.

1.2.1 INFORMATION MAPPING

Information Mapping is a candidate for providing documentation object types. The Information Mapping principles provide a well thought-out (25-30 years of development) and accepted technology for classifying information types.

Information Mapping has refined the types of information down to seven classes.

1.2.2 INFORMATION TYPES

Procedure

A procedure is a set of step which a person performs in order to obtain a specified outcome.

Process

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.

Structure

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.

Concept

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:

physical objects
conditions
relations
responses
events
ideas
etc.

Principle

A principle map is one in which a given body of knowledge presents an important:

policy
principle
guideline
standard
rule
law
assumption
generalization
regulation
criterion
goal
objective

Fact

Facts are statements asserted without supporting evidence.

Classification

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.


1the word constructs was considered to technical.

2the 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”.