Define the process of importing (include,extending, etc.) definitions from an external ISO Schematron schema

[dmj]

In short. The elements sch:include and sch:extends are used to incorporate definitions from an external ISO Schematron schema or schema fragment. Such an external definition may depend on top-level definitions of the external schema.

Consider the following case. A schema A includes a pattern from a different schema B.

<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>

<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()" diagnostics="diag-1"/>
    </sch:rule>
  </sch:pattern>
  <sch:diagnostics>
    <sch:diagnostic id="diag-1">...</sch:diagnostic>
  </sch:diagnostics>
</sch:schema>

Simply replacing the sch:include element in A with the pattern from B does not produce a working schema.

A definition of importing would discuss how to make top-level definitions from an external schema available.

See also: Maus, David. 2021. “What’s in a Schematron?” In Markup UK 2021 Proceedings. Online. https://markupuk.org/webhelp/index.html#ar02.html, esp. the section on schema composition.

[rjelliffe]

One thing to note is that if we have a Schematron schema document that is a library of patterns for e.g. some particular namespace and our new schema extends that library, then as well as inserting the sch:pattern elements it will also insert the sch:ns element, because /sch:schema/sch:ns is the same level as /sch:schema/sch:ns. Because Schematron avoids using namespace declarations for "Qnames in context" (i.e. XPaths) it does not have nearly the same dependencies on information in the root element: notably it does not need to trace arbitrary namespace context on every node in the schema. I think there is an argument to be made against smart imports: if someone wants to selectively bring in just some parts of a base schema and not others, it is their job to sch:include all the parts they need. I.e. if we want to import 10 patterns out of 20, and these patterns need some sch:param, sch:let and sch:ns then we need to explicitly put in sch:includes for those elements only, even if there is quite a few of them. I don't think it is a bad idea if users find it easier to explicitly make sch:ns element on their derived schemas, rather than including/extending the sch:ns elements from the base schema, actually: it makes things more explicit. Rick

…

On Fri, Feb 16, 2024 at 9:39 PM David Maus ***@***.***> wrote: In short. The elements sch:include and sch:extends are used to incorporate definitions from an external ISO Schematron schema or schema fragment. Such an external definition may depend on top-level definitions of the external schema. Consider the following case. A schema A includes a pattern from a different schema B. <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> <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 ***@***.*** = $allowedTypes]"> <sch:assert test="false()" diagnostics="diag-1"/> </sch:rule> </sch:pattern> <sch:diagnostics> <sch:diagnostic id="diag-1">...</sch:diagnostic> </sch:diagnostics> </sch:schema> Simply replacing the sch:include element in A with the pattern from B does not produce a working schema. A definition of importing would discuss how to make top-level definitions from an external schema available. See also: Maus, David. 2021. “What’s in a Schematron?” In Markup UK 2021 Proceedings. Online. https://markupuk.org/webhelp/index.html#ar02.html, esp. the section on schema composition. — Reply to this email directly, view it on GitHub <#66>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF65KKK4FGIAATL2LOLYJGDYT4ZPXAVCNFSM6AAAAABDLZZTT2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGEZTQMZSGA4TCMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[AndrewSales]

Thanks, @dmj .

I'm inclined to agree with @rjelliffe here.

extends isn't currently allowed at the top level (the skeleton implementation at least allowed it and enables what Rick describes), but is proposed to be added there, see Schematron/schema@58c1549#diff-9202b75b42b32283bb7212d62805a7e9f1f5b40b7c3b322a3ad20d7dd9bf0111R40.

FWIW, I've found this kind of idiom useful, defining a "header" of top-level declarations, which another schema can then extend:

<!--header.sch-->
<schema>
  <!-- some top-level declarations -->
  <ns .../>
  <let .../>
  <!--etc.-->

  <!--empty pattern, for validity-->
  <pattern/>
</schema>

<schema>
  <extends href='header.sch'/>
  <!--top-level decls now available here-->
  <!-- etc.-->
</schema>

It's good to start this discussion now, please do continue to flesh it out (noting also #67) -- but to manage expectations, I think it's unlikely we'll be able to incorporate this into the next edition, given the time available to finalize the working draft. So it might need to wait until the one after next...

[rjelliffe]

I think if the current standard omits to allow ***@***.*** (is that what Andrew is saying?) that would be a big error that should be prioritized ahead of any new features, since that is the primary use-case for ***@***.*** IMHO. Regards Rick

…

On Sat, Feb 17, 2024 at 9:08 PM Andrew Sales ***@***.***> wrote: Thanks, @dmj <https://github.com/dmj> . I'm inclined to agree with @rjelliffe <https://github.com/rjelliffe> here. extends isn't currently allowed at the top level (the skeleton implementation at least allowed it and enables what Rick describes), but is proposed to be added there, see ***@***.*** #diff-9202b75b42b32283bb7212d62805a7e9f1f5b40b7c3b322a3ad20d7dd9bf0111R40 <Schematron/schema@58c1549#diff-9202b75b42b32283bb7212d62805a7e9f1f5b40b7c3b322a3ad20d7dd9bf0111R40> . FWIW, I've found this kind of idiom useful, defining a "header" of top-level declarations, which another schema can then extend: <!--header.sch--> <schema> <!-- some top-level declarations --> <ns .../> <let .../> <!--etc.--> <!--empty pattern, for validity--> <pattern/> </schema> <schema> <extends href='header.sch'/> <!--top-level decls now available here--> <!-- etc.--> </schema> It's good to start this discussion now, please do continue to flesh it out (noting also #67 <#67>) -- but to manage expectations, I think it's unlikely we'll be able to incorporate this into the next edition, given the time available to finalize the working draft. So it might need to wait until the one after next... — Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF65KKINWVWYOUIA6CZMBBTYUB6TVAVCNFSM6AAAAABDLZZTT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBZHEZDGNJWGE> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>