WHITE PAPER
Interoperability between STEP and SGML
Provide product management capability on SGML documentation.
Provide improved product data representation.
NOTE: This paper is also available as a PostScript file: Uncompressed (2.256M) or compressed (165k)
Contents
- Background
- Vision
- Goal
- Strategy
- Mission
- The Role of STEP
- The Role of the SGML Family of Standards
- Results
- SGML_STRING
- Proposed Changes to STEP Resource Models
- SGML-Compliant STEP Implementation Form
- Activities
- SWEDCALS Project
- Standardisation Work
The focus of information systems is moving away from the simple objectives of
reducing costs and improving the control of operations. Instead, many companies
are aiming at establishing information architectures that will give them
maximal use of their accumulated information and knowledge.
The new architectures must be able to share, reuse and maintain information and
be flexible enough to accommodate continuous business process improvements.
They must also support the complexity needed for increasingly finer levels of
granularity of information context, content, and structure. The problems that
the new architectures must overcome to manage the vast quantities of
information needed for a modern enterprise are compounded by the
incompatibility of computer platforms, proprietary application packages and
stored legacy information.
As the business sectors in enterprises have been developed, their information
resources have evolved to support the local sector needs. Even within the same
business sector, different proprietary systems increase the difficulty in
sharing, reusing and maintaining information. And it is more the rule than the
exception that information systems in different business sectors use totally
independent and incompatible systems.
It is self-evident in today's complex business enterprises that the integration
and interoperability of information between business sectors is necessary.
Architectures must be found to solve the problems of incompatibility, and open
for information interchange within and across the entire enterprise.
Many businesses see the use of international standards as the architectural
building blocks for providing harmony within business sectors and helping to
reduce incompatibility between systems. However, even international standards
have often been developed to solve information problems within separate
business sectors and therefore even though the use of standards can solve the
information problems within the individual business sectors, the problems of
enterprise-wide information compatibility remain. To achieve full open
information interchange and interoperability across enterprises it is necessary
to design an architecture that can integrate the standards supporting
individual business sectors.
Two of the most prominent and important information sectors in which
compatibility and interoperability are needed are in the areas of: product
data and documentation. There is a growing awareness of the benefits
of integrating product data with the documentation describing the product.
Moving the standards closer together to support product documentation as part
of the life-cycle of manufactured products is becoming an actual and urgent
topic for standards bodies and industry alike.
SWEDCALS[1] regards it as a matter of high
priority that the CALS- community and ISO- organisations understands the need
of co-operation between the standards for documentation and the standard for
product data. SWEDCALS is therefore recommending that the CALS and ISO
committees responsible for these activities to concentrate their work and focus
on the integration of available and accepted standards in order to produce some
useful results.
To assist in the standardisation process and to provide a productive
environment for aligning these two areas, the Swedish FMV CALS office[2] initiated a workshop in November 1994 with
experts from both the STEP and the SGML arenas. Another workshop was arranged
by Astra AB in March 1995, where the results from the earlier workshop were
refined and further developed. The results from both of these workshops are
documented in this white paper.
The STEP Committees responsible for the integration activities have been
strengthened by the SWEDCALS initiative and have responded by focusing their
work on the specific task of integrating the SGML family of standards into the
STEP architecture.
The goal is to create an open architectural framework in STEP[3] (the ISO standard for product data) to
support the interoperability with the SGML family of standards[4] (the ISO standards for documentation),
without compromising either standard.
This will allow the production of products and documentation to be combined
into one, well-managed environment, completely defined by accepted and widely
used ISO standards. It will allow the integration of the documentation of the
total life cycle of a product to be an integral part of the actual product.
The goal will be accomplished through contributions from the STEP and SGML
arenas and from end users with clear and immediate requirements for a practical
solution. This strategy has been successfully used in the initiatory work in
the two workshops that have been held.
The objectives will be to model solutions and to recommend proposals for the
standards committees. The validity of these recommendations will be
demonstrated by creating a series of prototype systems.
The solution must be built on the following basic agreements:
- Both the STEP and the SGML family of standards have values of their
own and can successfully be used in isolation.
- The STEP and the SGML family of standards jointly provide the
required capabilities to treat information products (e.g. documents, books) as
products (in a STEP sense), and as product components.
- STEP provides capabilities that are required but lacking in the SGML
family of standards, and the SGML family of standards provides capabilities
that are required but lacking in STEP.
The solutions has to support both various and different levels of granularity
of information objects between the product model and the model for
documentation.
Each standard shall maintain its integrity and be modularised the way it suits
the user's needs.
The open architectural framework in STEP should be able to:
- Model the information needed for an SGML environment.
- Manage SGML entities[5] within
STEP as product data. This involves finding a solution for the modelling
/ storing / accessing of SGML entities in STEP at an acceptable granularity.
- Support a linking strategy compliant with both STEP and SGML.
- Allow SGML products to be exported in a format suitable for a
"bordering" SGML environments, e.g. publishing, multimedia, etc.
STEP is designed to represent product data and its internal relations or
structure. This is done using an object oriented approach. One of the strength
of STEP is its architectural framework
The role of STEP is identified as the following:
- To represent product definition information, including product
identification, product structure, product versioning, product configuration,
full life cycle support, etc.
- To provide access to its architectural framework for other product
related standards outside of the scope of ISO TC184/SC4, such as SGML.
- To fully support the needs of product documentation and other information
products.
The first item is what STEP is designed to do already. SGML do not attempt to
do this, except possibly when the product is an information product, e.g. a
document or a book.
Item two identifies the need to open up the STEP standard, so it can embrace
information encoded according to other standards. As we understand, STEP cannot
try to embrace the entire world and exclude the use of other standards. We
cannot accept that all new standards should be re-invented or re-defined within
STEP. On the other hand, there is no other standard that possess such a rigid
and mature architectural framework as STEP. There is a clear requirement to
open up the STEP architectural framework to allow for other standards to
coexist with STEP.
The third item requires some changes to the STEP standard, in order to treat an
information product (a document, a publication, an electronic book, etc.) as a
product in its own right. When those changes have been implemented, information
products may be stored in a STEP environment, and will automatically benefit
from the STEP product definition facilities in item one above, such as full
life cycle support, versioning, etc. And this is something that many SGML
projects are struggling with today, using proprietary formats, databases or
document management systems.
SGML is designed to model textual information for publishing purposes. It has
demonstrated its capabilities and usefulness, and is a stable standard. HyTime
has superior capabilities to link practically anything with anything, and it is
the only existing standard for hypermedia.
The role of the SGML family of standards is identified as the following:
- To represent the information structures involved in product
documentation, including classification and identification of types of
documents or information, and support for all types of character code sets,
special glyphs, and different language constraints.
- To extend the definition of product data to include product documentation.
- To act as an implementation form (in STEP terminology), or an interchange
form (in SGML terminology) for extended product data, thereby becoming an
interface between product data and an electronic or traditional publishing
environment.
- To provide arbitrary referencing capabilities.
The first item is what SGML is designed to do, and what STEP has not succeeded
in doing as well.
The second item places product documentation in its full sense into the product
data domain. This is a natural extension of what is already being modelled with
STEP today, and it is likewise an extension to the integration efforts of
documentation and logistics support data. In short, this would be a significant
step towards real integration of all product related information.
Item three will make it possible to export product documentation from a STEP
environment into an SGML environment, which is required if the documentation is
going to be processed and printed, or displayed. To achieve this, an SGML
compliant STEP implementation form, equivalent to the STEP part 21, has to be
defined.
The fourth item is possible due to the capability of HyTime to link together
two (or more) objects of any type, stored in any format. In the STEP
environment today, relations must be defined in the data model. With HyTime it
is possible to create links (and thereby relations) between arbitrary STEP data
(or other type of data). This might be of interest for very rare relations in
order to optimise the performance of the system.
The SGML_STRING is an information structure defined as an EXPRESS construct
(see diagram).
This structure allows the storing of SGML text as well as providing references
to the necessary SGML constructs.
The architecture of the SGML_STRING includes:
- content
- references to SGML constructs
The content of the SGML_STRING is a string (sequence) of character codes. These
character codes may include the character codes that SGML recognises as
defining mark-up (tags). Since SGML in itself may use any character code set
(not limited to ISO 10646), the content is of type BINARY.
The SGML_STRING references a DTD fragment which defines any of the mark-up
codes found in the SGML_STRING content. As well, it provides a reference to the
SGML declaration, and to HyTime processing instructions in the case HyTime is
being used.
The introduction of the SGML_STRING construct into the STEP resource models
permits the definition and utilisation of SGML text strings as STEP objects.
This allows the STEP compliant product models to contain text which can be used
to (automatically) produce SGML documents, e.g., for publishing documents.
The users of STEP applications will be able to combine SGML text along with the
design / manufacturing / production data. For example, the design of a
component, such as an airplane wing can be directly coupled to textual
information describing any relevant aspects of the design. This information can
be added to and modified throughout the component's life cycle. And,
at any time in the life cycle, this information can be exported to an SGML
environment for publication.
The ability to define SGML "products" in the STEP environment
opens up the possibilities of tapping in to the broad spectrum of STEP
associated applications, such as advanced modelling, automatic database
generation, workflow, versioning, etc.
The ability to integrate SGML and STEP data will allow the production of
products and documentation to be combined into one, well-managed environment,
completely defined by accepted and widely used ISO standards. It will allow the
integration of the documentation of the design, production,
maintenance; the whole life cycle of a product to be an integral part of
the actual product. Thus the production of documentation will not only be more
closely tied with the actual product, but publications will be more timely and
more accurate as they will incorporate actual product data. As well, the
documentation will become a component of the product, accompanying its changes
from version to version and being (semi-)automatically updated with every
change. Input to the documentation will be more readily available and the data
will be more relevant.
The SGML_STRING will be used in the definition of standard STEP APs
(application protocols) and will thus be automatically configured as part of
the products defined by these standards.
During the design, production, etc. phases of the product life-cycle the
designers, engineers, documentors, etc. will add documentation, in the form of
SGML_STRINGS, to the appropriate components of the product.
During the phases of the life-cycle where documentation is produced, for
example where the product is instanciated from the database, the documentation
will also be instanciated together with the appropriate STEP data (transformed
into character codes). The instanciated documentation file can be exported (via
the new SGML-compliant Step implementation form) to an SGML environment where
it can be published, parallel to the production of the actual product.
The addition of the SGML_STRING to the STEP environment will allow the
integration of the STEP and SGML family of standards. The advantages of the
integration will permit users to integrate the documentation of products into
the life-cycle of the product itself and the documentation will become just
another component of the product, following the life-cycle as any other
component.
An example of how document modelling might be achieved in STEP is shown in the
diagram below, using EXPRESS-G;
There are two reasons to propose changes to the currently existing STEP
resource models:
- to enable the utilisation of the SGML_STRING construct introduced
above in future STEP APs,
- to make the STEP resource models more suited to deal with
information products, such as product documentation.
To make the functionality of the SGML_STRING construct available throughout
STEP, it would be best to replace all references to the type STRING in
attributes defining descriptive text (such as the attributes called
"description" in all resource models) by references to a construct,
which can be either an SGML_STRING or a simple STRING. Such a construct can be
declared based on the SELECT construct in EXPRESS. It does not only introduce
SGML capabilities into those models but provides a high level of upward
compatibility between the old and the new version of the models in addition.
The current resource models do not support generic versioning, that means the
generation of versions of versions down to an arbitrary level. This is on the
other side a very common feature in publication environments, and also others.
Therefore the next revision of ISO 10303-41, 43, and 44 should take this
requirement into account and come up with a solution where a version_type is
always a subtype of the type of its owner (see the example for PRODUCT and
PRODUCT_VERSION below). Applied correctly, such a structure gives the user the
total control over which version of an object (specific or current) he or she
wants to use.
ENTITY product;
...
DERIVE
current : product := ...;
INVERSE
versions : SET [0 : ?] OF product_version FOR owner;
END_ENTITY;
ENTITY product_version
SUBTYPE OF (product);
owner : product;
...
END_ENTITY;
STEP is currently supporting multiple PRODUCT_DEFINITIONs per PRODUCT_VERSION
and multiple PRODUCT_REPRESENTATIONs per PRODUCT_DEFINITION. As the
introduction of SGML capabilities is into STEP is opening up the door for at
least one more representation technology, it might be appropriate to do the
following changes in ISO 10303-41:
- A mechanism should be introduced to allow building up a
PRODUCT_DEFINITION from several components, called "PRODUCT_DEFINITION_UNIT" in
the following.
- Specialisation's of the PRODUCT_DEFINITION_UNIT should allow to
combine different views into a single PRODUCT_DEFINITION, such as:
MECHANICAL_DEFINITION
FUNCTIONAL_DEFINITION
ELECTRICAL_DEFINITION
- Specialisation's of the PRODUCT_REPRESENTATION should allow to
distinguish between product representations based on different representations
technologies, such as:
SHAPE_REPRESENTATION
SGML_REPRESENTATION
VIDEO_REPRESENTATION
- A many-to-many relationship between the entities
PRODUCT_DEFINITION_UNIT and PRODUCT_REPRESENTATION will then provide the
capabilities to have elements such as:
a SGML_REPRESENTATION for a
FUNCTIONAL_DEFINITION
a SHAPE_REPRESENTATION for a SHAPE_DEFINITION
a
VIDEO_REPRESENTATION for a ELECTRICAL_DEFINITION
Both, the SGML and the STEP world must accept, that the other standard family
exists, is standardised internationally (by ISO), and has implementations and a
user community on its own.
It is under the circumstances above unreasonable to assume that one standard
will eventually provide all of the other standard's functionality in addition.
But there are on the other side requirements, which can only be fulfilled
today, if the functionality of members of both families of standards can be
used in a co-operative way, such as:
- the support of the automation of process chains from design,
development, and manufacturing to documentation and publication, associating
SGML functionality with all levels of a product structure and allowing for the
generation of adequate publication structures from that.
- to treat product documentation as the inherent component of a
product, that it in fact is.
To achieve this, an information flow between STEP environments (dealing with
product data) and SGML environments (dealing with publication data) must be
established in both directions. This could be done based on the existing data
exchange formats, which already exist, both formats function properly in the
cases of STEP to STEP and SGML to SGML communication respectively. But it would
be an unnecessary burden for an SGML environment to be forced to extract the
data relevant for it from a STEP exchange file. Using the SGML exchange file
structure on the other side provides the additional capability to use e.g. the
DSSSL mapping language to describe the necessary mapping from such an exchange
file into the structures supported natively within the target SGML environment.
The new implementation form is an SGML-conformant encoding of data in a
STEP-compliant structure. It is therefore an SGML-compliant interchange format,
the structure of which is derived from two sources:
- the EXPRESS schema describing the STEP data to be exchanged
- the tags used to mark-up SGML data within the STEP data to be
exchanged.
As such, it enables the import of STEP data into an SGML environment and to
process them there using SGML tools, as well as to prepare information products
based on SGML and to store and archive them in association with the pertinent
product information.
The new implementation form will work between STEP and SGML environments in
exactly the same way as STEP exchange structures (according to ISO 10303-21)
work between STEP environments, and SGML marked-up files between SGML
environments. This means, that a STEP environment will generate an exchange
structure according to the new working form in order to make STEP data
available to a publication environment based on SGML. This exchange structure
will then be mapped into the structures supported by the receiving system using
SGML tools, such as a mapping processor based on the SGML mapping language
DSSSL. After that it can be processed in the SGML environment without
restrictions.
In the opposite direction, a DSSSL based mapping processor can generate an
instance of this new implementation form restructuring SGML data to become
structurally compliant with the an EXPRESS schema, such as a STEP AP. This will
then be loaded into the STEP environment for on-line storage, further
processing, or archival.
A number of activities have been defined in order to accomplish the goal. The
immediate steps are to introduce the concept to ISO and the STEP, SGML, and
CALS communities, and to demonstrate the functionalities in a series of
prototypes. The activities will be kept together as an open SWEDCALS project.
The purpose of this SWEDCALS project is to establish the interoperability
between the standards as outlined in this white paper, with a high degree of
user participation, in order to ensure that the real business needs of the
industry today are incorporated into the solution. The industry will start
using these solutions today, due to the urgent needs, but requires that the
standardisation work is being driven in the same direction.
The first prototype project should demonstrate the basic concepts of the
SGML_STRING.
SGML data will be stored in an existing STEP environment with STEP data, as a
series of SGML_STRINGS. These will be modelled in the STEP environment to form
an information product, e.g. a book. The information product will be managed as
any other product in the STEP environment. Finally, the information product
will be exported from the STEP environment as an SGML file, and produced using
an SGML system.
Other prototypes will follow this first one, each exploring further into the
solution and becoming more practical in the sense that they will address real,
existing user requirements, and possibly the will be built on real user data.
Due to the need of changes in the STEP standard, the SWEDCALS project will also
work to convince others of the benefits. Presentations will be held at major
CALS, SGML and STEP events, results will be published, and prototypes will be
demonstrated.
A preliminary plan for the SWEDCALS project is shown below.
In parallel to the SWEDCALS project, the work of STEP committees and working
groups will continue. We hope to have a close co-operation, and some persons
will take part both in the committee work and in the SWEDCALS project.
In order to make the solution accepted as a part of the STEP standard, a lot of
hard work remains, and we have identified the following standardisation
activities.
It is essential that the SDAI always use persistent object identification.
Without it, it will not be possible to link between SGML and STEP in an
interactive environment.
The existing SDAI is being commented upon now, and the issue has already been
pointed out by Germany, Sweden and the United States.
The proposed changes to the STEP resource models have been discussed in this
white paper.
It is essential that those changes are incorporated in the STEP standard, and
that STEP is opened up as a architectural framework standard for other
standards too.
The SGML_STRING construct presented in this white paper needs to be fully
documented, and ought to be discussed in WG3/T18, as a start.
The SGML_STRING is the central point of this solution to make STEP and SGML
interoperable, and it is therefore of imperative significance that it becomes
part of the STEP standard.
In order to export STEP and SGML data from a STEP environment into a SGML
environment, a new implementation form is most probably required, as discussed
above. The current work have however not explored the details of this new
implementation form, and a lot of work remains here. It is however totally
dependent on the implementation of the SGML_STRING in the STEP standard.
If STEP Application Protocols become combinable (they are not today), it is
possibly interesting to develop an AP for information products. It depends
however on the standardisation items above.