QT4 CG Meeting 010 Minutes 2022-11-08

Table of Contents


Approved at meeting 011 on 15 November 2022.

Summary of new and continuing actions [0/9]

  • [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
  • [ ] QT4CG-007-05: NW to make an issue for Martin’s proposed ammendment to map:build
  • [ ] QT4CG-009-01: NW to coordinate with MK on an agenda for next week.
  • [ ] QT4CG-009-02: NW to work with MK to make sure PR #197 is updated correctly
  • [ ] QT4CG-009-03: NW to investigate the relationship between PR #215 and resolve-uri.
  • [ ] QT4CG-009-04: NW to review RFC 3896 wrt relative URIs
  • [ ] QT4CG-009-05: NW to fix the return type for parse-uri; consider using a record type.
  • [ ] QT4CG-009-06: NW to add error tests for parse-uri.
  • [ ] QT4CG-009-06: NW to make the query segments an array of maps.
  • [ ] QT4CG-010-01: DN to create an issue for proposing an optional else in XPath/XQuery
  • [ ] QT4CG-010-02: MK to incorporate the suggestions made by MSM

1. Administrivia

1.1. Roll call [6/13]

Regrets BTW, NW, JL, and CG.

  • [ ] Anthony (Tony) Bufort (AB)
  • [X] Reece Dunn (RD)
  • [ ] Christian Grün (CG)
  • [X] Joel Kalvesmaki (JK) [0:15-]
  • [X] Michael Kay (MK)
  • [ ] John Lumley (JL)
  • [X] Dimitre Novatchev (DN)
  • [X] Ed Porter (EP). Scribe.
  • [ ] Liam Quin (LQ)
  • [ ] Adam Retter
  • [X] C. M. Sperberg-McQueen (MSM). Chair.
  • [ ] Bethan Tovey-Walsh (BTW)
  • [ ] Norm Tovey-Walsh (NW)

Minutes scribed by EP, transcribed for the web by NW. Thank you, EP!

1.2. Accept the agenda

Proposal: Accept the agenda.


1.3. Next meeting

The next meeting is scheduled for Tuesday, 15 November.

No regrets given.

1.4. Approve minutes of the previous meeting

Proposal: Accept the minutes of the previous meeting.


1.5. Review of open action items

Nothing reported.

2. Technical Agenda

2.1. Extensions to conditional instructions

Approve extensions to conditional instructions described in chapter 8 of the current draft.

2.1.1. Adding @then and @else attributes to xsl:if

  • 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

2.1.2. Adding @select to xsl:when and xsl:otherwise

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


2.1.3. xsl:switch instruction

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


2.2. Changes to modes

Review changes to modes in §6.7:

2.2.1. As attribute

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.

2.2.2. Enclosed modes

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.

3. Any other business

None reported.