PDM-UG: General Information

From WikiSTEP

This page belongs to the PDM Usage Guide.

==Instantiation diagrams== The diagrams are presented using a graphical notation intended to illustrate the instance model. This notation is not EXPRESS-G, however, it does intentionally resemble it. The diagrams do not illustrate the EXPRESS schema, but illustrate a specific population of a particular instance model (or portion thereof) of the schema. A legend for the diagram notation is shown below :Instantiation diagrams: the diagrams are presented using a graphical notation intended to illustrate the instance model. This notation is not EXPRESS-G, however, it does intentionally resemble it. The diagrams do not illustrate the EXPRESS schema, but illustrate a specific population of a particular instance model (or portion thereof) of the schema. A legend for the diagram notation is shown below:

• illustration of entity instances and their attributes;
• identification of optional attributes;
• indication of specific attribute values, typically strings, may be enumerated values;
• identification of other document sections and referenced entity instances not fully illustrated in the current figure;

==Entities and attributes not supported by the preprocessor== For various reasons, there may be some entities that cannot be completely exported by the preprocessor. Sometimes an application may not maintain all the information that is anticipated for the data exchange. Other times, the information may be maintained by a sending system but not included in the data exchange. Never the less, the preprocessor must provide values for all mandatory attributes in an exchange file. For mandatory string attribute values, the null (empty) string '' has often been used when a preprocessor can provide no real user data. The default string value '/NULL' may be used for this purpose, as recommended by the European automotive industry. When no data is provided by a sending system for a string value, the preprocessor should use '/NULL' or the empty string ''. To further indicate the reason why no data is provided, the following convention may be used:

• Empty string '' indicates user data managed by the sending system but not provided for data exchange.
• String '/NULL' indicates user data in a mandatory attribute that is not managed by the sending system or currently not known.
• $ is used in the physical file, if an optional attribute is not instantiated.

It is generally not recommended to use the empty null string '' or the default string '/NULL' as valid user data.

==Entities and attributes not supported by the postprocessor== For various reasons, there may be some entities that cannot be completely imported by the postprocessor. The postprocessor translator implementation simply may not support the import of the entity. The receiving system may not maintain the information that is carried by an entity or attribute, or it may require specific attribute values that are not present in the input data. Entities and attributes not imported should list a reason in a history log file. Entities and attributes not supported by the receiving system should not cause a system failure. The minimum acceptable behavior should be to ignore the unsupported constructs.

==Unspecified and optional attribute values== Optional attributes without specific recommended values, such as the description attribute, are available on many entities in the PDM Schema. In general, use of this type of attribute is given the following recommendation:

• Preprocessor - first, follow the usage guide as much as is possible - if some specific common harmonized user requirement has been documented in the usage guide for the attribute, try to adapt this requirement to those you have identified (i.e., map the standard into your user domain). If no specific common harmonized user requirement has been documented in the usage guide, in general, such an optional attribute should not be instantiated. However, these attributes may be used in some bilateral agreements between exchange partners.

• Postprocessor - any optional attribute with no specific mapping specified, in general, cannot be specifically interpreted in an interoperable way. While these types of attributes are in general not recommended to be instantiated, the postprocessor should gracefully handle any data that is exchanged using these attributes. A robust, interoperable PDM Schema processor will generally provide user access to the values exchanged.

==Derived attributes== In general, derived attributes are not given with the description and recommendations for entities in the PDM schema. This is consistent with the STEP part 21 specification where derived attributes are not represented in an exchange file. Only in certain cases where special attention is required will such an attribute be presented and explained in this usage guide.

==Implementation project specific values== Attribute values recommended in this usage guide should be supported by systems conforming to the PDM Schema. Other values negotiated between exchange partners in specific projects may be used where the interpretation of their meaning does not contradict definitions provided in this usage guide. However, these agreements will not generally be interoperable solutions.

==Leading and trailing blanks in STRING values== All white space within the single quote delimiters of a STRING value should be considered valid user data.

==Uniqueness of identifiers== Identifiers cannot be unique in general. In the parallel management of internal and external identifiers in a database, duplicate identifiers may occur that can cause problems with the uniqueness rules defined in the EXPRESS schema. In those cases, the interpretation of the identifier can be logically extended by a prefix that identifies the organizational scope (id value of the organization related in role 'id owner') to help ensure uniqueness (see product). The unique rule shall be evaluated only in scope of the organization defined by the id_owner. Thus, a processor may utilize the organization identifier as a key to identifying a product.

==Schema version identification== version identification for the PDM Schema shall be encoded in the header section of the STEP Part 21 exchange file to identify the version of the schema to which the file conforms. This is done with the header entity file_schema, which identifies the EXPRESS schemas that specify the entity instances in the data section. The attribute schema_identifiers contains a list of strings that name the schema, optionally followed by the object identifier assigned to that schema. In place of the object identifier, the PDM Schema version identification number shall be enclosed within curly braces. Only capital letters shall be used in schema name strings.

EXAMPLE: To indicate PDM Schema version 1.2, the following instance of the header entity file_schema should be used.

ISO-10303-21;
HEADER;
...
FILE_SCHEMA(('PDM_SCHEMA {1.2}'));
ENDSEC;