Re: [off-topic] Re: Use xsd to specify multipleinsta
Michael Kay wrote: > > That solves an important part of the problem, namely explaining the rule > that has been breached. It doesn't help much with the other half of the > problem, which is locating where it has been breached - given that the rule > might concern the consistency of a number of elements or attributes widely > scattered through the document. > Yes. In Schematron we solve this by 1) Having a split between the context expression that locates the nodes for testing the assertions 1a) an optional path from those nodes to locate the "subject" of the assertions, if this is different from the context, which frees the context expression to be as simple as possible for the tests 1b) role attributes on the subjects, to markup the significance of the subject in the pattern (which are the closest to a type name in XSD) 2) test expressions in the assertions 2a) role attributes on the assertions, to markup the significance in the assertion in the rule (which are closest to facet or model group names in XSD) 3) separate diagnostics elements on the assertions, to allow dynamic construction of diagnostics or repair tips, which frees up the assertion text to be purely intentional: the assertions can be "an X should have a Y because Z" while the diagnostics can say "I found AAA, which is outside the range" 3a) role attributes on the diagnostics, e.g. warning|caution|note 4) (planned for the new version) separate properties elements on the assertions, which can contain PSVI-like anotations of static properties, structured (labelled) dynamic content including text and so on that can help locate problems, and sub-schemas. For example, I have been working on embedding XSD types and CRepDL (character repertoire) scripts as properties, which can be converted to extra assertions. And the Schematron skeleton implementation provides 3 different ways to generate an XPath for the current subject, and 2 different ways to generate unique IDS based on the XPath of the current subject. The location is available in the ISO SVRL (Schematron Validation Report Language) format, along with the assertion failure details: being an XML format this can then be easily used by the caller to locate the assertions being tested. Furthermore, of course, because Schematron does not (unless you select this in the validator) have a fail-on-first error semantic, you can approach link problems from both ends by having multiple tests for the same assertion. And, to address the issue of having multiple errors that are merely side-effects of a single cause, Schematron's phase mechanism allows the user to group patterns into "phases", and first validate some issues, then others. This progressive validation also gets rid of the problem that conventional schema languages have that the first problem you get reported may not be in the class of issues you want to address: if your workflow is that you want to get tables correct next, you don't need to first have to fix up all other issues before the first table to start. Cheers Rick
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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