Pros and Cons of implementing schema validation

I am new at this, but it seems there are three different places where you could validate an incoming xml document; in the docuement type, in the processing rules or in the flow service itself.

The WM documentation, leads me to believe that all three of these implementations are the same, they are all using pub.schema.validate.

So my question is when and why would I validate the xml in the doc type vs. the processing rule vs. flow service?

If I used the doc type or processing rule option to validate an incoming xml doc, how can I handle the exception flow when the xml is not valid? I am guessing I would do this in the flow services the processing rule calls, but I can I know if the xml is valid and what the errors are once I am in the flow service?

–steve

The ability to turn-on validation in the doc type or the processing rule is simply for flexibility. Normally, you’ll want to set the validation that is desired most of the time in the doc type and then override that setting in the proc rule as needed.

When validation is performed by TN, the service specified by the proc rule will be invoked. It is important to note that the service is invoked even when validation errors exist. In the service, call wm.tn.doc:getEvents to retrieve the activity log events associated with the document. The getEvents service accepts a parm to retrieve errors only, so you’re not wading through any information log entries. If you get any entries returned, then TN ran into errors processing the doc. You can e-mail this list to alert the right people or take whatever action desired.

HTH.