Consider the following case. A schema A, shown in Figure 1, “schema-a.sch”,
includes a pattern from a different schema B, shown in Figure 2, “schema-b.sch”.
Figure 1. schema-a.sch
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2"> <sch:ns prefix="example" uri="http://example.com/ns"/> <sch:include href="schema-b.sch#pattern-b"/> </sch:schema>
Figure 2. schema-b.sch
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2"> <sch:ns prefix="ex" uri="http://example.com/ns"/> <sch:let name="allowedTypes" value="tokenize('foo bar', ' ')"/> <sch:pattern id="pattern-b"> <sch:rule context="ex:element[@type = $allowedTypes]"> <sch:assert test="false()"/> </sch:rule> </sch:pattern> </sch:schema>
Simply replacing the sch:include element in A with the
pattern from B does not produce a working schema.
The included pattern was written with the expectation that the prefix ex is bound to http://example.com/ns1, but schema A
uses the prefix example.
The rule context expression refers to a global variable
allowedTypes which is not defined in A.
In general, the interaction of schema composition with rule based validation is underspecified.