Define parameters for abstract patterns

[xatapult]

There is no way you can define which parameters are there for an abstract pattern. Therefore the processor cannot check that an abstract pattern invocation is correct.

I know that these parameters are macro/text-substituted and are not "real" parameters in the XSLT sense, but nonetheless it would be nice if we could define them, both for checking and code documentation purposes.

[xatapult]

There's another reason we might want to do something about this: XSLT uses <xsl:param> elements to define a parameter in the location where they're used and an <xsl:with-param> to give it a value. But Schematron uses <param> elements to give parameters a value. Since XSLT and Schematron are often used side-by-side, that's confusing...

I know this would seriously break compatibility with previous versions.

[rjelliffe]

The reason that I didn't put formal parameters on abstract patterns was just the desire not to put anything in unless it did something. That is a weak reason. Because it was written for XSLT1, there was no potential benefit to, say, have something that could carry type information too. That is not the case now. However, I really wanted to avoid the trap that XSD had leapt into: attempting to replace a simple single generic macro mechanism (DTD parameter entities) with dozens of explicit features to "reconstruct" their use. But the main reason was that I thought it was something that experience should work out. Has anyone reported this as an actual big problem they had? Is the real flaw here that the same delimiter is being used for two different things? So if macro parameters were signified in the XPATH within e.g $$ would that be even clearer than having some formal parameter declaration element? (Meeting the expectation of looking like another language seems should be an explicit non-goal, to me, btw.) Cheers Rick

…

On Thu, 24 Mar 2022, 6:56 pm Erik Siegel, ***@***.***> wrote: There's another reason we might want to change this: XSLT uses <xsl:param> elements to define a parameter in the location where they're *used* and an <xsl:with-param> to give it a value. But Schematron uses <param> elements to give parameters a value. Since XSLT and Schematron are often used side-by-side, that's confusing... — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF65KKL2NLIIXEYVNITJQM3VBQN3NANCNFSM46NVQAOA> . You are receiving this because you are subscribed to this thread.Message ID: <Schematron/schematron-enhancement-proposals/issues/8/1077337901@ github.com>

[dmj]

I'll most likely implement this using processing instructions in SchXslt2. It seems useful to error on both sides: Parameters that are declared but not provided, and parameters that are provided but not declared.

[AndrewSales]

I think adding optional-repeatable element param to abstract patterns is a simple enough solution here. I don't think the syntax is that much of an issue - it's unambiguous from the context to a machine and human beings are adept at using the same word in different contexts to express different meanings - plus XSLT is an important query language binding, but only one of them.

However, param as currently defined has mandatory name and value attributes. You may not wish to specify a value for an abstract parameter, and if you do (as you must now), is that value the default? What happens if the concrete pattern also specifies a value for that parameter (it must, as things stand)?

In which case, it seems there are three options:

1. add param as currently defined: this would compel you to include a value for abstract parameters in a valid schema
2. make value optional and allow it to be absent for an abstract pattern parameter but required for a concrete one
3. redefine param when used in an abstract pattern as having only the name attribute.

(2) offers most flexibility, enabling default values.

[rjelliffe]

Or allow an empty value as the default.

…

On Mon, 11 Mar. 2024, 22:58 Andrew Sales, ***@***.***> wrote: I think adding optional-repeatable element param to abstract patterns is a simple enough solution here. I don't think the syntax is that much of an issue - it's unambiguous from the context to a machine and human beings are adept at using the same word in different contexts to express different meanings - plus XSLT is an important query language binding, but only one of them. However, param as currently defined has mandatory name and value attributes. You may not wish to specify a value for an abstract parameter, and if you do (as you must now), is that value the default? What happens if the concrete pattern also specifies a value for that parameter (it must, as things stand)? In which case, it seems there are three options: 1. add param as currently defined: this would compel you to include a value for abstract parameters in a valid schema 2. make value optional and allow it to be absent for an abstract pattern parameter but required for a concrete one 3. redefine param when used in an abstract pattern as having only the name attribute. (2) offers most flexibility, enabling default values. — Reply to this email directly, view it on GitHub <#8 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF65KKJK7T6RLRLJJGZAYGLYXWL75AVCNFSM46NVQAOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJYHAZDONJWGUYQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[dmj]

When I implemented the processing instruction I decided against the possibility of default values for backwards compatibility. If this is no convern, then I opt for (2).

[AndrewSales]

FWIW it's mine too, @dmj .

On the subject of compatibility:

• an existing implementation would presumably not know what to do with the proposed abstract param
• it equally would not know how to handle the absence of a param value
• existing schemas should function just as before, though they would be invalid if the constraint on every concrete parameter requiring an abstract equivalent were added to the Schematron schema schema [Annex B]
• such invalidity as there is should disappear once the "expansion" processing step is complete, and all abstract patterns have been instantiated. At that stage, schemas using this proposed new mechanism should be backward-compatible on this score.

Correct me if I'm wrong!