Lists Home |
Date Index |
>> A Schematron assertion (that the node list is non-null) would then always
>> fail, even at "compile" time.
>> I think this behavior would be _better_ for Schematron.
> How can that be better for schematron? It completely breaks the
> whole purpose of the schematron schema, which is to find the "bad"
> markup and to report the occurrences to the user. Having your
> schematron schema fail to compile because it is looking for illegal
> cases means that almost all schematron schema would not compile.
Since this is compile-time assessment of the expressions in the
stylesheet, I think that the answer is to not import a schema to the
stylesheet in the first place, or, if you do, not to assert (or is it
treat?) anywhere in that stylesheet that the element that you want to
test is of the type specified in that schema.
I can't see anything in the XSLT 2.0 WD that says that, during
compilation, it will access a particular instance document's schema
and use that to optimise queries. I think that as the stylesheet
author, you're in control of what the processor knows at compile time.
So Schematron can remain unaffected, I think. Likewise for other
stylesheets that purposefully operate over schema-invalid documents.
Of course that doesn't mean that optimising away aaa/bbb if you "know"
that a valid aaa can never hold a bbb is useful. The Data Model
currently goes to great lengths to say that it allows for partial
validation of a document, and includes invalid elements within the
document. If a processor substituted aaa/bbb for the empty sequence on
the assumption that the source document was completely valid, there
would be a rather strange situation where the data model contained an
element that was inaccessible from the stylesheet.
On the other hand, if a stylesheet states that instance documents will
be valid against a particular schema, it's probably right for that
stylesheet to reject instance documents that aren't completely valid
before even attempting a transformation. In that situation,
optimisating away paths would be reasonable. There's no way currently
to state that an instance is conformant to a particular schema in XSLT
2.0, as far as I can see (there's an outstanding issue on that).