In a document-type-specific burst configuration file, the dmsmetadata element is the last child of the createarg element. The dmsmetadata element contains the metadatarule and twowaymetadatarule elements. These elements enable you to use XML attributes or content as values for PTC Server property fields and to use PTC Server property fields as the values for XML attributes or content. You can use both PTC Server global attributes and system attributes for metadata assignment rules. For both one-way and two-way metadata rules, you must use file-based attributes for the associated PTC Server property. If you do not use a file-based attribute, the metadata rule will fail with an error.

Make sure that property assignment rules do not conflict with other PTC Server connection automatic metadata updates. For example, the PTC server might have a template for newly created objects that assigns object property values. Having multiple property update mechanisms might yield unexpected results.

Note that the PTC Server IBA PTC_DD_EXTENDED_DOC_TYPE is reserved for internal use by Arbortext. Do not use this global attribute in any metadata assignment rules contained in your document-type-specific burst configuration file. If you use this global attribute in a metadata assignment rule, your settings will be overwritten in a future release of Arbortext Editor.

Note also that if there is an error during the bursting process in passing the XML attribute values for a graphic object to the PTC Server properties, that graphic object is still added to the PTC Server. In this case, the PTC Server connection writes an error to the burst log, if enabled, or to the Arbortext Editor message window.

You can use system attributes for metadata assignment rules. If you use PTC Sever system attributes, you must use a name for the system attribute in your burst configuration file that the PTC Server connection recognizes. The following table covers the supported PTC server system attributes, the required name for the system attributes in the burst configuration file, and the level of access. System attributes that are read-only can only be used in a twowaymetadatarule burst configuration file rule where the mode is toxml.

Note that the burst configuration file name is case insensitive. The data type for PTC Server system attributes must be string.

You can use the dmsmetadata element to update PTC Server security labels. Both one-way and two-way metadata assignment rules treat passing a Security Label value from an XML document to a PTC Server property differently from PTC Server global attributes. A Security Label value is only assigned to a PTC Server property when a new document is initially uploaded to the PTC Server. Security labels will not be updated when that document is subsequently checked into the PTC Server. You must use the PTC Server HTML interface to update security labels after a document is uploaded. For two-way metadata rules, passing values from the PTC server to an XML document works as usual.

References to security label names in metadata rules must match the value of the name attribute on the SecurityLabel element in the security label XML configuration file on the PTC Server. Values for security labels in a document must match the value of the name attribute on the SecurityLabelValue element in the configuration file. If these values do not match, any associated metadata assignment rules will fail.

References to security labels must also have the prefix SL:: prepended to the name of the security label. This flags the value as a security label for the PTC Server. For example, if the name of the security label is EXPORT_CONTROL, the name for that security label in the burst configuration file must be SL::EXPORT_CONTROL.

In the following example, the EXPORT_CONTROL security label is assigned the value of the book element’s role attribute when the document is initially burst into the PTC Server. Similarly, the CORPORATE_PROPRIETARY security label is assigned the value of the book element’s status attribute when the document is initially burst. However, the CORPORATE_PROPRIETARY security label is associated with a two-way metadata rule. If someone uses the PTC Server HTML interface to update that security label, then the new value for the security label will be passed to the status attribute in the XML document the next time that the document is checked out or updated in Arbortext Editor.

For more information about security labels, refer to the Windchill Security Labels Configuration and Implementation Guide.

The metadatarule element enables you to use XML attributes or content to serve as values for PTC Server property fields. When such mappings exist, the XML attribute values will be copied from the source XML document to the PTC Server object properties. Each mapping entry requires an XPath expression and the name of the PTC Server object property. Property assignment rules can be specified by element name, source type, or both.

The metadatarule element has the following attributes:

Property assignment rules function as follows:

The content of the XML attribute is converted to the data type of the associated PTC Server property. Depending on the data type, the content of the XML attribute needs to be in a specific format to support the conversion. For all data types besides string, leading and trailing spaces are ignored. The following data types are supported:

The PTC Server connection supports the full XPath 1.0 specification for specifying property values. This allows combinations of element content, attribute values, and static text. XPath expressions are evaluated to strings. If multiple elements or attributes match, the first occurrence is returned. This is consistent with the XPath specification.

Following is an example of burst configuration file syntax that stores the value of the authcode attribute in the authorization object property:

The twowaymetadatarule element enables you to either use PTC Server property fields as the value for an XML element or attribute or to have the exchange of values work in both directions. In the latter case, the value of a PTC Server property field is used as the value for an XML element or attribute when a document is checked out or opened in Arbortext Editor for viewing without being checked out. When a new document is initially added to the repository or an existing document is checked into the repository, then the value of the XML element or attribute is used for the PTC Server property field. Note that the element or attribute associated with a two-way metadata rule must already exist in the XML document and have a value assigned. If you want to use an XML attribute value to clear the value of a PTC Server property field, the attribute value can be a blank space.

Before you can use two-way metadata, you must enable it in the atidefaults.bcf system-wide burst configuration file. In that file, set the createdefaults element's twowaymetadata attribute to on to enable two-way metadata.

The twowaymetadatarule element has the following attributes:

Property assignment rules function as follows:

The supported data types for passing attribute values from an XML attribute to a PTC Server property are the same as those supported for the metadatarule element. The following data types are supported for passing a value from a PTC Server property to an XML attribute:

Following is an example of burst configuration file syntax that sets up a two-way metadata relationship between the projectStatus PTC Server property in the repository and the status element in the XML document. When a document is checked out or opened in Arbortext Editor for viewing without being checked out, the value of the status element is replaced with the value of the projectStatus property. When a document is created or checked in, the value of the projectStatus property is replaced with the value of the status element.

Following is an example of a two-way metadata rule where the ruletype uses the twoattr value. In this case, the rule uses the DITA document type’s othermeta element containing the following values:

For this DITA markup, the following two-way metadata rule specifies that for topic objects, the repository’s Security property should be assigned the value high: