XMLNSC validation

The XMLNSC parser offers high-performance, standards-compliant XML Schema validation at any point in a message flow.

Validation of the input XML message or the message tree is performed against the XML Schemas that are deployed.

Validation is not the same as parsing. When parsing, the XMLNSC parser always checks that the input document is well-formed XML, according to the XML specification. If validation is enabled, the XMLNSC parser also checks that the XML document obeys the rules in the XML Schema.

Enabling XML Schema validation in a message flow

You must complete the following tasks to construct a message flow that validates an XML document in accordance with an XML Schema:

  • Enable validation at the appropriate point in the message flow. This is typically achieved by setting the Validate property of the appropriate node to Content and Value. See Validating messages.
  • Ensure that all required XML Schema files are deployed. See Deploying XML Schemas later in this section.
  • If the XML Schema files are deployed in a message set, you must also supply the name of the message set. Typically, you specify the message set by selecting the Message model property on a message flow node. If the parser is being invoked from a programming language such as ESQL or Java™, the message set must be specified in the parameters of the function call.

Deploying XML Schemas

XML Schemas can be deployed within an application, in a library that is referenced by an application, or in a message set.

If the schemas are deployed as part of the application, they must be included in one of the projects that are referenced by the application.

If the schemas are deployed in a library, the application must reference that library, even if it will be deployed as part of a different application.

Tip: In WebSphere® Message Broker Version 8.0 and later, message model schema files contained in applications, integration services, and libraries are the preferred way to model messages for most data formats. Message sets are required if you use the MRM or IDOC domains. For more information about message modeling, see Message modeling concepts.

If the schemas are deployed in a message set, you must complete the following steps.

All XML Schemas that are used by IBM® Integration Bus must be created as message definition files within a message set.

To create and deploy a message set for XML Schema validation:

  1. Create a new message set or locate an existing message set.
  2. Ensure that the message set has its Default message domain set to XMLNSC, or that the XMLNSC check box under Supported message domains is selected, to indicate that the message set supports the XMLNSC domain.
  3. Create a message definition file in the message set to represent your message. If you have an existing XML Schema or DTD that describes your message, you can import it. You can repeat this step for each message that you want to validate.
  4. Add the message set to a BAR file, which generates the required XML Schema in a file with extension .xsdzip, and deploy the BAR file to the integration node.

Standards compliant validation

XMLNSC validation complies fully with XML Schema v1.0 as defined in the specifications that are available at http://www.w3.org/TR/xmlschema-1/ and http://www.w3.org/TR/xmlschema-2/, with the following minor exceptions:

  • Any floating point value that is smaller than 10E-43 is treated as zero.
  • Any member of a group or complex type, that has both minOccurs > 1024 and maxOccurs > 1024, is validated as if minOccurs = 0 and maxOccurs is unbounded.

Validating XML v1.1 documents

You can validate documents that conform to the XML v1.1 specification, but support is limited by the fact that the XML Schema v1.0 documents must conform to XML v1.0.

As an example, you cannot always declare an XML v1.1 tag name in XML Schema v1.0. This limitation is not imposed by the XMLNSC parser implementation; it is a limitation of XML Schema v1.0.

Interpreting validation errors

A validation error is an error that results when the XML document breaks the rules that are defined in the XML schema. The XML Schema standard specifies exactly what these rules are, and how they should be applied. Validation errors that the XMLNSC parser issues contain information that links the error to the XML Schema rule that has been violated.

All validation errors are reported in BIP5025 or BIP5026 messages. Both messages begin with text in the following form: 
XML schema validation error '[cvc-error key: error description]'
Examples: 
'cvc-minInclusive-valid: The value "2" is not valid with respect to the minInclusive facet 
with value "3" for type "po:itemCountType".' 
'cvc-complex-type.2.4.a: Expecting element with local name "numItems" but saw "totalValue".'
To find the XML Schema rule that has been violated, open the XML Schema specification and search for the error key.

Example 1: Open http://www.w3.org/TR/xmlschema-1/ and search for ‘cvc-minInclusive-valid'. Follow the link to the XML Schema rules for the minInclusive facet.

Example 2: Open http://www.w3.org/TR/xmlschema-1/ and search for ‘cvc-complex-type'. Follow the link to the XML Schema rules for validating the content of a complex type. In this case, the error key contains extra information. The ‘2.4.a' refers to the exact sub-rule that was violated. It should not be included when searching for the rule.

If the XML Schema specification does not provide enough information, you can find more information using a search engine. The XML Schema standard is very widely used, and many online tutorials and other resources are available.

Start of change

XMLNSC validation restriction

Do not use patterns that include an unbounded wildcard character followed by a negated character class to validate string elements because an error occurs and validation fails even if the input string is valid.

For example, validation of the input string <StringWithXSDPattern>ADDDDDA</StringWithXSDPattern> results in error cvc-pattern-valid if a pattern of the following format <xs:pattern value="A.*[ˆD]"/> is used in the schema. The unbounded wildcard character is .* and the negated character class is [ˆD]. You can replace the negated character class with a non-negated class to avoid this error: using a pattern of the following format A.*[ABC] in this example will result in correct validation.

End of change