SGML environments are better suited to the design and production of instances of product documentation representations. The format and structure of SGML is singularly well suited for the manipulation and handling of documents intended for presentation. There exists a solid and well functioning set of support software tools and applications backing SGML environments.
However, contrary to many other data forms, such as design, manufacturing, accounting, personnel records, etc., the management and storage of documentation has not enjoyed the luxury of systematic organization tools such as database management, life-cycle support, etc. Thus the management of the life-cycle support, such as version control, is more likely to be better fulfilled in a STEP-compliant environment.
Thus the problems of product documentation management should be solved within the STEP environment. This requires facilities for:
To overcome the above mentioned problems, T14 proposes the following:
Fundamental to the integration between the two environments is:
It is evident that STEP environments will include functionality for the management of a total life-cycle of product documentation. As this is not the case in most SGML environments, the management of product documentation should be within the STEP environment. This integration of product data and product documentation requires that representations of product documentation be able to be modelled with STEP tools.
Note however, that this does not mean that documentation will be completely modelled using STEP tools. There are two reason for this: one, the SGML environment already includes a modelling language, which is well established with support tools and functions readily available. To "re-invent the wheel" in STEP would be wasteful and would likely never be fully accepted. Two, storing documents at the SGML level of granularity in entities defined in STEP-compliant environments would create a granularity of storage that would make the access impossibly complicated and unrealistic in access time.
T14 is proposing a hybrid approach. SGML-encoded product documentation structures must be able to be modelled within a STEP-compliant scheme. However, product documents need only be modelled in STEP down to the level of generic content descriptions. The content models can be most effectively modelled (and encoded) in SGML.
The hybrid approach allows both whole documents, sub-documents, or just chunks of SGML-encoded data to be modelled in STEP.
The requirement is that a model is developed for the inclusion of SGML-encoded data within STEP schemas.
The export of SGML-encoded data can be accommodated via the Standard Data Access Interface (SDAI ). This is a needed function to extract product documentation that is been managed by the STEP-compliant environment.
As well, because product documentation will often be created externally to a STEP-compliant environments, it must be also possible to store SGML-encoded data produced in these environments into the STEP-compliant repositories.
The access of product data is essential to the writing of product documentation. It must be possible to address, query, and retrieve product data in a number of ways: product structure relations, attribute values, global addresses, etc.
The product data extracted from the STEP-compliant repositories must be converted for use in product documentation. For example, real number values must be converted to character data for presentation. There are a great number of transformations that are applicable to product data, and the requirement is a method for the description of transformations and a conditional operator to specify when the transformation is to be applied.
One of the essential factors needed for interworking of data between to environments is the ability to unambiguously address information objects. Addressing mechanisms must be available for the translation of global addresses to local addresses both in the transfer process and also in "browsing" processes. For example, it must be possible to identify a particular product data entity, such as a tool-number, in a (STEP-compliant) proprietary CAx system. It then must be possible to build up a query using the global address of the tool-number from within an SGML environment so that the correct data can be automatically updated when the document is published.
Similarly, storing items within a STEP-compliant environment must invoke a global address mechanism that can be used to organize, refer to, retrieve, and manage the item within the system.