[
Lists Home |
Date Index |
Thread Index
]
From: "Mike Champion" <mc@xegesis.org>
> 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
|
