[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Testability and Schema validity
From: "Mike Champion" <mc@x...> > In the "OWL and DTDs" thread, some strong claims about schemas being > necessary for an XML application to be testable were made. I think that is a much stronger claim than I have made. Indeed, as I mentioned, even an open source program (in any language) with a warrant from the standards group would fill the role. But I think declarative schema languages have more capabilities for things other than validation, so are certainly preferable. > That sounds sensible, and probably is usually very practical, but I'm not at all > sure it's logically true. Yes, the logic is not the logic of "this is the only way to test something" but the logic of distrust: specifically the nice distrust proper to QA. Of course a standards-adopter might well *in addition* decide to only purchase products should pass a test suite or that a standard is complex enough that it should be avoided unless some test suite is available. Formal quality is no guarantee of actual quality: any more than a biscuit factory which samples 1 out of every 100 biscuit packets will guarantee that that your particular packet does not contain too many rat hairs. Validation is like any other formal metric: it does not guarantee good semantics, but it does stick a coarse net across the stream to identifiy obvious issues, and it makes catching the errors less a matter of domain expertise but a matter of syntax expertise. > For example, consider a purchase order format definition. It will > undoubtably define the element names and attributes and content model(s) > that are legal, and at least Schematron is capable of defining some fairly > robust models that won't break in the face of change, extra > information,etc. But a real test regime will require constraints that > aren't expressible in any XML schema language AFAIK: All the following examples are value constraints. Schematron can handle them. But no-one in the universe expects schema languages to handle all constraints, especially dynamic constraints. That there are some constraints that a schema language won't catch is beside the point: just as there are some rat hairs that a QA process won't catch. So I think the examples are fundamentally misplaced: the point is not program proving but the pragmatic software engineering approach that you should do the best you can given the state of the art and the state of the market: the lack of coverage is beside the point. > The <part_number> attribute value on each <item> element must match [a > product in our catalog]" This can be done in Schematron. You can retrieve any XML information from a URL (such as the results of a database query) and look at it using the document() function. You don't need to retrieve the whole database, because the URL can be constructed dynamically to include information from the instance being validated in the query. > "The <quantity> element value must be less than or equal to the [number > currently in stock according to ERP system]" This can be done in Schematron, using the method above. (I would class this as a business rule, in any case, and not expect a schema language to cope with it.) > "The <total_price> element value must [approved by the credit checking > service given the credit card number, expiration date, cardholders name]" This can be done in Schematron using the method above. (I would class this as a business rule, in any case, and not expect a schema language to cope with it.) > "The <key> element value must be a prime number represented by at least 20 > decimal digits" [OK, that's totally contrived in the purchase order > context, sorry] This can be done in Schematron using the method above, or say by an extension function in the query language. Most schema languages can represent the 20 decimal digit constraint directly, of course. (And Schematron can certainly approximate a prime number checker using a long chain of mod terms, to get rid of trivial composite numbers.) > Given that the test suite definition us going to have to specify how to do > all this database lookup or web service invocation or calculation or > whatever, why is a schema for the syntax really and truly necessary? If > one has enough confidence in one's testing regime, it could be the "real" > definition of validity, no? Who is "one"? A standards-adopting agency should not have to make its own test suite for things that can be validated using a standard schema language. Cheers Rick Jelliffe
|
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
|