Our custom soap processor has a configurable setting that turns on a call to pub.schema:validate for the inbound document contained in the Soap message body. The content of the body is extracted and turned into a node by a custom service. The conformsTo parameter is derived based on attributes in the soap message header.
This has all been working great, but today I found out that pub.schema:validate does not detect an error when valid elements are included in a sequence, but in the incorrect order.
So, if a sequence in the XSD (and the IS schema created from the XSD) specified an order of <city><state><zip>, but the document to be validated contained elements in <zip><city><state> order, no error would be detected.
This same error would result in a validation exception in XML Spy as well as most validating XML parsers.
My guess is that since an IS Map step will still work even if the elements are in a different order, the decision was made to allow this behavior (or maybe it was added intentionally).
The problem lies in the errors that will occur if the document from the inbound soap request will be passed on to a recipient application that will use a validating parser that cares about element order.
Apparently, this is a common question for WM Support. Have others seen this? What explanations were you given for the behavior?
Mark