OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xml-dev] When to Validate XML?




Some form of validation is necessary at both the sender and
receiver's end. In the pre-XML days, the validation is done via
'application logic' on both ends. However, IMHO, XML complicated
matters here.

For most starters, schemas seem to be a place to keep all their
validation logic - however schemas are not expressive enough for this
purpose. So, I've often heard complaints that one has to do to lot more
validation besides what the schemas offer. So, there is some logic in
the applications, and some more in the schemas. I don't see anything 
wrong in this - each of these validations may in fact be serving 
different purposes.


> Another consideration is the cost of rejecting a "semantically" valid
> document that happens to have some syntax out of place.  My favorite
> (hypothetical) example is a $1000000 purchase order with a private attribute
> in it somewhere; would you really reject it?  If "reject" means turn it over
> to a human, sure ...But if you're using human or programmed business logic
> look the documents over anyway, why bother validating the XML in the first
> place? 


Good example. Such a document may be "invalid" as per a schema or DTD. 
But it is perfectly valid from the business sense. So, how to deal with 
such documents when the sender and receiver wanted (for whatever 
reasons) schema-based validation (in addition to application level 
validation)? The all-or-none style parsers die on such documents.

Do we need a different kind of parsers which can process "invalid" 
documents, and tell us at the end what the violations are?


> Another impression I've received over the years is that validation (via
> DTDs, Schemas, or whatever) tends to be more of an "audit time" activity
> than a real-time activity. The DTD or schema represents a "contract" between


Precisely. However, the sender/receiver should be able to apply some 
discretion. In the above $1000000 purchase order example, the receiver 
may want to process it just because there are big bucks with it - the 
receiver can do so as long as there is "enough" information to process 
the purchase-order.

Subbu