Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XPath/XSLT 2.0 concerns
 10/2/2002 10:58:32 AM, "Aaron Skonnard" <aarons@d...> 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
