[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Requirement: objective, executable conformance requirements & Schematron
+NAME Rick Jelliffe +CONTACT rjelliffe@allette.com.au +CATEGORY (select one or more from below) editing/import-export/other +SCOPE (select one or more from below) general +USE CASE The more that checking we can express and check that document conforms, the better the chance for interoperability. And the more that a standard expresses its constraints in objective, verifiable terms, the less chance that unintended vagueness has crept in. Even the use of formal notations for expressing constraints (EBNF, home-made grammar languages) may not be effective in removing ambiguity unless they themselves can be automatically tested. So expressing constraints in a way that allows automatic verification of the specification and of documents (i.e. executable specification, a.k.a. schemas) is very practical. (Furthermore, formal notations which are not directly executable may be rather academic and fail to reach the readership.) That being said, specifying constraints in an executable schema language can reduce ambiguity even just used as a formal notation and not executed. It gives developers a clear, algorithmic formulation of the constraint, rather than the vaguaries and idioms of natural language alone. There have already been many examples in ODF where better notations would have been useful: * the issue of the scope of IDs * the replacement of @name with @xml:id attributes * foreign elements and foreign attributes * links between different XML parts in the same ODF archive, e.g. checking that the stylesheet document does in fact have the style named in the contents document +DESCRIPTION The ISO Schematron schema language has been developed to express the presence or absence of patterns in a document. It typically uses an XPath location to select an element, and then tests a series of XPath expressions from that context. Most importantly, it is based on a natural language expression of the constraint. XPaths are widely known in XML development circles (to the extent that an XML developer who does not have a grasp of XPaths or the concepts of CSS selectors would probably be considered deficient in that regard) and has already been used in ODF through XForms. So adotping Schematron does not require an expansion of the expression languages used in ODF. It is possible, for example, to take a Schematron schema and typeset it directly as an ISO Standard (i.e. an annex or series of clauses). Schematron has the advantage that it can express constraints it cannot test. (In such a case, the test is vaccuous 'true()' test.) Similarly, where XPath is not powerful enough to express a constraint fully, a weaker (coarse grain) test may be expressed. In this way it overcomes the problem of deciding whether the natural language or the artificial language has primacy: the natural language does, with the tests never allowing false negatives. So my proposal is that all document constraints (other than those that can be expressed simply in the RELAX NG schema or which require complex parsing) should be expressed in a normative Schematron schema. The schema should be processed so that the plain language assertions are made into numbered lists, and these put (informatively) in the conformance section of the ODF standard. Note: Schematron's idea of assertions has been picked up by W3C XML Schemas 1.1, so it should not be considered "fringey".
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]