I think Michael and others are getting a little sidetracked with the science: like George the Animal Steele being distracted by the turnbuckle: what ultimately really matters for Testing and QA is not raw pass/fail capabilities but the ability to efficiently determine what the defect is that caused the failure: for triage. That two languages may be equivalent in when they fail does not mean they are equivalent in how well they can help explain the failure or anomoly.
It would be reductionist to say that because C++ and Assembler are equally powerful, they are as workable or effective or substitutable for each other.
Yes Schematron does have contexts to allow multiple assertions from a single point, and yes it has sch:let and sch :phase etc but the most important thing is that it almost forces the writer to make clear natural language statements with dynamic details: it moves the emphasis from "how can i express this constraint in Xpaths" to "how can i express this constraint in a way that lets the user grok the defect rather than the failure occurrence?"
We need to know which tables failed not just that some tables failed. Usually.
(One reason people like to validate with a progming language is that they can explore the failure with the same tool that detected it. This is an advantage that I think Schematron has. )
For the last few years most of my time has been spent on running really big comprehensive tests in Schematron on really big document sets. The raw pass/fail statistics are useful at the start and the end of testing, but not for triage: this was a lesson I learned when I did write some Schematron patterns based on raw counts in context / -- knowing there is a needle in the haystack does not get you very far: indeed we had a big delay because of it.
All languages embody an underlying "theory" of psychology: how people go about solving problems. I think Schematron's "theory" is holding up well after 13 years: compare Schematron assertions and patterns with Xsd assertions and types. Xsd supports no distinction between failures (markup domain) and defects (semantic domain). The failure may be at table/row[2]/entry[3] but the defect may better expressed "column three".
(There are now a rich variety of Xpath -using languages for testing. Some are organized as singleton "test cases" that may fit into some tool chains or test methodologies better than Schematron. I dont think that alters Schematron's particular strengths however. )
Cheers
Rick
>>
>
> Right. But XMLUnit doesn't let you do that because it requires an
> absolute path (thank you John) to the node you are testing.
>
I think it's quite powerful enough to write assertions of the form
every $t in //table satisfies ($t/thead and $t/tfoot)
and assertions like that are quite powerful enough to meet any unit testing needs that I've ever seen
Perhaps you're still thinking of the limitations of XPath 1.0?
Michael Kay
Saxonica
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php