Using the DOM as an XML/HTML repository API   Table of contents   Indexes   W3C's Resource Description Framework Schemas: DTDs for the 21st Century
 
 

STEP/SGML harmonization - Data Architecture or Product Documentation?
 
Nigel   Shaw
  Managing Director
  EuroSTEP Ltd.
Castell
Bodfari
Denbigh   United Kingdom  LL16 4HT
Phone: +44 (0)1745 710 677
Fax: +44 (0)1745 710 688
Email: nigel.shaw@eurostep.co.uk Web: www.eurostep.com
 
Biographical notice:
 
Nigel Shaw
 
Nigel Shaw is an internationally respected expert and consultant in the area of product data and related standardization. Nigel has been involved with the STEP standard since 1986 and is recognised as a technical leader within the STEP development. From 1989 to 1995 he chaired the Editing Committee for STEP.
 
Nigel has experience working with manufacturing companies, particularly in military and civil aerospace. For five years he represented British Aerospace in the PDES, Inc. Consortium, working with major US companies.
 
Since early 1995, Nigel has chaired the vendor Round Table of the ProSTEP Association where his role is to ensure consistent implementation of STEP across the major CAD vendors and to co-ordinate further development of data exchange processors.
 
With EuroSTEP, Nigel is the managing director of EuroSTEP Limited but also has to do real work! Nigel has been involved with a NATO project to integrate standards for logistics, initial procurement and technical publications with STEP. Nigel has also been active in the new Preliminary Work Item concerning the potential bringing together of STEP and SGML. In this respect he has been working closely with Boeing.
 
ABSTRACT:
 
Traditionally the standards for handling product data and documentation have been mutually exclusive choices. There were several reasons for this:
  • different standards
  • different tool technologies and communities
  • lack of sufficient interaction between the relevant players
 
In practice both communities are solving closely related problems. They have now recognised that there is much to benefit from in their closer integration and combined application of the respective tools.
 
A common effort has started to demolish the walls between the standards areas covered by STEP and the SGML family. This will lead to businesses being able to inter-operate across both domains effectively, managing and linking both types of information together. This should enable increased value to be gained from information around products using standards based approaches to ensure portability and long-term viability of the information. It should also enable reduction in the storage of redundant information across product databases and related documentation.
 
This presentation gives the background to the interoperability efforts, and describes why the effort is considered to be an architectural issue within the STEP community. The paper also outlines the possibilities to be realised by doing succeeding with the combination of approaches.
 
 

Introduction
 
In 1990 I was asked to represent product data standards in a NATO Industry study of CALS. The US Department of Defence had recently defined the whole CALS approach and the study had to determine its relevance to NATO. There was a business group and a technical group looking at the relevant standards: SGML, EDIFACT, IGES, STEP,... Several invited experts were gathered together, each representing a different domain. I was there for IGES and STEP. The SGML family of standards was represented by a Canadian, who, for the purposes of the study, was elected an honorary European. His name was Yuri Rubinsky.
 
The chairman was not familiar with STEP so I was asked to go on first and explain it. Yuri was asked next and he got up, pointed to a picture I had drawn illustrating the STEP technology, said "Its just like that!" and sat down. Of course, this was not quite the whole story but the basic point was made. At one level, STEP and SGML are variations on a theme: the use of language (in the computer science sense) to describe and handle information. However there are many differences too. To explain what some of those are is necessary to show why the integration of STEP and EXPRESS with the SGML family is an architectural question.
 
Later in the NATO study, Yuri and I came up with and documented ideas as to how STEP and SGML could be used together. Now, nearly 8 years later, I am pleased to say those ideas are beginning to take hold.
 
 

The starting problem
 
The effort to develop STEP started with both the success and failings of the IGES specification. IGES set out to enable the exchange of engineering drawings between computer-aided draughting systems. In this initial brief it was a success and became very widely used. However it also had several failings:
  • Verbose file format with at least 3 eighty column records per item
  • The file format and data content definition were the one and the same thing.
  • It did not support automated software development, leading to several years of development before exchange became reliable.
 
These failings were to be addressed by a new International Standard which would also deal with geometric models and a broader perspective on product data than simply drawings. This development started in 1984 and took ten years!
 
Another significant aspect of the development of both IGES and STEP has been the recognition that the relevant systems for creating the data already existed in a variety of forms with their own internal and external but proprietary data forms and storage approaches. Furthermore these systems would often hold the same or related types of data. Hence the standards had to support many different potential forms of implementation.
 
As a consequence of this background, STEP comprises 4 major areas which go a long way to separate the "how" from the "what" (which IGES failed to do):
  • EXPRESS, an implementation independent information specification language (ISO 10303-11)
  • A file format for exchange driven by the EXPRESS language and so generic in terms of the data content. (ISO 10303-21)
  • A programmer level data access interface, also based on EXPRESS (ISO 10303-22)
  • Models built using EXPRESS (many other parts of ISO 10303)
 
Of these components only the models are specific to product data. The other components, particularly EXPRESS and the dependent file format and access interface are generic and can and are being applied to many different information domains.
 
As was indicated in the introduction, STEP, and specifically EXPRESS, is built on the same basic computer science as SGML in that a language is defined which is then used to describe the form of some information. Then mechanisms are provided to allow instances to be handled. The standard also contains much use of the EXPRESS language. In effect this is like defining a set of standard DTDs. The parallels are clear.
 
However there are some key differences. These include:
  1. From the initial problem, it was always assumed that there could be many instance forms for the same data. (More than one is allowed for in the standard!)
  2. The types of data vary and include much numerical data.
  3. The structure of the data being considered is not necessarily predictable or hierarchical.
 
 
Therefore we have a data description language used as the basis for multiple implementation forms. These include databases, programming language constructs and tools such as browsers as well as the file format and data access interface. In fact there are several other standards using EXPRESS, some with their own exchange format.
 
 

Why is the impact of integration with SGML an architectural issue for STEP?
 
So why is the impact of integration with SGML an architectural issue for STEP?
 
The simple answer is that there are so many possible ways in which the capabilities of the SGML family could be fitted into STEP that an architectural perspective is required. We will examine some of these:
 
The use of SGML as a publication mechanism for the STEP standard. (This is an ongoing development which will not be discussed further here.)
 
STEP, through the EXPRESS language, has a base type called STRING. In an approach designed to support computer sensible data, the STRING is where computer sensibility ends. But SGML provides a mechanism for making STRINGs (and a lot more) computer sensible.
 
Product data includes many documents which are both sources for aspects of products (such as specifications) and derived from product data (such as parts catalogues). Therefore there is a need to:
  • store product data and documents together
  • link (and navigate) across both "kinds" of information.
 
This raises several key questions:
  • Can we define a common model for the management of document and product data?
  • Can the linking mechanisms from the SGML family, notably HYTIME, be applied to EXPRESS driven product data?
  • Can those linking mechanisms be applied solely in the EXPRESS driven world to enable a general addressing mechanism?
 
STEP is a complex mixture of a standard, containing some elements purely connected with the "how" aspects of technology and many elements which use the "how" to define "what" the standard deals with. It is like having the basic SGML language and a set of complex DTDs in the same standard. The DTD equivalents (EXPRESS schemas) impose limits on the relationships that can be defined in instances of data.
 
However there is a second level of relationship which is needed. Such relationships cannot be predicted, and so subjected to data modelling. Instead they are defined in and between instances of data sets corresponding to the schemas defined by data modelling. Typically they occur in product data in the relationships defined to support parametric geometric modelling. This second level is equivalent to the use of HyTime to provide links which are independent of a DTD. In practise this involves two key elements: addressing the elements being related and specifying the nature and meaning of the relationships.
 
The STEP development activity (TC184/SC4) has been working on parametrics for a while. (It has a tendency as a subject to cover a multitude of areas including different forms of shape representation which use the ad-hoc relationships.) There is an ongoing struggle to deal with addressing (effectively links). This is an area where there is much that can be learnt from the HyTime standard.
 
We also have a strong developing interest in the use of SGML or, to be more specific, XML as a basis for an alternative encoding for the STEP Physical file. This is a very natural development given the explosive growth potential of the web and data exchange using web tools. It is also a relatively straightforward development to base on the EXPRESS language.
 
Hence, there is potential that the interaction with the SGML family will affect:
  • how data is exchanged
  • the richness of the data that can be exchanged
  • the storage approaches used for holding mixed product and document data
  • how product data can be navigated
 
Inevitably this kind of combination of effects requires an overall assessment. Hence the relationship to the SGML family of standards becomes an architectural concern.
Using the DOM as an XML/HTML repository API   Table of contents   Indexes   W3C's Resource Description Framework Schemas: DTDs for the 21st Century