OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[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]