Attribute values

This section describes how to set entities and attributes that are specified in the information model, but not handled by importing / exporting systems.

NOTE    This section has been derived from the "PDM Schema usage guide" (http://www.pdm-if.org/pdm_schema/)

The following string values are used for attributes, as described below and in section General use of assignment entities

Table 1 — Attribute values

Entities and attributes not supported by the exporter

For various reasons, there may be some entities that cannot be completely exported by an exporter. 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 exporter 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 exporter 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 exporter 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 importer

For various reasons, there may be some entities that cannot be completely imported by the importer. The import 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 information model. In general, use of this type of attribute is given the following recommendation:

Exporter - 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. Importer - 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 information model. 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.