XML Schema Binding Options

Integrators can use xml schema binding options. The table below lists the settings, along with their default values.

To configure the settings, in the Administration App, select the Data tab, and find the settings within the All Settings page.

These settings apply to third party (Blackbox) integrations only, and will not affect the snippets or Apps.
Setting Default Description
Xml Validation False This is a boolean setting indicating whether Transtream should perform validation on each request and response prior to either processing or returning. If switched on (set to True), Transtream will validate each request prior to processing it, and it will validate each generated response before returning it to the client. If any error or warning is identified, it will be returned as part of the response within the top-level Status node. Only Client Requests are validated, excluding internal child transactions.
Xml Boolean Standard Default This setting controls how all <xs:boolean> values are returned in the response. When Default is selected, all <xs:boolean> values are returned in the format that is the standard for the type of transaction (1/0, True/False, true/false). If W3C is selected, only true or false (mind the lowercase) will be returned by Transtream. This is the XML standard, and will be expected by schema code wrapper generators, e.g. JAXB (Java Architecture for XML Binding). All boolean values will be converted to one of these two values: true or false.
Xml AutoCorrect ProjectsServer Indicates which application should perform automatic correction of XML documents. This feature is only active if XML Validation is enabled (set to True), and is available in order to ensure a higher level of backward compatibility even when using schema validation. By having this feature as an application rather than a True/False setting, it is possible to maintain a high degree of schema binding directly to Transtream while still using all legacy requests. Autocorrection works as follows:
  1. Removes any nodes which are not listed in the schema (i.e. are invalid as per the schema).
  2. Adds any mandatory nodes which are not present but are listed in the schema as mandatory.
Xml Minimum Elements Only False This is a boolean settings indicating whether the application should return or receive only the minimum number of elements. If set to False, empty nodes and blocks will be present. If set to True, then all blank and non-mandatory nodes (including their parents, if appropriate) are removed. This setting helps reducing the size of the XML document and is designed to provide a greater connection to the schema files where blank nodes should not be returned, unless they are mandatory. This setting affects how Transtream generates requests; only the minimum number of elements will be submitted.
Xml Validation Severity Level Default Indicates how the system should treat schema validation failures.
  • If Warning is selected, all errors are downgraded to warnings and returned in the Status block. The top-level "Status" code will be the result of the transaction, so a successful ship request remains as an overall success.
  • If Default is selected, errors and warning are treated for what they are. If an error is detected in a request, the transaction fails, and the validation errors are returned. However, if the validation fails in a response, then the original response data is preserved and will be returned, so all charges, label data, etc. will be available in the response. Only the top-level Status block will indicate a failure and its details.
  • If Error (Fatal) is selected, all warnings are upgraded to errors and considered fatal. The top-level Status code will indicate a failure. However, the original response, in case a validation fails to process it, is cleared; and only a basic failure response is returned, so all charges, label data, etc. although available in the database, will not be available in the response. It is recommended that this setting is only used on dev and test systems where it is appropriate to replace a compliance engine success with a failure for testing purposes, e.g. in order to identify mismatched schema tags.
Article last edited 12 June 2018