Parts and Documents

DocumentVersion and PartVersion are representing one of the most fundamental key concepts of the VEC. They are the only classes in the VEC model that are defining version information. In combination with the attributes companyName and partNumber or respectively documentNumber they define an unambiguous context for data exchange. If two instances of the VEC are containing PartVersions or DocumentVersions with equal values of the attributes companyName, partNumber and partVersion or companyName, documentNumber and documentVersion, then the two objects can be trusted to be unchanged.

Unchanged in this context does not mean binary identical content of the resulting XML-Subtree, but unchanged user data. So if the content of a DocumentVersion is transferred from one VEC-file to another (e.g. for documents describing part master data), the binary representation can be different (e.g. order of the xml elements, technical ids for xml idrefs), but the information represented by the DocumentVersion must not be different (e.g. property values of a Specification). However, it is explicitly allowed that the scope of the information contained in different instances of the same DocumentVersion may differ. For example, in most processes a component (e.g. a connector) is specified by a technical document, in the VEC represented as a DocumentVersion. In the use case of part master data exchange the VEC for the component might contain very detailed information. For the use case of harness description not all of this detailed information is required (e.g. for a connector the information about slots and cavities might sufficient) and therefore it should not be included. However, the component is still specified by the same technical document. Another example of a scenario where this might occur, is the update of a VEC exporting system. A later export might contain more information, even if the original document has not changed.

These cases are allowed with an unchanged documentNumber, documentVersion, if the shared part of the represented information in both DocumentVersion instances is still consistent.

More specific possibilities to track changes of DocumentVersions are supported by the digitalRepresentationIndex. In some cases, the DocumentVersion represents a version of a real document in the domain. The Specifications in the DocumentVersion represent the values defined in the original document. Thus, the DocumentVersion in the VEC is not a managed document by itself, but only a specific digital representation of another document. In other words, it is only a translation of the original document into the language of the VEC. For example, there is a connector described by a drawing / data sheet, which is available in some arbitrary format (e.g. PDF). This document has a number and a version. When the document is transferred (e.g. with a converter or manual input) into the VEC, the DocumentVersion containing the Specifications might have the same documentNumber and documentVersion as the original data sheet, since it is not a managed document in the process, but only a different representation of the same information. In such a scenario, it is possible that the content of a DocumentVersion changes without a change of the original document (e.g. there was an input error during the manual transfer of information, there is a new version of the converter / exporter and many more). However, the original document has an unmodified DocumentNumber & DocumentVersion. To indicate such (potential) changes of the content of a DocumentVersion the DigitalRepresentationIndex was introduced. DocumentVersions that contain a different amount of information (see above) shall also have different digitalRepresentationIndex values (if defined).

That means, if no DigitalRepresentationIndex is defined, the rules from above apply. If a DigitalRepresentationIndex is defined, the content of the DocumentVersion can only be trusted to be unchanged, if companyName, documentNumber, documentVersion and digitalRepresentationIndex are the same.

Since both classes can define PDM information they are derived from the abstract class ItemVersion.

The differentiation between PartVersion and DocumentVersion in the VEC is necessary, because a part can be described by multiple documents (e.g. a technical data sheet, a drawing and a 3D-model) and one document can describe multiple parts (e.g. a drawing for a contact family that displays multiple terminals and their corresponding seals). As a result a part can, be changed (requiring a new PartVersion) without the need of changing all of its describing DocumentVersions. For example, if a single property of a component changes, a new version of the part itself and its technical data sheet is necessary, but its 3D model might remain unchanged. Another example is, that a document describing multiple parts might be changed (requiring a new DocumentVersion), but in fact only one of its represented parts is changed (requiring a new PartVersion). This relationship between a PartVersion and its describing DocumentVersions is expressed in the model by the association DocumentVersion.referencedPart.

The relationship DocumentVersion.relatedDocument can be used to describe general relationships between DocumentVersions (e.g. the relationship between a technical drawing and a given standard the drawing is compliant with). The composition of SheetOrChapter considers the fact that DocumentVersions may be composed of several sheets or chapters.

The VEC is designed as a format for data exchange. This requires that all content data can be related to a certain unambiguous version context, in order to allow a receiver of the information to easily check if and what has changed since the last data exchange. For this reason, all content data that is not constant is defined with information specific subclasses of the class Specification. A Specification is always contained in a DocumentVersion and thereby related to an unambiguous version context.