- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 03 Feb 2026 18:15:29 +0000
- To: public-xslt-40@w3.org
Hello folks,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2026/02-03.html
QT4 CG Meeting 151 Minutes 2026-02-03
[1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
Pull Requests
Table of Contents
* [6]Draft Minutes
* [7]Summary of new and continuing actions [0/5]
* [8]1. Administrivia
+ [9]1.1. Roll call [10/10]
+ [10]1.2. Accept the agenda
+ [11]1.3. Approve minutes of the previous meeting
+ [12]1.4. Next meeting
+ [13]1.5. Review of open action items [2/10]
+ [14]1.6. Review of open pull requests and issues
o [15]1.6.1. Merge without discussion
o [16]1.6.2. Close without action
* [17]2. Technical agenda
+ [18]2.1. PR #2413: 2365 Drop extensible record types
+ [19]2.2. PR #2418: 2399b Add rules and advice for JSON output
of special numerics
+ [20]2.3. PR #2416: 2406 Add fn:parts-of-dateTime and
fn:build-dateTime functions
+ [21]2.4. PR #2410: 2398 Fix fn:highest to match fn:lowest
+ [22]2.5. PR #2404: 2403 Enhancements to fos.xsd
+ [23]2.6. PR #2409: 2407 Change function to fn in type-of
output
+ [24]2.7. PR #2419: 2292 XSLT document() function: options
parameter
+ [25]2.8. PR #2423: 2421 document XSLT incompatibility with
simplified stylesheets
+ [26]2.9. PR #2428: 2422 Drop XSLT section on embedded
stylesheet modules
* [27]3. Any other business
Draft Minutes
Summary of new and continuing actions [0/5]
* [ ] QT4CG-143-02: MK to try to recover the ability to extract
formal equivalences into tests
* [ ] QT4CG-143-03: JK to look for C14N test suites.
* [ ] QT4CG-144-01: MK to consider if any now lost value comparisons
should be added as examples.
* [ ] QT4CG-149-01: CG to draft a new PR with the common rule note.
* [ ] QT4CG-150-01: NW to ask Jirka for a room at XML Prague for
Tuesday/Wednesday
* [ ] QT4CG-150-02: Everyone review the "nice to have" tags and
object where they wish
* [ ] QT4CG-150-03: NW to setup an agenda item to review open issues
* [ ] QT4CG-150-04: NW to see about a status update on PR #2345;
possibly schedule discussion
* [ ] QT4CG-151-01: MK to fix the typo in the build-dateTime
function.
* [ ] QT4CG-151-02: NW to generate compiled schema, merge #2404.
* [ ] QT4CG-151-03: NW to investigate why records are formatted
incorrectly in XSLT
1. Administrivia
1.1. Roll call [10/10]
* [X] 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] Alan Painter (AP
* [X] Wendell Piez (WP)
* [X] Norm Tovey-Walsh (NW) Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [28]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [29]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 10 February 2026.
No regrets heard.
1.5. Review of open action items [2/10]
* [ ] QT4CG-143-02: MK to try to recover the ability to extract
formal equivalences into tests
* [ ] QT4CG-143-03: JK to look for C14N test suites.
* [ ] QT4CG-144-01: MK to consider if any now lost value comparisons
should be added as examples.
* [X] QT4CG-148-02: NW to publish a dated draft after QT4CG-148-01 is
complete.
* [ ] QT4CG-149-01: CG to draft a new PR with the common rule note.
* [X] QT4CG-149-02: MK to update the PR #2372 so that the "?" are
part of the comment.
* [ ] QT4CG-150-01: NW to ask Jirka for a room at XML Prague for
Tuesday/Wednesday
* [ ] QT4CG-150-02: Everyone review the "nice to have" tags and
object where they wish
* [ ] QT4CG-150-03: NW to setup an agenda item to review open issues
* [ ] QT4CG-150-04: NW to see about a status update on PR; possibly
schedule discussion
1.6. Review of open pull requests and issues
This section summarizes all of the issues and pull requests that need
to be resolved before we can finish. See [30]Technical Agenda below for
the focus of this meeting.
1.6.1. Merge without discussion
The following PRs are editorial, small, or otherwise appeared to be
uncontroversial when the agenda was prepared. The chairs propose that
these can be merged without discussion. If you think discussion is
necessary, please say so.
* PR [31]#2430: Updates to schema for xslt
* PR [32]#2429: Feature/2026 01 28 draft review
* PR [33]#2426: 2408 editorial omnibus
* PR [34]#2412: 2395 2396 Add missing "new in 4.0" entries
* PR [35]#2411: 2397 add to F&O list of functions defined in XSLT
Proposed: merge these PRs without further discussion.
Accepted.
1.6.2. Close without action
It has been proposed that the following issues be closed without
action. If you think discussion is necessary, please say so.
* Issue [36]#2053: Add fn:collection-available
* Issue [37]#1962: fn:map-to-element
Proposed: close these issues without further action.
Accepted.
2. Technical agenda
2.1. PR #2413: 2365 Drop extensible record types
See PR [38]#2413.
MK introduces the motivations for the proposal. To make it easier to
manage extensible and non-extensible record types without having to
create multiple types.
* JWL: Does this mean all record types are extensible?
* MK: No, instance of still checks.
* JWL: So I can other stuff, but when they get passed to a function,
it'll strip out everything that's not necessary.
* MK: Yes.
* WP: Sounds fine to me; it only applies to built-in record types.
* MK: You can't define your own extensible record types. You have to
pass a map.
* JLO: I'm unconvinced. I fear especially that instance of is failing
even though all the keys that should be in there are present.
+ ... It will create non-extensible records.
+ ... And for serialization, we need extensiblity.
* MK: Yes, it does mean that the option parameters where you want to
allow vendor-specific extensions become more difficult.
+ ... We pass those as maps.
* JLO: I'd like to see them as extensible records.
MK proposes to review the text and come back to the discussion.
* MK: The main impact is in the XQuery spec.
+ ... A record is now just a sequence of field definitions.
+ ... We lose a lot of text because we've dropped a feature.
+ ... Coercion rules discard the additional fields.
+ ... That means you can make use of static checking. But it
could be done the other way.
+ ... All the rules related to extensible record types are
dropped.
+ ... Constructor functions are considerably simplified
* MK: There are consequence changes in XSLT for pattern matching.
* CG: I really like this proposal. I think there are a lot more ways
to enforce type safety.
+ ... We're using records a lot and everytime they're
extensible, you don't know anything about them.
* RD: I'm happy with this; we can always add extensible records back
in if it's necessary. Worst case, you supply the parameter as a
map.
* WP: I see an analogy to schema validation. I think leaving
extensible options as maps is fine. I think this is a price worth
paying.
* JLO: I'm still not convinced. If both MK and CG are in favor, I'm
inclined to go along.
+ ... I'd really like to see how we could end up using records
for options that will have additional entries.
+ ... Could we have vendor-defined records?
* MK: It's always easier to add a feature than remove one, but more
valuable to remove it.
+ ... I concede that this loses things, but there were lots of
things we had to work out for extensible and non-extensible
record types. This is the cleanest solution I could come up
with.
* AP: The generators proposal was based on extensible records; but
they'd have to be maps, I guess.
Some discussion of how you might make it work; you could have a fixed
field whose value is a map. Could this also work for things like
serialization?
* MK: We could also try to define a subtyping relationship between
two different record types.
* JK: I'm not opposed to simplifications. As a developer, I was
looking forward to writing my own extensible record types. What's
the alternative?
* MK: We could look at some type of subtyping relationship. Something
that's not arbitrarily extensible, but more like XSD. But that
causes a lot of complexity as well. That would make static error
checking harder.
* JK: It would be nice, but I'm in favor of simplification.
* JLO: I see that there's a way forward and I'm fine.
+ ... Why is the order of entries changed in the map to match
the order of field declarations?
* MK: It doesn't have to be. This proposal doesn't change that; that
was already the case.
+ ... It just means if you know you have a record, you know the
order.
* CG: It also means you can directly reference the offset into
records (as an implementor).
* MK: There's a cost on doing the coercion.
* JWL: To come back on the mark of JLO's. Remember, there are two
sorts of "records": maps that are records and maps that are just
maps.
Proposal: accept this PR.
Accepted.
2.2. PR #2418: 2399b Add rules and advice for JSON output of special numerics
See PR [39]#2418.
* MK: This arose from an action or a review.
* MK: It clarifies JSON serialization of numbers, canonically and
non-canonically.
Proposal: accept this PR.
Accepted.
2.3. PR #2416: 2406 Add fn:parts-of-dateTime and fn:build-dateTime functions
See PR [40]#2416.
* MK: This was in response to a Saxon user pointing out that it was
quite hard to round a date time to a integer number of seconds.
+ ... It's a general problem that it's not easy to convert
between dateTimes and the numeric values of the components.
* MK: There's a new dateTime record type and a function to create a
dateTime from one of those records.
+ ... You have to have one of a specific set of fields.
ACTION QT4CG-151-01: MK to fix the typo in the build-dateTime function.
* MK: I could decide if the extract function should be
parts-of-dateTime or parts-from-dateTime. I chose
parts-of-dateTime.
* MK: The use case becomes decode, round, and encode again.
* CG: Have you seen my comment with the solution to use the round
function?
* MK: Yes. There are ways to do it, but this seemed more natural and
general.
* WP: I think this is way better than the alternatives.
* JLO: Will this make it easier to get to seconds-since-epoch.
+ ... Could we do "to-dateTime-record"?
* MK: Names are always tricky.
* NW: I think time divided by 1 second is the quick and dirty way to
get seconds from epoch.
* JWL: Is there any argument for doing the same for durations?
* MK: Yes. I decided not to do both at once.
* RD: Didn't we have a proposal a while back to do this?
* MK: Early on I had a parts function that decomposed several data
types. That got lost.
Proposal: accept this PR.
Accepted.
2.4. PR #2410: 2398 Fix fn:highest to match fn:lowest
See PR [41]#2410.
* MK: Debbie Lockett pointed out that we had an old version of
fn:highest that didn't make any sense.
* MK: This PR reinstates fn:highest along the lines of fn:lowest.
Proposal: accept this PR.
Accepted.
2.5. PR #2404: 2403 Enhancements to fos.xsd
See PR [42]#2404.
ACTION QT4CG-151-02: NW to generate compiled schema.
Proposal: accept this PR.
Accepted.
2.6. PR #2409: 2407 Change function to fn in type-of output
See PR [43]#2409.
* MK: This is a trivial change proposed by CG.
+ ... It just changes the serialized form.
* CG: It just seems like what users might expect.
Proposal: accept this PR.
Accepted.
2.7. PR #2419: 2292 XSLT document() function: options parameter
See PR [44]#2419.
* MK: This is substantive but it's following a well trodden path;
we've done this for the doc function before. The only complication
is that the document() function already had a second argument. So I
did the choice trick.
MK reviews the proposal text.
Proposal: accept this PR.
Accepted.
ACTION QT4CG-151-03: NW to investigate why records are formatted
incorrectly in XSLT
2.8. PR #2423: 2421 document XSLT incompatibility with simplified stylesheets
See PR [45]#2423.
* MK: This isn't changing the spec; it's removing an incompatibility
that we introduced.
* MK: A simplfied stylesheet used to have an implicit match pattern
of "/" which meant it could only match a document node and
couldn't, for example, process JSON.
+ ... This documents the incompatibilities.
Proposal: accept this PR.
Accepted.
2.9. PR #2428: 2422 Drop XSLT section on embedded stylesheet modules
See PR [46]#2428.
* MK: This deletes the section on embeded stylesheet modules.
+ ... It doesn't remove the feature. We say elsewhere that a
stylesheet may be embedded.
+ ... All this does is cut out advice and guidance; partly
because no one uses them and they're tricky to use.
+ ... You get all sorts of tricky issues related to ID values,
fragment identifiers, etc.
* MK: It also removes a reference to the xml-stylesheet processing
instruction which has never been part of XSLT.
* RD: If a processor doesn't need to support this, how do you specify
it?
* MK: With some kind of API.
Some discussion of what it means to have a stylesheet embedded in
another document and what sorts of APIs you might need.
Proposal: accept this PR.
Accepted.
3. Any other business
None heard.
References
1. https://qt4cg.org/meeting/minutes/
2. https://qt4cg.org/
3. https://qt4cg.org/dashboard
4. https://github.com/qt4cg/qtspecs/issues
5. https://github.com/qt4cg/qtspecs/pulls
6. https://qt4cg.org/meeting/minutes/2026/02-03.html#minutes
7. https://qt4cg.org/meeting/minutes/2026/02-03.html#new-actions
8. https://qt4cg.org/meeting/minutes/2026/02-03.html#administrivia
9. https://qt4cg.org/meeting/minutes/2026/02-03.html#roll-call
10. https://qt4cg.org/meeting/minutes/2026/02-03.html#agenda
11. https://qt4cg.org/meeting/minutes/2026/02-03.html#h-4B2B2EA1-12A0-4D1C-A338-5856F1197EEF
12. https://qt4cg.org/meeting/minutes/2026/02-03.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2026/02-03.html#open-actions
14. https://qt4cg.org/meeting/minutes/2026/02-03.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2026/02-03.html#merge-without-discussion
16. https://qt4cg.org/meeting/minutes/2026/02-03.html#close-without-action
17. https://qt4cg.org/meeting/minutes/2026/02-03.html#technical-agenda
18. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2413
19. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2418
20. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2416
21. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2410
22. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2404
23. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2409
24. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2419
25. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2423
26. https://qt4cg.org/meeting/minutes/2026/02-03.html#pr-2428
27. https://qt4cg.org/meeting/minutes/2026/02-03.html#any-other-business
28. https://qt4cg.org/meeting/agenda/2026/02-03.html
29. https://qt4cg.org/meeting/minutes/2026/01-27.html
30. https://qt4cg.org/meeting/minutes/2026/02-03.html#technical-agenda
31. https://qt4cg.org/dashboard/#pr-2430
32. https://qt4cg.org/dashboard/#pr-2429
33. https://qt4cg.org/dashboard/#pr-2426
34. https://qt4cg.org/dashboard/#pr-2412
35. https://qt4cg.org/dashboard/#pr-2411
36. https://github.com/qt4cg/qtspecs/issues/2053
37. https://github.com/qt4cg/qtspecs/issues/1962
38. https://qt4cg.org/dashboard/#pr-2413
39. https://qt4cg.org/dashboard/#pr-2418
40. https://qt4cg.org/dashboard/#pr-2416
41. https://qt4cg.org/dashboard/#pr-2410
42. https://qt4cg.org/dashboard/#pr-2404
43. https://qt4cg.org/dashboard/#pr-2409
44. https://qt4cg.org/dashboard/#pr-2419
45. https://qt4cg.org/dashboard/#pr-2423
46. https://qt4cg.org/dashboard/#pr-2428
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 3 February 2026 18:15:36 UTC