Pass parameters to the validating stylesheet at validation runtime

[hryom]

The <let> elements ends as <param>s in the compiled stylesheet. It would be convenient if you could pass values on these parameters to the transformer at the validation time, and in this way overwrite the default value given from the schema.

A scenario could be that you have to check something against an external source, which url may change depending on your environment (e.g. staging or production).

[AndrewSales]

Thanks for this, @hryom . It may be that this is something left to implementations to decide, but could you please provide a little self-contained example, showing what you would like to happen here? I'm assuming you're referring to top-level let elements.

[hryom]

Yes, I am referring to the top-level let elements. Perhaps we should use the term global parameter.

An example

Given this document:

<events>
  <event date="1066-10-14">Battle of Hastings</event>
  <event date="1683-09-12">Battle of Vienna</event>
  <event date="1815-06-15">Battle of Waterloo</event>
  <event date="1944-06-06">Battle of Normandy</event>
</events>

and this schema

<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron" queryBinding="xslt2">

  <sch:let name="earliest-date" value="'1753-01-01'"/>

  <sch:pattern>
    <sch:rule context="event">
      <sch:assert test="@date >= $earliest-date">
        Event date <sch:value-of select="@date"/> must not be before <sch:value-of select="$earliest-date"/>.
      </sch:assert>
    </sch:rule>
  </sch:pattern>
</sch:schema>

When validating the document, the first two event elements will fail. When validating the document with a new value for earliest-date given as a parameter, e.g. 1900-01-01 the three first event elements will fail.

[xatapult]

I think this is a vary good an useful idea.

For me, a top-level <param> element would be the way to go here. Like in XSLT. Not overload the <let>

How to set these parameters is implementation defined and depends on the processor's (command line or API) interface

[AndrewSales]

Added as much to the latest draft.

[rjelliffe]

In the Schematron Skeleton, a top-level sch:let is implemented as an xslt:param. This allows overriding at run-time.

In Schematron, a param is a second-class compile-time constant, which disappears from any scope at runtime: i.e. macro substitution. A variable (let) is a runtime construct that has runtime visibility and scoping.

(In XSLT, the top-level params are not defined as either compile-time or run-time: an XSLT compiler could require the data or not, as I understand it.)

So I believe that the better approach is to make the standard clear that the value of a top-level sch:let variable may be overridden at run-time at user option, and not mess up the compile-time/run-time distinction of sch:param.

Regards Rick

On Mon, Mar 18, 2024 at 12:30 AM Andrew Sales @.***> wrote:

Closed #34 https://github.com/Schematron/schematron-enhancement-proposals/issues/34 as completed.

— Reply to this email directly, view it on GitHub https://github.com/Schematron/schematron-enhancement-proposals/issues/34#event-12142980918, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF65KKI6BBK4E4Z2RGD64VDYYWLJDAVCNFSM5YN6DWS2U5DIOJSWCZC7NNSXTWQAEJEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW4OZRGIYTIMRZHAYDSMJY . You are receiving this because you are subscribed to this thread.Message ID: <Schematron/schematron-enhancement-proposals/issue/34/issue_event/12142980918 @github.com>

[rjelliffe]

Or, if we want compile-time parameters as well, then define /sch:schema/sch:param so that it is part of the macro -substitution mechanism: i.e. handled by iso_dsdl_include.xsl or equivalent.

I agree that it is handy to have both compile-time and run-time parameterization: I like the feature, but I think the appropriate elements are sch:param and sch:let respectively.

(Security note: sch:param could potentially allow compile-time injection of code, so if it is implemented then it might be useful to limit it to strings and not to XPath fragments.)

Regards Rick

On Tue, Mar 19, 2024 at 5:40 PM Rick Jelliffe @.***> wrote:

In the Schematron Skeleton, a top-level sch:let is implemented as an xslt:param. This allows overriding at run-time.

In Schematron, a param is a second-class compile-time constant, which disappears from any scope at runtime: i.e. macro substitution. A variable (let) is a runtime construct that has runtime visibility and scoping.

(In XSLT, the top-level params are not defined as either compile-time or run-time: an XSLT compiler could require the data or not, as I understand it.)

So I believe that the better approach is to make the standard clear that the value of a top-level sch:let variable may be overridden at run-time at user option, and not mess up the compile-time/run-time distinction of sch:param.

Regards Rick

On Mon, Mar 18, 2024 at 12:30 AM Andrew Sales @.***> wrote:

Closed #34 https://github.com/Schematron/schematron-enhancement-proposals/issues/34 as completed.

— Reply to this email directly, view it on GitHub https://github.com/Schematron/schematron-enhancement-proposals/issues/34#event-12142980918, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF65KKI6BBK4E4Z2RGD64VDYYWLJDAVCNFSM5YN6DWS2U5DIOJSWCZC7NNSXTWQAEJEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW4OZRGIYTIMRZHAYDSMJY . You are receiving this because you are subscribed to this thread.Message ID: <Schematron/schematron-enhancement-proposals/issue/34/issue_event/12142980918 @github.com>