Define parameters for abstract patterns about schematron-enhancement-proposals HOT 7 CLOSED

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.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

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.

from schematron-enhancement-proposals.

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.

from schematron-enhancement-proposals.

from schematron-enhancement-proposals.

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

from schematron-enhancement-proposals.

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!

from schematron-enhancement-proposals.