pub.schema:validate
WmPublic. Validates an object using an IS document type, XML document type, or an IS schema.
Input Parameters
object | Document Where Document is an IData or an XMLData-formatted document, com.wm.lang.xml.Document or com.wm.lang.xml.Node Document or object to be validated. |
conformsTo | String Document type or schema to validate object against.  If object is a Document (IData object), conformsTo must specify the fully qualified name of an IS document type on the Integration Server. If object is a XMLData-formatted document, conformsTo must specify the fully qualified name of an XML document type on Integration Server. Note:
One or more XML document types and XML fields are created from a single XML schema definition. To validate an XMLData-formatted Document using the XML document types created from an XML Schema definition, you need specify only one of the XML document types or XML fields created from the schema. Integration Server locates the related XML document types, using the complete collection of XML document types and XML fields created from the XML schema definition during validation. If object is a com.wm.lang.xml.Document or com.wm.lang.xml.Node object, conformsTo must specify the fully qualified name of an IS schema on the Integration Server. The specified IS schema is needed only for validating nodes with "Names" that are not from XML namespaces (that is, qualified nodes whose XML Namespace Name properties are absent). Integration Server can only locate the IS schema if its fully qualified name is provided. If the XML document (com.wm.lang.xml.Document or com.wm.lang.xml.Node) contains namespace-qualified tags, conformsTo is ignored. Instead, Integration Server uses the XML namespaces declared in the instance document to locate the IS schemas that contain definitions and declarations for that XML namespace. Note:
When validating a document type created from an XML schema definition, if you want to use the OR operator for pattern-matching, use the | operator after the pattern string. If the | operator is used at the start of the regular expression, Integration Server treats it as an empty string. |
maxErrors | String Optional. Number of errors to be collected. Default value is 1. When the number of errors found is equal to maxErrors, the validation processor stops validation and returns the result. If maxErrors is set to -1, the validation processor returns all errors. |
ignoreContent | String Optional. Flag that specifies whether the validation processor will validate content keys of the type String, String List, or String Table. Set to: true to ignore content (that is, do not validate keys of these types). false to validate content. This is the default. |
failIfInvalid | String Optional. Flag that indicates whether the service should fail and throw an exception if the object is invalid. Set to: true to indicate that the service should fail if the object is invalid. false to indicate that service should signal success and return errors to the pipeline if object is invalid. This is the default. |
schemaDomain | String Optional. Schema domain in which the schema specified by the XML namespaces resides. If schemaDomain is not specified,Integration Server uses the default schema domain. Note:
This parameter only applies if object is a com.wm.lang.xml.Document or com.wm.lang.xml.Node |
Output Parameters
isValid | String Flag that indicates whether or not the validation was successful. A value of: true indicates that the validation was successful. false indicates that the validation was unsuccessful. |
errors | Document List Errors encountered during validation. Each document will contain the following information: |
| Key | Description |
| pathName | String Location of the error in XQL. |
| errorCode | String Error code (for example, VV-001). |
| errorMessage | String Error message (for example, Missing Object). |
Usage Notes
When validating supplied XML against an IS document type, XML document type, or IS schema, Integration Server uses the Perl regular expression compiler by default. If you need to change this behavior so that Integration Server uses the Java regular expression compiler during validation, set the server configuration parameter watt.core.datatype.usejavaregex to true. For information about setting this configuration parameter, see webMethods Integration Server Administrator’s Guide.
By default, when validating XML, Integration Server uses the Perl5 regular expression compiler. As a result, Integration Server uses Perl5 pattern matching to evaluate element content. The Perl5 pattern matching is not identical to the pattern matching defined by the World Wide Web Consortium (W3C) for the XML Schema standard. When validating XML against an IS schema or IS document type created from an XML Schema definition, an element defined to be of simple type with a pattern constraining facet might be invalid according to the Perl5 pattern matching rules but valid according to the pattern matching rules associated with the XML Schema standard.
You can change how Integration Server performs pattern matching during validation by switching from the Perl5 regular expression compiler to the Java regular expression compiler. To do this, set the server configuration parameter watt.core.datatype.usejavaregex to true. When his parameter is set to true, Integration Server performs pattern matching as described by java.util.regex.pattern.
When validating against an IS document type, if the Allow null property is set to false for a field in the document type and the corresponding element in the instance document carries the attribute xsi:nil, Integration Server throws the following error
[ISC.0082.9026] Undefined Object found.
When validating against an IS document type, if the Allow null property is set to false for a field in the document type and the corresponding element in the instance document contains content or contains child elements, Integration Server throws the following error:
[ISC.0082.9024] FieldName cannot have content or child elements since
xsi:nil is true.
When validating a com.wm.lang.xml.Document or com.wm.lang.xml.Node object, Integration Server searches the named schema domain for the specified schema. If the schema cannot be found in the specified domain, Integration Server searches the default schema domain. Note that Integration Server searches the schema domain for a schema, not an individual component (element, attribute, complex type, etc) within the schema.
When validating XML, Integration Server uses the W3C recommendation XML Schema Part 2: Datatypes. If you want to validate XML for illegal values, set ignoreContent to false and the watt.core.validation.w3cConformant configuration parameter to true. For information about setting this configuration parameter, see webMethods Integration Server Administrator’s Guide.
The pub.schema:validate service cannot be used to validate a node produced by the enhanced XML parser.