One of the first tasks my custom soap processor performs is schema validation. If the incoming SOAP request doesn’t conform to the schema imported into the IS an error message is returned to the service consumer.
The schema validate service leaves MUCH to be desired regarding the error messages that it returns, particularly when XML nodes are missing child elements. For example, if a node has three required elements (firstName, middleName, lastName) and the “middleName” element is missing the pub.schema:validate will return the following:
[INDENT]“Child element lastName at position 1 is unexpected”
[/INDENT]instead of something like…
[INDENT]“Child element “middleName” is a required element”
[/INDENT]Is anyone aware of 3rd-party or open-source alternative to performing schema validation? Possibly a Java API that I could invoke instead of pub.schema:validate? This would greatly reduce the confusion caused by the error messages my custom soap processor currently returns.
IS 6.5 SP 2 (due out today) is supposed to deliver XML Schema 1.0 compliance. I think that means that WM node objects could be more easily converted to DOM objects and passed to third-party validation routines.
We’ll all have to see what really was implemented and how it can be used.
BTW, I agree that the validation message you referenced [strike]sucks[/strike] is less helpful than it could be.
I was trying to validate the xml with xsd schema defined with
Unique and Key Constraints but the pub.schema:validate is not throwing any error when there are duplicate key values to the attributes in the xml file.
<xsd:key name=“OrderNumber”>
<xsd:selector xpath=“./Order:OrderInfo” />
<xsd:field xpath=“@OrderNumber” />
</xsd:key> but if i have missed any of the tags or mismatch of datatypes it is showing error accurately but with only duplicate key values it is not showing any error, could you please help me out how it can be resolved? Thanks in Advance Gouse.
I am not familar with xsd:key, selector and field, but am pretty sure that most validating parsers would not be able to use those to enforce unique key values.
I’m pretty sure that attempting to do so at schema validation time (ideally at the edge of the network) would be a Bad Idea and does not belong in that layer.
So can i go with .Net service or Java service to validate the document.The input for either of the services will be the xml file which validates against the schema defined.
and could you please let me know , how to handle large xml files to validate againt schema in IS server (using inbuilt service or writing a .Net or Java service) as we see most outOfMemory exceptions is coming, how we can over come from this on handling large xml files.(thinking increase of JVM Heap memory already set to high)
Search here on wMUsers for information on IS large-file handing approaches. While iterating over the nodes in a large, incoming document you can validate the current node against an IS schema created from the XSD (not against a doc type).
Make XML validation optional (configurable) as it could degrade throughput.
It really depends on the use, but I guess, that limiting that by vendor is not good solution.
I would say, that having that keys validated by processor is far more better solution, that doing that in custom java code (not mentioning custom flow code).
I agree, that this should be solution of last resort, but still, would like to have chance to use it.
For me it is the same, as with serial triggers - there are many better solutions than serial trigger, but sometimes, it’s just a quick&simple solution to the problem.
It’s a pitty, that there is no documentation about which elements are supported by Schema declarations and which are not (or at least - give a warning, that something will not be validated…)
Can you give an example of an validating XML parser from any vendor or open source project that would understand how to validate an xsd:key data type? What would that look like? How would the parser know what to validate against?
As I stated originally, I’m not familiar with xsd:key. Perhaps you could cite some references to support your assertion below