Cart
[Home] [By Thread] [By Date] [Recent Entries]
Not every pipeline, but where one uses it in the pipeline is important. Take the famous co-occurrence constraint, aka, correlation. Should I correlate in the GUI (eg, a pattern check validation using script), on send, or on receipt? Any or all will work but the last requires the most network traffic and possibly incovenience given a context where everything needed is at the client already (say, form field validation). Business objects may be different. In this case, I need to correlate the data entry to server-side information. If I get a blind transaction from a trading partner, I may want to correlate the entire input. Now the schema looks good but only insofar as the message received is atomic. So the context of a context, that is, where am I in the pipeline and what do I need from the context to validate the entry makes a world of difference. This may be at the root of some of the XML Schema despair; trying to make it affective over all potential process contexts rather than a few or one. Schemas are usually cheaper than equivalent JavaScript; on the other hand, they aren't parameterizable unless I put XSLT in the pipeline too. Now I am into self-modifying code and my nausea quotient goes up. Len Bullard Intergraph Public Safety clbullar@i... http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Gavin Thomas Nicol [mailto:gtn@e...] Ahhh, but how will you use it? The assumption I've seen people make it that it'll be part of every pipeline. I may/probably will use XSchemas to validate the correctness of my application. I most likely will not use XSchemas to validate my content (except in some very specific domains).
|
