[
Lists Home |
Date Index |
Thread Index
]
10/2/2002 10:58:32 AM, "Aaron Skonnard" <aarons@develop.com> wrote:
>I guess it depends on the pool of cases. I think it depends largely on
>the type of XML application. In the case of Web service applications, I
>think XML Schema validation will be extremely common at runtime.
>
>Can you elaborate on what you mean by "...it's just not at the right
>level for business-logic validation."?
Pardon my jumping in, but I'd really like to hear refutation of my
argument here:
Let's say your business gets a purchase order via a SOAP message.
I guess if it's an "RPC" style message, then it makes sense to
validate the body of the SOAP message against a schema because
if the arguments don't have the right type, unmarshalling them and
passing them to the back-end API is going to fail. On the other hand,
your Java (or whatever) code is going to throw an exception if you
try to pass a string to a function that wants an integer. 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.
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 having
debugged their message generating code IMHO. So, contract-time
schemas (especially annotated schemas) make sense, debug time
schema validation makes sense, but run-time????
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
for ... e.g. "is this an established customer", "is
their credit good", "are they ordering an item in our catalog",
"is it in stock", etc. If you are going to write code to do all
this, why bother with a syntactical validation up front? Maybe,
just maybe, this is a sensible thing to do for some application
as a "clean data" check. Great, good thing that type aware validation
is an option, no quarrel. Especially in a pipelined process where
you are trying to extract the data you really need from a possibly
messy and diverse input stream, validation to make sure that you've
got the syntax right could be a handy tool.
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? I haven't heard a compelling argument.
XSLT??? There doesn't seem to be a compelling case. XQuery???
Well, there are fervent defenders of that idea, to be sure, but
then again XQuery is not exactly a part of the Web Services stack,
so I'm not sure if that's relevant to this discussion. I guess
I could *imagine* a situation where XQuery is used to do the kinds of
business logic validation described above (being able to handle
the input XML data and the legacy RDBMS data against which it's
validated in a single query expression).
Still, XQuery has to prove itself as a practical
solution for pressing problems before it will be taken seriously
as a Swiss Army Knife for all IT problems.
|
