Added the following text in Annex D.1.3 to resolve this issue:

AttributeTypes that correspond to their equivalent OPC UA FX DataTypes.
Only use a well-known ReferenceTypeId from standard UA, DI and UAFX AttributeType Libraries in a Descriptor. Do not include vendor Nodeset information in a ReferenceTypeId contained in a Descriptor.

Describe a PortableRelativePath using standard ReferenceTypeIds with allowance to include subtypes.

An engineering tool that is importing a vendor Nodeset, in order to create an AML file, could map a vendor specific ReferenceTypeID to a standard ReferenceTypeID (a “supertype). For example, the PortableRelativePath FxRoot could map to FE1.

For a PortableRelativePath that contains a vendor specific ReferenceTypeId, the engineering tool converts the vendor specific ReferenceTypeId in that PortableRelativePath to a standard ReferenceTypeId. In this scenario, the engineering tool needs to have knowledge of the vendor Nodeset.

Added the following paragraph to resolve issue 8490:

The values of the ReferenceTypeIds contained in the datatype PortableRelativePath need special handling when converting to AML. If the ReferenceTypeId in the nodeset is a vendor-specific type (i.e. not a well-known ReferenceTypeId defined in an OPC UA specification) then the ReferenceTypeId that appears in the AML shall be the ReferenceTypeId of its most-derived supertype that is a well-known ReferenceTypeId defined in an OPC UA specification. When a conversion of the ReferenceTypeId is done then the respective IncludeSubtypes field of the PortableRelativePathElement structure shall be set to true.

reopened

The original resolution to this issue was superseded by the later resolution needed for Mantis issue 8674. Mantis issue 8674 corrected the use NodeIds in the Descriptors that also handled the PortableNodeId and PortableRelativePath issues brought up in this issue. The original resolution had therefore become redundant and not needed. The paragraph in Annex D.1.3 was removed.

OE team agrees to close it