Simplify rule for attribute values on Extension Instructions used to invoke named templates

[pgfearo]

Regarding the rule in the current proposal for Invoking Named Templates with Extension Instructions:

The way in which attribute values are handled depends on the type declaration of the template parameter...

I have some problems with this dependency on parameter type (to control whether value is an AVT or XPath expression):

1. In many cases, a xs:string or xs:boolean type passed as a param will be a variable reference so a coder needs to enter name="{$myName}" instead of name="$myName" in their XSLT editor.
2. If passing a literal xs:string type, the syntax: name="first" would be easy for a human reader to misinterpret as a NameTest instead of a StringLiteral.
3. The dependency on param type means more effort (and thus poorer performance) for a tokenizer or syntax-highlighter as it may need to get type information from included/imported XSLT stylesheet modules or from extension elements declared later in the same XSLT module.

The third point above is most important from my viewpoint as maintainer of an XSLT editor, but I believe the first two points are also valid.

For these reasons, I propose that: all attribute-values on extension instructions used to invoke named templates are treated as XPath expressions.

[yamahito]

It seems to me that this is already mandated:

Note that the attribute values are treated as XPath expressions: to pass a literal string, nested quotes are needed as in the example above.

However, one of the examples above contradicts this, as nested quotes are not used in the extension instruction:

a call on the template written as:

<xsl:call-template name="log:message">
    <xsl:with-param name="message" select="'Good morning'"/>
 </xsl:call-template>

can be replaced with the instruction:

<log:message message="Good morning"/>

And indeed seems to me to contradict the other example, where a lack of double quotes suggests to me that the attributes should be interpreted as XPath:

The instruction

<N A1="E1" A2="E2" A3="E3"/>

is deemed equivalent to:

<xsl:call-template name="N">
  <xsl:with-param name="A1" select="E1"/>
  <xsl:with-param name="A2" select="E2"/>
  <xsl:with-param name="A3" select="E3"/>
</xsl:call-template>

I think at least one correction to the spec is needed for consistency: I think my preferred correction agrees with Phil's suggestion:

<log:message message="'Good morning'"/>

[pgfearo]

@yamahito I agree that in the proposed specification there is indeed contradiction in the documentation and in the examples.

However, in the Saxon documentation though there is no such contradiction. The Saxon 11.2 behaviour is consistent with the examples.

As an XSLT developer I pass variable/parameter values much more frequently than string-literals. Hence my preference to use:

<log:message message="$greeting"/

Instead of:

<log:message message="{$greeting}"/

For the rare occasions where I can hard-code a string-literal the extra nested quotes would (in my view) not be too burdensome:

<log:message message="'good morning'"/

As a hack I guess I could always declare the parameter as xs:string+ to get the desired behaviour:

<xsl:template name="log:message">
    <xsl:param name="message" as="xs:string+"/>
    ...
</xsl:template>

I will delay making a decision on how I support the type-dependant aspect of this XSLT 4.0 feature in VS Code until there's been more discussion on this. So for now, extension instructions will have their attributes recognised as AVT's regardless of parameter type.

The following screenshot of XSLT than runs with Saxon11 shows the problem this causes in the editor:

1. $greetingList on line 12 is marked as unused (greyed out)
2. $greetingList on line 16 is wrongly highlighted as a string-literal instead of a variable (orange instead of white)

[michaelhkay]

The purpose of the rules as written is to make these extension instructions behave as far as possible in the same way as typical built-in instructions.

Most boolean parameters to existing instructions expect literal yes/no values, for example streamable=yes|no. In at least one case (xsl:message terminate="yes|no", the value can be supplied as an AVT (and we changed these parameters to accept true|false|0|1 to make this convenient). Users would not expect to pass such parameters as XPath expressions.

String-valued parameters to existing instructions generally expect either literal values (for example validation="strict", or AVTs (regex="{$regex}"). Users would not expect to double the quotation marks on such parameters (`validation="'strict'") which would be needed if the value is an XPath expression.

I think your arguments (1) and (2) apply equally well to the conventions followed for existing XSLT instructions, and I think it's more important to be consistent with these conventions than to improve on them.

As for argument (3), I have learned over the years that designing a specification for the benefit of implementors rather than users is rarely a good idea. Syntax-directed editors do have a problem with XSLT modules containing references to other modules that might not be directly imported or included; I don't feel we are making that problem any worse.

[pgfearo]

I concede the point on why using literal values for extension instructions is preferred.

Even though I made argument 3 from the perspective of an implementor of a code editor (extension), it was with the interest of the XSLT developer in mind. I am first and foremost an XSLT developer (that's what I get paid for) - the editor is just a means to an end for me.

I know this is outside the scope of the language designers but I'm hopeful there will be ways for the XSLT code editor to assist the XSLT developers (like myself) so they have some hint for each extension instruction attribute about whether a literal-value or XPath expression is expected before they edit it.

I haven't tested this yet, but I'm assuming that an extension instruction attribute will be treated as a string-literal regardless of whether the type of the corresponding xsl:param is declared directly as xs:string or is declared using a type alias.