[Schematron] errors in iso_dsdl_include.xsl beta

Rick Jelliffe rjelliffe at allette.com.au
Tue Sep 16 11:03:13 EDT 2008

G. Ken Holman wrote:
> But then you need a different keyword other than sch:include ...
> perhaps sch:merge ... but I don't think you can arbitrarily change 
> the semantics of sch:include now that it has been out and implemented 
> for a while.
> I know that my existing and deployed sch:include stylesheets would 
> stop working.
Why would they stop working? There would be no change to existing valid 
And you would not need to change your code list methodology unless or 
until it was
prudent to take advantage of the new features.

(Or it is a good thing if schemas that the implementation does not 
understand fail, on the
grounds that you don't want false positives?)
>> I think this is the neatest way to cover what many people are
>> requesting.
> I guess I missed seeing what people are requesting.  Can you cite 
> some examples?
Well you for one!  The request has been for a better inclusion 
mechanism, with the specific
problem with the current include being that it only allows one branch to 
be included, whereas
people have multiple branches they want, for example multiple patterns 
or multiple assertions.
(The problem is that IDs only allow single elements to be located, and 
that XPointer's range functionality
is fundamentally broken because it does not correspond to a WF document.)

We discussed here whether an include or an import mechanism was needed, 
and IIRC correctly
people did not get too excited by an import mechanism (at least a 
top-level one.)

I am very keen to see what people think about this merge functionality 
and whether it would
address the problem they have with the current include. And, of course, 
the option of having
an element called <merge> (even though otiose) is not crazy, if that is 
what people prefer.
(I saw another standard use <merge> for its inclusions recently, sorry, 
no reference, so I don't
think my proposal is unique.)

(The other change I am proposing that would break if a new schema ran on 
an old processor
is the sch:pattern/@documents attribute. I think it would be an 
acceptable cost.)
>> The same mechanism also should
>> work at any level of merge, not just top-level. (Actually, I will have
>> to get rid of any position dependencies
>> in the skeleton in order to make top-level merges with namespaces and
>> phases work.)
> Can any proposed functionality be implemented in different modules 
> than the modules put forward as "reference implementations"?
I will remove the "reference" comment when I move this one out from beta 
status, and I think it is clear
that the merge functionality is experimental.

Rick Jelliffe

More information about the Schematron mailing list