[
Lists Home |
Date Index |
Thread Index
]
From: "Thomas B. Passin" <tpassin@comcast.net>
> You don't want to say that governments should avoid xslt because it can't be
> validated against a schema, do you?
Anyone making (adopting standards for) large, loosely-coupled, mission-critical systems
with a view to QA should reject XML standards (i.e. for elements and attributes) with
no adequate schema. The core of software engineering is measurability; the core of QA
is independent auditability; even the core of XP is testing:-- it is entirely ironic to see modern
"standards" which actively stymie good software engineering, good QA, and good XP.
Standards without schemas show contempt (no, that is too strong: it may be weariness,
unconcern or even optimistic overconfidence) for us people who have to use them,
a too-narrow focus on subject matter without the vital concern for the pragmatics of data
interchange and use.
I would certainly say that XSLT 1 should fail to provide an adequate minimum level
for QA were it released today, but when it was created there wer no schema languages
available with adequate power: I believe RELAX NG (through TREX) was to some extext
created with XSLT as a use case.
But the world has changed now (by which I don't mean we can deceive and suspend
human rights willy nilly!): we have a better range of validation tools which provide an
adequate ground for realistic QA. There are very few element and attribute constraints
that cannot be expressed by modern schema languages, and they are even good for
some kinds of value-related constraints.
The increasing use of RELAX NG at W3C for schemas whenever WXS cannot cope
should not be seen so much as erruptions of a subterranean competition between WXS
and RELAX NG, but as a competition between formal quality (i.e., using schemas) and
handwaving ad hocery (i.e., not using schemas).
Please note, I am not saying that all XML should have a schema. Nor that all data
should be checked against a schema. I am talking about bottom-line quality issues
at the current state of technology as far as standards-making and standards adoption.
> (Or is there an RNG schema possible for xslt?)
Yes, there is a good RELAX NG schema for XSLT. It validates the xslt: namespace
elements.
If you wanted, say, an XHTML-in-XSLT schema, you certainly
can make a Schematron schema for this: for example, one that says that a
<table> should contain at least one <tr>s or <xsl:apply-template> or <element name="tr">
etc.
> Whoa, hold up there, Rick. How about xslt (and therefore Schematron!)?
> There is no useful schema because any elements and attributes can be put in
> the document. As Mike Kay and others point out from time to time, xslt
> validation is done by the xslt processor as it tries to compile the
> stylesheet.
Schematron's element syntax is not defined at all using XSLT. It has a DTD, RELAX NG
Schema, WXS schema and even Schematron schema. It defers the definition of some
of its attribute values (rule@context, assert@test, value-of@select) to the query language
it is using. In the default case, Schematron uses XSLT's paths and expressions but there have been
Schematron's made which don't use XSLT, such as Libby Miller's Schemarama which used
Squish or the ones that use simple XPaths.
In any case, that Schematron limited its elements that were expressable in XSLT is
a good example that the *discipline* of being able to express specifications in terms of
formal executable languages works. Actually, Schematron was initially prototyped in
OmniMark so that XSLT convenience would not dominate. Formal non-executable
languages are important for defining semantics to allow reasoning; standard executable
languages are important for defining syntax/structure to allow use and validation.
I think Tom is bringing up the related question: "Why worry about schemas for elements/
attributes if there are data values which are specified informally or with non-executable
BNF or invoke other standards which don't have schemas?" I think my answer is that
1) The standards *should* use some executable syntax specification For simpler syntaxes,
using WXS regular expressions or Schematron's ability to take apart data values and
validate the parts. Maybe in the future XSLT2's data tokenizing may have some use.
2) In the absense of standard exectuable syntaxes (err, actually, SGML provided this in part)
for embedded syntaxes, we are the ad hoc stage, and the unacceptability of this should
be promoted. For example, we get the problem when people use BNFs that they also
need to specify whether they are using longest/shortest matching, whitespace handling
or even if the BNF can be used for parsing (i..e it may be ambiguous, where the people
creating it can say "Oh, this element in your document is covered by this particle in the
BNF productions" but the grammar is not enough to make the link.)
3) Like I said, there has to be the usual pragmatic exception for bootstrapping: where
there are no prior executable tools. But we are beyond that now.
The next question I imagine people will be thinking is "Aren't you assuming that
schema languages are perfect?" Not at all. Old gotos are convenient but
may legitimately be banned for formal QA reasons. There are almost no complaints
now that the modern range of Schema languages are inadequate for representing
attribute and element constraints: the onus should be on standards makers to
show why their XML standard should not provide a schema, and user-side policy
makers should require them. When a modern schema language cannot express
an XML structure that a non-executable format such as BNF can, there is a high likelihood
that a mistake is being made: in particular ambiguity mistakes.
Cheers
Rick Jelliffe
|
