QT4 CG Meeting 010 Minutes 2022-11-08

• RD: Second if example missing “=” for @then and @else.
• DN: Trivial examples would be more succinctly achieved with XPath conditional expressions if/then/else.
• MK: True, but when used with sequence constructors the utility of these attributes is more apparent.
• DN: Else is optional?
• MK: Yes, it defaults to an empty sequence.
• DN: Could XPath also have an optional else?
• MK: Reason for requirement in XPATH is dangling else/return condition.
• MSM: Some part of me asks why not use <xsl:choose>, may be worth noting this could be written with XPath or choose.
• RD: Flow control objects were already somewhat flexible (multiple ways to write the same logic).
• DN: Could we define a default else in XPath to omit?
• RD: Return could be part of flowr expression, which would complicate this issue.
• MSM: This should be treated as a separate issue, DN, please propose this.

ACTION QT4CG-010-01: DN to create an issue for proposing an optional else in XPath/XQuery

• MSM: Suggested revisions:
  • Syntax errors
  • Create more demonstrative example of its utility
  • Note to explain the several ways possible to express flow control

ACTION QT4CG-010-02: MK to incorporate the suggestions made by MSM

• DN: Is there discussion of performance?
• MK: Yes, there’s a brief discussion of expression evaluation.
• MSM: Could there be confusion in the attribute name “select” in that it somewhat suggests you’re changing the context before the test? Should it be named “then” or should there be a note clarifying what select does in this context.
• MK: Agreed, there is a lack of symmetry.
• RD: How about a “return” attribute, which better signals what the attribute is doing? This mirrors “switch” in XPath syntax.
• MSM: Should “then” be “select” on if in previous proposal? To be discussed when PR for xsl:if revisions are reviewed.

Proposal: Add @select to xsl:when and xsl:otherwise as proposed.

Accepted.

• RD: I like it. It improves alignment with XQuery.
• DN: This example could be written as a Map/Key. Could you provide a better example?
• MK: Second example is better?
• MSM: Is this a hint to the compiler to do this with a branch table? Is this relevant to XSLT processing?
• MK: Yes, it is a hint to the optimizer.

Proposal: Add an xsl:switch instruction as proposed.

Accepted.

The as declares what will be returned by a mode, in case a mode returns a boolean or maps, for example (detail is in §6.7.4).

• JK: Is this describing the aggregate of the mode, or individual templates?
• MK: This describes what the individual templates return.
• JK: Generally, I think @as describes aggregate.
• DN: What happens if there are @as attributes that are in the mode?
• MK: @as on templates within enclosing mode must be subtype of parent mode.
• DN: So this should generate errors if they do not match?
• MK: Yes.
• DN: Can there be an example of this?
• MK: Yes.
• RD: This is useful in that it ensures all your templates are returning expected types.
• MSM: Move on to Enclosed modes topic.

Addition of content as a set of template rules within a mode element (detail is in §6.7.5).

• MK: Primarily an organizational nicety, to confirm you’re looking at all the templates in a mode.
• MSM: This makes it much easier not to forget setting a mode on a template.
• MK: Yes! We’ve all omitted modes accidentally.
• DN: Check verbiage “containing” vs. “enclosing”. Make consistent throughout.
• MSM: Enclosing mode is most understandable.
• MSM: Clarification, overriding does not require the override to be in an enclosing mode?
• MK: Yes, that’s not even possible.
• EP: Note that you have TODOs in your doc.
• RD: Can you inherit modes?
• MK: I can see potential there. I’ve used a hierarchy of modes previously, based on the role attribute.
• RD: I’ve had stylesheets that also cascade roles.

Discussion to continue. End of meeting reached.