[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] When to Validate XML?
- From: Subrahmanyam Allamaraju <firstname.lastname@example.org>
- To: email@example.com
- Date: Thu, 01 Nov 2001 10:14:00 -0700
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
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
> 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
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