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. 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.