Enhancement for sch:phase - @start-at

[rjelliffe]

(Added: In my Schematron users meeting presentation [Prague 2024] I identified this as proposal as one of the most important IMHO.)

Motivating Use-Case
Sometimes we only want to look at a small part of a document, and so we don't want to look throughout. For example, say we just want to check the metadata. We don't want to have to have absolute paths for every sch:rule/@context. Or, because we want a separation of concerns within a document so that changes being made by you in your section won't be validated when I validate my section.

Good performance is a perennial issue of course.

@start-at does not limit the scope of Xpaths inside rules or templates: they can still use location steps and variables etc. to access any part of the document. I only limits where validation starts from, for the patterns that are active in that phase, rather than starting from the document-node().

It is not inherited by sch:pattern/@documents; or, at least, I think that any interaction with sch:pattern/@documents should be left undefined to allow experimentation by implementers: the use-case would be the same: to reduce unnecessary. So initially I would suggest that the QLB for XSLT n and XPATH n be changed so that using document() or document-uri() functions in @start-at does not have defined semantics and probably should trigger a warning (e.g, coarsely, when contains(@starts-with, 'document(') )

Suggestion
An attribute sch:phase/@starts-at has an XPath location. The phase validates starting at that node and under it using the normal rules.

(I also thought of adding this to sch:pattern, but it seems messy,and it could easily have performance costs that a user might not expect, depending on implementation. And I think it is better to enhance phase rather than complexity sch:pattern.)

I considered names such as @from and @Branch: @from is not clear about exclusivity, and @Branch is unnecessary tied to validating trees, which strictly belong to the QLB. So I think @start-at is quite clear.

Example

  <sch:phase id="validate-metadata" start-at="/thing/metadata">...
  <sch:phase id="validate-tables" start-at=".//table">... 

In this case, the first phase only looks at and under /table/metadata. In the second phase, it only looks at and under any table.

Implementation
I think this is fairly simple to implement. Along the lines of:

<xsl:template match="/">
      <xsl:if test="is-enabled-phase('validate-medata')">
             <xsl:apply-templates  select="/thing/metadata" mode="validate-metadata-pattern-mode/>
      </xsl:if/>
     <xsl:if test="is-enabled-phase('validate-tables')">
             <xsl:call-template   select=".//tables"   mode="validate-tables-pattern-mode" />
      </xsl:if/>
</xsl:template>

[AndrewSales]

What happens if evaluating the expression in start-at returns the empty sequence? I assume it would have a similar effect to a non-matching rule/@context: if the nodes don't exist, nothing happens.