Implementing the IPC­2570 ("PDX") Standards

The IPC-2570 standards were a significant step forward in facilitating product data exchange between supply chain partners. Nonetheless, the standards are not without their flaws.

This topic identifies some of the shortcomings of the version 1.0 published specifications, introduces prospective users to certain pitfalls hiding within the PDX domain, offers practical interpretations for applying the current standards, and suggests some guidelines improving a new generation of PDX standards.

Implementers should also note that not all PDX generators have closely followed the specification. You'll find some "compliant" files may ignore #REQUIRED attributes, exclude some attributes, or otherwise deviate from the IPC standards. This topic is examined in IPC-2570 & Agile PDX files.

We'd appreciate learning about your own experience working with these standards. Please contact us.

1 Introduction

When IPC-2571 (2001) and its associated standards for product data exchange ("PDX") were issued, they addressed a pressing need for establishing a common approach to moving design and manufacturing data between computer systems. As was stated in the introduction to IPC-2571:

The Product Data eXchange standard provides a way to describe product content (Bill of Materials (BOM), Approved Manufacturer Lists (AML), Drawings, etc.), Engineering Change Requests (ECR), Engineering Change Orders (ECO) and Deviations in an eXtensible Markup Language (XML) format. This standard will enable dramatic efficiency improvements throughout the supply chain since partners will have a way to exchange product content and changes in a common language.

While the standards realized significant benefits for PLM users and tool vendors, they also reflect the state of the art of the late 1990s, and in fact embody usage assumptions and conventions of PLM tools dating from 20 years ago. Furthermore, since many of the attributes rely on pre-existing tools, the attributes were "self evident" to the authors; consequently, XML element and attribute descriptions can be ambiguous to those who must apply the standard to new PLM tools and within supply chains that don't use these older tools.

1.1 IPC-2570 series standards

The IPC-2570 series of standards were developed and published by IPC Product Data Exchange Task Group (2-15a) of the Supply Chain Communication Subcommittee (2-15) of IPC. As stated within the standard itself (page i):

The IPC-2571 standard defines an XML encoding schema that enables a total product definition to be described at a level appropriate to facilitate supply chain interactions.

The development committee included representatives from academia, product engineering firms, contract manufacturers, electronic component suppliers, other standards bodies, and PLM tool suppliers.

The first three standards — IPC-2571, IPC-2576, and IPC-2578 — were adopted by the American National Standards Institute in November of 2001.

1.2 The PDX file format

A so-called PDX package consists of an XML file conforming to the standard's Document Type Definition file format (IPC-2571.dtd), and zero or more electronic file attachments (typically CAD, spreadsheet, or other design data); all files are compressed into a single file using an industry-standard algorithm. This compressed file, with .pdx file extension, can then be transferred between compliant computer applications, as well as being read using stand-alone PDX viewers (e.g., Agile eXpress, PDXplorer).

2 Design issues in the current PDX standards

The IPC-2570 series standards seem to have been largely influenced by PLM tools existing at the time, and reflect some of the unique implementation decisions of those tools' designers. To achieve system interoperability, designers of conforming products will be constrained by this history, and must navigate the following points.

2.1 Data elements

Implementing any standard is most efficient when there's a close mapping between system business objects and representative elements within the standard. Regrettably, it seems that the most efficient means for constructing the PDX standard was simply to document existing PLM tools, begging the question whether those tools truly represented the best possible object model.

The result is that the IPC data model exhibits some weaknesses, and consequently is not easily implemented by tools that don't closely follow the original PLM designs.

2.1.1 Inappropriate business object abstractions

Some business objects are combined into single elements. For example, the Contact element (IPC-2571, 9.1) is a single entity that's applied as both persons and organizations. More commonly, a set of persons may belong to an organization, but not vice versa, and this relationship is more often represented in a hierarchical schema rather than as the de-normalized PDX representation. In any case, the contactName is ambiguous and its value depends largely on which element invokes the Contact element.

Conversely, the IPC standard artificially segregates a single concept – a part – into three distinct elements (Item, ManufacturerPart and SupplierPart) depending on the part owner's role in the supply chain.

2.1.2 Inefficient element hierarchy

Certain elements are logical descendents of other elements, yet the IPC standard does not acknowledge the relationship. For example, the AsBuiltProduct element (IPC-2576, 5) more appropriately belongs as a sub-element of the Item element (IPC-2578, 4.1). As such, many of the redundant attributes for both AsBuiltProduct and ProductInstance could have been avoided.

2.1.3 Vaguely-defined data elements

A few elements are documented without being defined. For instance, it's not at all clear how a Configuration element (IPC-2576, 7) is used. It may describe a product "model" in the context of a marketing configuration (i.e., a specific set of features), or may identify a product baseline (a specific set of items).

2.1.4 Incomplete data elements

An item is minimally identified by its (a) owning organization and (b) the identifying number assigned by that organization. (Historically, in defense contracting, this was CAGE and PIN, respectively.) Curiously, IPC misses the owning organization in the AlternateIdentifier element (substituting the difficult-to-apply "description of the numbering scheme"), and even the basic Item element (IPC-2578, 4.1) only offers the ownerName and ownerContactUniqueIdentifier as optional attributes.

A number of common business object attributes should not be relegated to the AdditionalAttributes elements. For example, Contacts will invariably have a unique activity status (Active, Primary, Alternate, Inactive) and an open-ended list of contact methods (Phone, Fax, Mobile, Email, Chat, etc.).

2.1.5 Undefined/unused data elements

The 2571 DTD specifies a Role element as <!ELEMENT Role (#PCDATA)> but it is not referenced by any other element, and none of the IPC-257x standards define its purpose or use.

2.2 Element attributes

Element attributes provide details about the business objects. These details should coherently support machine-level data exchange (using concepts like abstraction, uniqueness and referential integrity) and, perhaps only incidentally, human readability (enforcing naming conventions). To be truly useful, all attributes should be clearly defined and without redundancy.

2.2.1 Inconsistent Required versus Implied attributes

One of the difficulties of the current standards is that some attributes are oriented towards maintaining machine coherence via a required ID attribute; other ID attributes are #IMPLIED while CDATA values are #REQUIRED to facilitate human readability (e.g., compare IPC-2578, 4.1 with IPC-2578, 10.1).

In a somewhat different example, Contacts (IPC-2571, 9.1) may be used to define either organizations or persons but the data necessary to support this dual role may not always be required. For instance, a principal usage is to identify a manufacturer (IPC-2578, 9.1) or supplier (IPC-2578, 10.1) without regard to the existence of a person. Nonetheless, the PDX standard specifies that businessName is optional.

Similarly, some elements require attributes while others make the identical attributes optional. Consider, for instance, the requirement for a part manufacturer's name: in ApprovedManufacturerListItem (IPC-2578, 9.1) the manufacturedBy attribute is optional, while in ManufacturerPart (IPC-2578, 18.1) manufacturerName is required.

2.2.2 Inconsistent naming conventions

As cited in the preceding example, the attribute names manufacturedBy and manufacturerName serve the same purpose and presumably contain the same data.

Similarly, the Item (IPC-2578, 4.1) ownerName should be equally applicable to all other instances where there exists an item ownership role, such as the ManufacturerPart (IPC-2578, 18.1) owner.

2.2.3 Redundant or irrelevant attributes

One of the principal ideals for data exchange should be to create exactly one instance of an attribute. Redundant attributes offer the unhappy potential to be in conflict with other instances of the same information. For example, a BillOfMaterialElement (IPC-2578, 6.1) replicates a revisionIdentifier from the associated Item (IPC-2578, 4.1) element's revisionIdentifier.

Irrelevant attributes nonetheless require implementation effort. Given that all contacts are directly under the ProductDataeXchangePackage element, and there's no contact hierarchy defined, there's little need for the isTopLevel attribute in a Contact element.

2.2.4 Inappropriately-assigned attributes

Certain enumerated values defined by IPC-2578, Section 6.1 (at globalBillOfMaterialTypeCode) are more relevant to the BillOfMaterial, rather than BillOfMaterialItem, element. As noted in the standard, the "BillOfMaterial element is a collection of BillOfMaterialItem elements that describes an assembly, kit or a single item." The BillOfMaterialItem enumerations such as EndProduct, Subassembly, PhantomSubassembly, and Kit more appropriately describe the entire BillOfMaterial.

The supplierPartUniqueIdentifier within ApprovedSupplierListItem is defined as being an ID, but seems more properly to be an IDREF. The intent appears to mirror the  ApprovedManufacturerListItem / ManufacturerPart relationship. If this attribute is an ID, then neither it nor the SupplierPart element's supplierPartUniqueIdentifier has any useful purpose.

2.2.5 Overly complex set of attributes

The standard defines functionally-equivalent attributes within an element. Consider that a Change (IPC-2578, 12.1) is undifferentiated except via the changeType attribute. However, there are distinct requestReason and changeReason attributes, as well as separate changeRequestDescription and description attributes. These pairs are mutually exclusive between ECRs and ECOs, and one of each can be dropped.

2.2.6 Undefined, ambiguous or incomplete attributes

A few attributes are not easily deciphered from the standard. For example, the Approver (IPC-2578, 13.1) element's approverWorkflowStatus attribute is described as the "identifier of the status of the workflow that is being signed off".

In other instances, similar attributes can be distinguished only after some debate. A Change (IPC-2578, 12.1) has optional attributes indicating changeOriginatedByName and changeOwnerName. Perhaps the former is the person who created the change, while the latter is the change's sponsoring organization.

2.3 Attribute enumerations

Enumerations are intended to provide a set of well-defined constraints; the members should be both necessary and sufficient. In addition, their application should be well-defined or commonly-understood.

2.3.1 Unnecessary enumerations

The enumerations in the globalEngineeringChangeStatus attribute of Change (IPC-2578, 12.1) element offer substantial overlap: IssueIdentified / UnderInvestigation, Implemented / Completed and ChangeRequested / ChangeOrderProposed all appear redundant. Similar redundancies appear in other attributes.

2.3.2 Insufficient enumerations

Given the extensive use of currency in product information, the AdditionalAttribute element (IPC-2571, 10.1) should include an enumerated value of Currency in the dataType attribute, with the ISO 4217 currency code carried in the dimension attribute.

Commonly-encountered states also seem to be missing, e.g., a Canceled selection in the globalEngineeringChangeStatusCode attribute of Change (IPC-2578, 12.1).

2.3.3 Undefined enumerations based on implicit data types

The IPC standard identifies, but fails to define, certain data types. For example, in IPC-2571, section 10.1, representation ranges of Float and Double are undefined and various computer systems will have differing interpretations.

Although units of measure are used throughout the specification, a permissible set or recommended source is not provided. One solution would be to adopt a standard set of units of measure, such as ANSI ASC X12 Data Element 355 and/or UNECE Recommendation No. 20, Codes for Units of Measure Used in International Trade.

2.3.4 Undefined enumerations based on implicit business rules

In Item (IPC-2578, 4.1), the purpose of globalLifeCyclePhaseCode is to indicate a set of business rules for committing company resources to an item. Until the IPC explicitly defines a business rule for each enumerated value, the terms should have intuitive or commonly-used meanings.

• Conditional is really an adjective for another state (e.g., "conditional production"), which means "restricted". It would seem that any Conditional lifecycle phase is simply a limited form of a subsequent phase. Moreover, items cannot have a Conditional phase if the standard does not provide a method for specifying the associated restrictions.
• In practice, Preliminary and Design are usually synonymous.
• Pending typically modifies a state (phase), and is not generally used as a state itself. For example, "pending release" or "pending cancellation" indicates an awaited change in state.
• Unqualified modifies any phase ("unqualified for pilot", "unqualified for production") and may not be a distinctly useful lifecycle phase.
• Similarly, Disqualified generally means "do not use", and could simply be replaced by the already-existing temporary (Inactive) or permanent (Obsolete) values.

Other enumerations with undefined business rules include ApproveWithConditions, UnderQualification, and Nonpreferred.

2.3.5 Undefined order for sequential enumerations

The purpose of globalLifeCyclePhaseCode is to indicate a set of business rules for committing company resources to an item. Since a company's commitment usually increases over time, the enumerations implicitly suggest a specific order of assignment, from Design through Obsolete. However, the order isn't documented and, in a few cases, the implied order of the enumerations is doubtful, e.g., Production, Pending, Inactive.

3 Recommendations for a practical PDX implementation

Many of the difficulties identified in the previous section cannot be easily addressed within the confines of the existing standards. However, some issues do lend themselves to intuitive clarifications. We offer some suggestions that, while conforming to the standards, provide some degree of implementation consistency.

3.1 Proposed definitions and usage

The goal of any standard is reduce implementation-specific negotiation of common attributes. To reduce ambiguity, we propose the following shortcuts to implementation.

Table 1: Proposed element and attribute definitions

Location	Attribute name	Recommendation
2571: 9.1	contactName	When a Contact is referenced  as an approver, owner, originator, or user in Approver, Change, HistoryItem, Item, ManufacturerPart, ProductDataeXchangePackage, SupplierPart), this is the person's name. Otherwise, in ApprovedManufacturerListItem, ApprovedSupplierListItem, ManufacturerPart, SupplierPart, use the business name of the manufacturer or supplier.
2571: 9.1	businessName	Treat as #REQUIRED
2571: 9.1	isTopLevel	Set as Yes only when the Contact element refers to PDX package originator.
2571: 10.1	dimension	AdditionalAttribute should use ANSI ASC X12 Data Element 355
2576: 8.1	manufacturerUnitOfMeasure	Lot should use ANSI ASC X12 Data Element 355
2578: 4.1	itemClassification	Item classes are typically the PLM system's first class objects such as Document, File (i.e., Attachment), Part and Change. With Changes and Attachments having their own dedicated elements, this value can be a simple Part | Document enumeration.
2578: 4.1	globalProductTypeCode	By convention amongst existing PDX generators, this seems to be assigned the item subclass, such as Part Assembly or Document Specification.
2578: 4.1	description	Throughout the IPC standards, this attribute is often most useful as the part name or document title.
2578: 4.1	versionIdentifier	Define "version" as an optional alias for an item revision, and exists only in conjunction with a revision. For more details, see Reference 6.
2578: 4.1	globalLifeCyclePhaseCode	Avoid vague or irrelevant business rules enumerations: Conditional, Preliminary, Pending, Unqualified, Disqualified
2578: 4.1	globalProductUnitOfMeasureCode	Adopt ANSI ASC X12 Data Element 355
2578: 4.1	ownerContactUniqueIdentifier	Treat as #REQUIRED
2578: 6.1	proprietarySequenceIdentifier	BillOfMaterialItem row or "Find" number
2578: 6.1	billOfMaterialItemUniqueIdentifier	Treat as #REQUIRED
2578: 6.1	globalBillOfMaterialTypeCode	Apply the bill of material parent assembly's BOM type code value.
2578: 6.1	globalProductUnitOfMeasureCode	There isn't one; the standard assumes all BOM quantity have "each" as the UoM. It's a good idea use an AdditionalAttribute to explicitly specify each row's UoM.
2578: 8.1 & 9.1	globalPreferredStatusCode	AlternateItem and ApprovedManufacturerListItem: (a) integer value of 1 or greater, (b) the code of 1 represents the most preferred item, and (c) the code need not be unique within the list of elements.
2578: 9.1 & 10.1	manufacturerPartUniqueIdentifier supplierPartUniqueIdentifier	ApprovedManufacturerListItem and ApprovedSupplierListItem: Treat as #REQUIRED
2578: 9.1 & 10.1	manufacturerContactUniqueIdentifier supplierPartContactUniqueIdentifier	Treat as #REQUIRED
2578: 9.1, 10.1, 18.1, 19.1	globalSupplierPartStatusCode globalManufacturerPartStatusCode	ApprovedManufacturerListItem, ApprovedSupplierListItem, ManufacturerPart and SupplierPart: Avoid vague or redundant business rules enumerations: Conditional, Nonpreferred, UnderQualification
2578: 12.1	changeType	A Change either releases/cancels affected items (Notice) or does not (Request).
2578: 12.1	changeSubType	This is the organization-specific subclass objects: ECR, ECN, ECO, MCO, etc.
2578: 12.1	requestReason	An enumeration or summary of the source of the original problem or request.
2578: 12.1	changeReason	An enumeration or summary of why the change is required.
2578: 12.1	description	The primary discussion of the change and its impact.
2578: 13.1	globalEngineeringChangeStatus	Avoid vague or redundant business rules enumerations: Waive is an invalid response where globalApproverTypeCode is required, and irrelevant in all other cases; the effect of ApproveWithConditions is undefined on the change's approval status.
2578: 18.1	manufacturerName	Use Contact.businessName

Table 2: Proposed "essential" enumerated values

Location	Attribute name	Recommendation
2578: 4.1 & 11.1	globalLifeCyclePhaseCode	Design | Prototype | Pilot | Production | Inactive | Obsolete | Other
2578: 6.1	globalBillOfMaterialItemTypeCode	DirectMaterial | IndirectMaterial | Setup | Reference | Other
2578: 9.1 & 10.1	globalSupplierPartStatusCode	Unqualified | Approved | QualityHold | Disqualified | Other
2578: 18.1 & 19.1	globalManufacturerPartStatusCode	Unqualified | Approved | QualityHold | Disqualified | Other
2578: 11.1 & 12.1	globalEngineeringChangeStatusCode	IssueIdentified | ChangeOrderProposed | ApprovalPending | OnHold | Rejected | Approved | Released | Completed | Other
2578: 11.1 & 12.1	changeType	Notice | Request
2578: 14.1	disposition	UseAsIs | DepleteStock | HoldForOtherUse | Rework | ReturnToVendor | Scrap | Other

3.2 Avoided attributes

Some aspects of the current standards are too vague to implement with confidence. In these instances, it's safer for implementers to avoid using these attributes until the IPC issues more definitive descriptions of their application.

Table 3: Avoided attributes

Location	Element name	Attribute name
2578: 12.1	Change	changeRequestDescription
2578: 12.1	Change	workflow
2578: 13.1	Approver	approverWorkflowStatus

3.3 File attachments

Because file attachments have not been clearly defined within IPC-2571, element 8.1, varying implementations now exist. In the tables below, we try to reconcile these implementations within the existing definitions.

Table 4A: Proposed file attachment attribute definitions, IPC-2571, 8.1: isFileIn = Yes

Attribute name	Type	Required?	Description
referenceName	CDATA	#IMPLIED	User-specified source filename, e.g., abc.txt, that should be assigned to extracted file.
universalResourceIdentifier	URI	#REQUIRED	since file:// is regularly ignored in many implementations, it seems PUID & filename is sufficient
fileIdentifier	CDATA	#IMPLIED	Package-unique identifier (PUID) as generated by file packaging routine. This value is undefined by the IPC standard, but could be a package-level sequential value, an application-level file name, or a GUID.
versionIdentifier	CDATA	#IMPLIED	Application-specific file version, usually an integer
fileSize	CDATA	#IMPLIED	Integer byte count without formatting, e.g., 1675713
checkSum	CDATA	#IMPLIED	MD5 hash per RFC1321
isFileIn	Yes | No	#REQUIRED	YES: Indicates that file is included in PDX package
description	CDATA	#IMPLIED	File description
globalMimeTypeQualiferCode	CDATA	#IMPLIED	Although IPC-2571, section 8.1 explicitly defines this as a MIME type (e.g., application/msword), PDX generators often use the filename extension without delimiter (doc). If this field is used, the content must be explicitly agreed or the receiving system should be prepared to accept either MIME or extension.
attachmentModificationDate	CDATA	#IMPLIED	ISO8601 UTC date time 2012-05-03T03:07:21Z

Table 4B: Proposed file attachment attribute definitions, IPC-2571, 8.1: isFileIn = No

Attribute name	Type	Required?	Description
referenceName	CDATA	#IMPLIED	User-specified source filename, e.g., abc.txt
universalResourceIdentifier	URI	#REQUIRED	URL scheme and name, e.g., ftp://any.com/abc.txt, https://www.any.com/abc.htm
fileIdentifier	CDATA	#IMPLIED	The standard specifies that this attribute is used as a key to distinguish otherwise identically-named files, which suggests that it's only relevant when isFileIn is Yes. Even so, some PDX generators assign an integer value to this when isFileIn is No.
fileSize	CDATA	#IMPLIED	Empty value, as this value may refer to a web page or other resource where size cannot be known or enforced.
isFileIn	Yes | No	#REQUIRED	NO: Indicates that file is not included in PDX package

Procedurally:

1. File is included in package (isFileIn is Yes)
   1. Assign the source (human-assigned) filename to referenceName: abc.txt
   2. Generate a package-unique identifier (PUID), and assign it to fileIdentifier: f000143
   3. Assign fileIdentifier.referenceName to universalResourceIdentifier: f000143.abc.txt
   4. Copy the source file into the PDX package using the fileIdentifier.referenceName: f000143.abc.txt
   5. Copy the file's byte count, as an unformatted integer, into fileSize.
   6. Format the attachmentModificationDate as ISO8601 for date time converted to UTC, e.g., 2012-05-03T03:07:21Z
2. File is referenced (isFileIn is No)
   1. Assign the source (human-assigned) filename to referenceName: abc.txt
   2. Assign nothing to fileIdentifier.
   3. Assign the complete URI scheme and name (ftp://any.com/abc.txt, https://www.any.com/abc.txt) to universalResourceIdentifier. This contains only whatever is likely to be obtained by a non-originating user. If the universalResourceIdentifier is not likely to be accessible by the PDX recipient, then the path information is omitted. For example, if the file can be obtained via ftp://, https://or https://, then the full path is included; if it's a private resource (say, D:\path\ or \\servername\path\), then just use file:// as the prefix.
   4. Assign nothing to fileSize.

4 Guiding principles for revision of product data exchange formats

The standards as currently published could be significantly improved by adopting appropriate "big picture" goals to guide committee work. Revisions to the PDX standards under these rules may offer wider adoption of the standards, with less effort by implementers seeking broad interoperability.

These goals should be embodied in future revisions:

1. Reduce business partner case-by-case negotiations of attribute interpretation by more crisply defining the meaning and intent of attributes.
2. Reduce application complexity by defining (and applying) a more generalized set of global enumerations. Each unique set of enumerated values must be managed within an ERP or PLM application, and generally requires a separate database table or other mapping mechanism. Reducing the number of sets reduces development complexity and user confusion.
3. Reduce the number of enumerated values for a specified attribute. Certain IPC enumerations suggest a particular set of business rules, but it's presumably beyond the scope of the IPC standard to explicitly define these rules. For example, there may be no physical difference between an item with a globalLifeCyclePhaseCode of Pilot, and the identically-identified item at Production. The distinction is purely in how the item can be used within a specific supply chain at various points in its lifecycle. Therefore, we recommend a significant reduction in enumerations that represent undocumented differences in business rules, at least until IPC chooses to make the difference explicit.
4. Improve understanding by establishing, where appropriate, unambiguous ordering of enumerations, such as in the globalLifeCyclePhaseCode.
5. Add, where appropriate, new elements that abstract common business objects. There are real benefits to (a) distinguishing between people and organizations, (b) identifying and managing documents that are a necessary part of the manufacturing process, and (c) providing for variable collections of contact methods to coincide with the variety of real-world communications channels.
6. Eliminate redundancies and potential for error by making IDREF attributes, rather than their human-friendly identifiers, as #REQUIRED; this reinforces the IPC standards' role as primarily machine-to-machine data exchange mechanisms. In our view, the relationship is correctly specified in, e.g., the AlternateItem element (IPC-2578, 8.1) but is incorrect in AffectedItem (IPC-2578, 14.1). It should never be acceptable for both identifying attributes to be #IMPLIED (e.g., billOfMaterialItemIdentifier and billOfMaterialItemUniqueIdentifier, IPC-2578, 6.1).
7. Eliminating some attributes or enumerated values may affect deployed systems, but AdditionalAttributes elements and xxxCodeOther attributes, respectively, can be used as easily for constraining the standard as for expanding it.

5 Conclusions

The IPC-2571 series standards were envisioned to promote a comprehensive and predictable data exchange between computer applications that manage product design data. While the standards have provided a reasonable starting point, their essential function in providing a unifying view of computerized product data has not been fully realized due to ambiguities in implementation.

Rather than argue for a complete revision of the data elements, the IPC committee could make the standards more robust simply by enhancing the documentation: improving element and attribute descriptions, clarifying the intent of various enumerations, and defining default business rules.

References

1. IPC. (2001) IPC-2571 Generic Requirements for Electronics Manufacturing Supply Chain Communication - Product Data eXchange (PDX)

2. IPC. (2001) IPC-2576 Sectional Requirements for Electronics Manufacturing Supply Chain Communication of As-Built Product Data - Product Data eXchange (PDX)

3. IPC. (2001) IPC-2578 Sectional Requirements for Supply Chain Communication of Bill of Material and Product Design Configuration Data - Product Data eXchange (PDX)

4. ANSI Accredited Standards Committee. ASC X12 Data Element 355

5. UNECE Recommendation No. 20, Codes for Units of Measure Used in International Trade

6. Product-Lifecycle-Management.com website. Terminology: revision or version?