Re: [xml-dev] XSLT question on transitive closures

[Rick Jelliffe <rjelliffe@allette.com.au>]

On Fri, 2007-10-26 at 11:02 +0100, David Carlisle wrote:
> 
> 
> > Transitive closure is intrinsically a higher-order function,
> 
> But guessing (since it's Rick) that this is a schematron question
> which means that one's generating a stylesheet dynamically anyway,
> There is thus the possibility to generate, given a function implementing
> an xpath expression, a specific closure function.
 
Ah, everything can be solved by text substitution :-)  If in doubt, add
another stage to the pipeline!

Thanks for that, it is very useful and simple to understand. 

The actual task I am doing is not actually Schematron, it is about
removing families of elements from XSD schemas (an element, its
declaration, uses and any unique descendents.)

However, there is also a Schematron angle, for possible extensions to
Schematron.

One is to have a mechanism so that schema validation occurs over the
transitive closure of a set of documents: a website for example, or a
series of imported XSD schemas. For example, to start from a document
then go to any document in the current directory linked by xlink in the
current document, validating each one and continuing to traverse. So the
schema element could have some attribute sch:schema/@visit containing an
xpath. The use case is validating an interdependent document set.

Another is to have some kind of transitive closure on patterns, so that
a pattern selects a set of nodes, and these nodes are the ones that the
rules apply to. So the pattern element could have some attribute
sch:pattern/@visit  containing an xpath. The use case is validation
where there is some notion of reachability important.

Or there could be a tie in with phases, so that different traversals
cause validation in different phases. (I don't see much benefit at the
rule level or assertion level: gilding the lily.)

One of the advantages of XLinkit over Schematron has been that its
provision of more complete qualifiers (for each, every, etc not sure on
syntax) allowed it to be used for these kinds of validation-in-the-large
use cases. It may be that there is a good advantage in providing a
built-in mechanism at the top-level, rather than just allowing clever
schema developers to hack user-defined functions that have to live
underneath the schema/phase/pattern/rule/assertion framework.

Cheers, and thanks again
Rick Jelliffe