Declare the result type of a mode, via @as

[Arithmeticus]

Initial message to support discussion on the proposal for the introduction of @as in <xsl:mode> to define the output of a particular mode. Current: https://qt4cg.org/specifications/xslt-40/Overview-diff.html#mode-result-type

[Arithmeticus]

The current wording of the proposal seems not to deal with situations where templates in a mode produce legitimate descendants of the primary type. If I have <xsl:mode as="map(*)*"> or <xsl:mode as="element()*"> surely the former needs to allow templates to output atomic values, and the latter, children nodes, which, I suspect, are not subtypes of the @as value of <xsl:mode>. I can't confirm because the link at 6.7.4 of the diffed proposal -- Section 3.7.1 The judgement subtype(A, B) XP40 -- is dead.

[michaelhkay]

If you're outputting XML in the traditional way, then I think you would want to use as="node()*". Yes, this would prevent a template rule returning a string that wasn't wrapped in a text node; but using xsl:value-of or xsl:text to produce text nodes is the normal approach anyway. More important is that if a template tries to output a map or array (usually because you forgot the mode attribute), this is very likely to be a type error rather than a dynamic error, giving better diagnostics.

If you're intending to output maps (and this is probably the primary use case) then in my experience it's very useful to specify a map or record type to indicate what you're expecting xsl:apply-templates to return. It enables the compiler to detect many otherwise bewildering errors. If you want to produce some text to add to the map, switch to a different mode. I think it's good programming practice for modes to be small and focused, rather than global and all-purpose. There's a traditional culture of only using modes if they're needed for disambiguation, whereas I think people should be encouraged to use them much more liberally as a modularity mechanism.

[michaelhkay]

Note that xsl:mode/@as is specified in the current draft, I have added the label "requires confirmation" so that we can confirm that we want it.

[michaelhkay]

I'm closing this. We discussed it on 2023-10-03. The minutes record that we accepted the idea, but I was given an action to check how it worked with the default built-in rules (action QT4CG-048-01). I addressed that question in issue #750 and PR #751, which was accepted. This issue can therefore now be closed.