[
Lists Home |
Date Index |
Thread Index
]
Mike Champion [mailto:mc@xegesis.org] wrote:
...
> Pardon my jumping in, but I'd really like to hear refutation
> of my argument here:
>
> ...<snip/>
> But it's not terribly clear to me what you gain by a formal schema
> validation, since the whole point of exceptions is to let you
> handle the situation where you get bad data. If you have a
> C or COBOL back end that is going to die horribly if it gets bad
> data, I guess a good case for up front validation can be made.
How well the "back end" deals with exceptional conditions is
implementation dependent. For example, if you write a Web service in
.NET like this:
[WebMethod]
public double Add(double x, double y) {
return x+y;
}
It expects an Add element with two child elements, x and y. If, however,
you send it an Add element with foo and bar child elements, or no child
elements, or something else off the wall, it will happily return 0. This
is a false positive, where most developers would expect an exception.
Performing schema validation before the method is called moves such
error handling down a layer and protects you from this type of thing
happening.
> But anyway, who would be crazy enough put in SOAP RPC interfaces
> to legacy code that can't deal with bad data without crashing?
> More generally, who would be loony enough to let remote
> users directly call APIs in their order entry system unless they
> were VERY sure that they could be trusted, and "trust" implies
> debugged their message generating code IMHO. So, contract-time
> schemas (especially annotated schemas) make sense, debug time
> schema validation makes sense, but run-time????
I'd like to see you make this argument to a financial institution or a
supply chain where big bucks are at stake. Distributed systems have
never worked this way. You define the contract, a specific message is
generated on the wire that the other side expects, the other side
validates the format as it deserializes. In the past, the validation was
hard-coded into the wire-format parser (NDR in the case of DCOM), but it
was still happening. You can't just throw any message on the wire and
expect it to make it through a DCOM object on the other side that will
gracefully deal with the exception.
> If it's a document-style message, there seems to be even less point
> in doing a runtime schema validation. You are going to have to
> write some code to do business-logic validation on the purchase
> order that no schema language could plausibly define the constraints
> ...
Again, constraint validation can be layered. And I'd definitely like to
see something like this make its way into XML Schema.
> But we're talking about XPath/XQuery here ... not arguing whether
> type-aware schema validation is a Good Thing to have or not. Is
> it worth the weight on XPath?...
Sorry for the distraction, just trying to point out the schema are
relevant at runtime in many systems. However, I don't think it's worth
"the weight on XPath" as you say. I'd prefer a more layered approach as
well.
--
Aaron Skonnard <http://skonnard.com>, DevelopMentor <http://develop.com>
Essential XML Quick Reference available online in PDF format...
<http://develop.com/books>
Before you criticize someone, you should walk a mile in their shoes.
That way, when you criticize them, you're a mile away and you have their
shoes.
|
