QT4 CG Meeting 141 Minutes 2025-11-11

Regrets: DB

• [ ] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Wendell Piez (WP)
• [X] Ed Porter (EP)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW) Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 18 November 2025.

• [X] QT4CG-140-01: NW to make sure that the new spec is in the dashboard.
• [ ] QT4CG-140-02: MK to add a note about dealing with binary in parse-cvs and parse-json

This section summarizes all of the issues and pull requests that need to be resolved before we can finish. See Technical Agenda below for the focus of this meeting.

See PR #2277.

• MK: CG has added check boxes; let’s merge the changes we’ve got and press on.
• CG: Many of the comments refer to typos and don’t need much work.
  • … Some issues need a more thorough review
• MK: Yes, if you find something non-trival, it should probably be an issue in its own right.

Proposal: accept this PR, but leave the issue open.

Accepted.

See PR #2273.

MK reviews the PR

• MK: I think this PR only points out consequences of the spec as its written. It doesn’t make any changes.
  • … We want maps and arrays to behave like nodes, so we have to allow functions to behave that way (because maps and arrays are functions).
  • … We also want it to work that way so you don’t have to do a test for empty.
• JWL: The CSV to arrays example uses csv-to-arrays() which produces a sequence of arrays, which is a sequence of functions, that’s subtle!
• JLO: I’m often using a different form of that, using ? to lookup something. It fails when we have an empty sequence.
• MK: No, empty maps to empty now.

MK continues the review.

• MK: There was a suggestion that each application of =?> could return zero or more functions, but I haven’t changed that. Each application must return exactly one, but there can be multiple maps on the left.
• JWL: You normally expect the context item to be consumed fairly quickly.
• MK: Yes, but it’s okay here because the function doesn’t change the context item.
• CG: I need to think about the last example; on the right there are function items. Is that okay? Wouldn’t they need more parentheses.
• NW: I hate it, I agree we have to do it, but I hate it.
• JLO: The result would be a sequence of all the function calls.
• MK: It’s exactly like the first example.
• JLO: I often use the ! operator so that I can return sequences of stuff.
• JWL: That means you could have maps of dispatch functions to process bits and pieces, couldn’t you?
• MK: Yes, it opens up all sorts of amazing things.
• CG: What about this example:

let $math := { 'n': -123, 'abs': fn { abs(?n) } }
return (
  (: ✓ works :) $math ? abs($math),
  (: ✓ works :) $math =?> abs(),

  (: ✓ works :) $math ? wrong(),
  (: ✓ fails :) $math =?> wrong()
)

• CG: I think the last two cases should do the same thing.
  • … A map can have functions that do or don’t require maps as the first argument.
• MK: Yes. I’d just like to retain a few places where you can get static errors if you misspell things.
  • … This is saying methods should work a bit like static function calls. So there’s some chance of producing a static error.
• JLO: What does “works” mean for $math ? wrong()?
• CG: It returns an empty sequence.
• JLO: I sort of think that shouldn’t work, but also why it should.
• CG: The lookup expression is used for many things; if you use it to call functions, you’ll have those challenges. If you’re just using it for lookups, you maybe don’t want errors. But it can be missleading if you’re calling functions.

Proposal: accept this PR.

Accepted.

• CG: Can we keep 2219 open then?

See PR #2266.

MK introduces the PR.

• MK: I added some magic environment variables.
• NW: Why is this better than fn:system-property()?
• MK: The system property function expects QNames in the XSL namespace.
  • … I think that could be terribly confusing.
• NW: Fair enough, I’m not going to lie down in the road over this.
• WP: I guess I have similar concerns to NW.
  • I see the problem with namespaces, but it seems like we should be doing it the same way.
• MK: I reviewed the list of system properties and some are very XSLT-specific.
  • … There are things like the vendor URL that isn’t really sufficient.

Some discussion of the actual list of properties proposed.

• WP: I think my question is about user migration.
• MK: It doesn’t take away system property in XSLT.
• JLO: I think a function like this is needed; every processor has a function that does something like this.
  • … Why isn’t this one function that returns a map?
• MK: Because this is the way the environment variables function works.
  • … We’d probably do that differently if we were adding it today, but I just wanted an incremental change.
  • … And we could add this to a 3.0 or 3.1 processor without introducing a non-conformity.
• JLO: I’d be in favor of a system properties function that just did this new behavior.
• CG: I think I agree with JLO; if we have a custom function, we can add implementation defined properties.
• RD: Why can’t we use system property again?
• MK: It’s use of the XSL namespace.
• RD: If we did adopt that function, couldn’t we keep them separate.
• MK: It creates a lot of complexity in something like a use-when attribute, is that in the XSLT context or the XPath context? What about in xsl:evaluate or in load-query-module.
• MK: Let’s see what it looks like if we add a new system-properties

See PR #2259.

• JK: It’s not ready to vote on, but I could use some feedback.
  • … The design choice is to add a new parameter named canonical that takes yes or no and allows canonicalization on XML and JSON, but could also be extended to XHTML.
  • … Most parameters in serialization get suspended if you say canonical=yes. But what about use-character-maps.
• MK: I think you should. If you canonical, then the output should be canonical XML rather than something else. And from an implementation perspective, it’s very muddled what order you do things in them.
• JK: I’ve written that the substitution occurs much earlier than C14N.
• MK: But that means you have to literally implement as proposed, doing a non-canonical serialization and then reparse. And gives rise to new possible errors.
• NW: You could do the double-parsing by hand if you needed to.
• JK: That’d be similar to Unicode normalization. But the C14N specs opt out of that. You have to supply that as a parameter.

See PR #2120.

MK reviews the PR.

• MK: This takes into account some of JK’s comments on the previous proposal.
  • … It attempts to provide a single instruction that meets all use cases.
• MK: I’ve reintroduced xsl:array-member as a sub-instruction
• MK: I start with the use cases…

MK walked through the documented use cases.

• JWL: I’m happy that xsl:array-member is back. It’s much clearer.
  • … If you have an array with a for-each but no select and the sequence constructor contains multiple xsl:array-member children, what happens?
• MK: Excellent question. (Reviewing the rules) In that case, it has no effect. Each evaluation of the sequence constructor gives you one member.
• JWL: Does that mean xsl:array-member is not permitted when you have no select?
• MK: I thought about that, but thought maybe a warning was better.
  • … YOu might be right. The orthogonality isn’t perfect.
• JK: I’m also happy to have xsl:array-member back. I think arrays are more conducive to mapping over XML structures.
  • … I’d like to see the xsl:array-member with a different parent.

Proposal: accept this PR.

Accepted.