- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 16 Dec 2025 17:42:52 +0000
- To: public-xslt-40@w3.org
Hello,
Here are the draft minutes from today’s meeting.
https://qt4cg.org/meeting/minutes/2025/12-16.html
Happy holidays and see you next year!
QT4 CG Meeting 146 Minutes 2025-12-16
[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 [8/13]
+ [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/5]
+ [14]1.6. Review of open pull requests and issues
o [15]1.6.1. Merge without discussion
* [16]2. Technical agenda
+ [17]2.1. PR #2342: 2341 Canonical JSON serialization
+ [18]2.2. PR #2329: 2327 Rename sequence-join as intersperse
+ [19]2.3. PR #2324 & #2282: bin:infer-encoding /
bin:decode-string
+ [20]2.4. PR #2313: 2298 XQFO rules: definition of default
values
+ [21]2.5. PR #2336: 2334 Revise XSLT pattern syntax and
semantics
+ [22]2.6. PR #2323: 2322 Generalize simplified stylesheets
+ [23]2.7. PR #2283: 2276 Relax XSLT rules on Extension
Attributes
* [24]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-146-01: NW to attempt to provide a markup solution for
argument defaults
1. Administrivia
1.1. Roll call [8/13]
Regrets: SF, RD.
* [X] David J Birnbaum (DB)
* [ ] Reece Dunn (RD)
* [ ] Sasha Frisov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [ ] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [ ] Alan Painter (AP
* [X] Wendell Piez (WP)
* [ ] Ruvim Pinka (RP)
* [X] Ed Porter (EP)
* [X] Norm Tovey-Walsh (NW) Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [25]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [26]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 6 January 2025.
The CG will not meet for the remainder of 2025. Happy New Year,
everyone!
1.5. Review of open action items [2/5]
* [X] QT4CG-143-01: CG to make another attempt at binary functions.
* [ ] 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-144-02: MK to add notes about edge cases: sequence
normalization and character maps for example.
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 [27]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 [28]#2347: 2340 Add a note explaining 1972-01-01
* PR [29]#2346: 2343 Add examples of format-integer with negative
numbers
Proposal: merge without discussion.
Accepted.
2. Technical agenda
2.1. PR #2342: 2341 Canonical JSON serialization
See PR [30]#2342.
MK introduces the PR.
* MK: This brings a few details about canonical JSON serialization to
the reader's attention.
* MK: Map entries are sorted; added a note pointing out how that
sorting must be done.
* MK: The rules for canonical numbers in RFC 8785 are quite complex.
+ ... I've added a note that if the output is not canonical,
output decimals (including integer) as the string value (not
scientific notation).
+ ... For strings, I've restated the escaping rules for
convenience; they differ from our usual rules.
* MK: In JSON canonicalization, the RFC takes as the input an
existing JSON document, where we take an XDM value representing the
tree. I thought about wording it that way, but that gives too much
freedom for numerics. We say that our rules are effectively a
mapping to the implicit data model of I-JSON.
Proposal: accept this PR.
Accepted.
2.2. PR #2329: 2327 Rename sequence-join as intersperse
See PR [31]#2329.
MK begins by reviewing the issue and the alternate names proposed.
* MK: I think fn:insert-separator has the most support.
* CG: I can see that there are concerns about fn:sequence-join. I
would be fine with several of these. Make it more explicit what the
function does; I'd also revert fn:array-join at the same time.
* JK: From my perspective, the function under discussion is similar
to fn:insert-before. If that's the case, I'd like to see greater
parity between them. I prefer fn:insert-throughout.
* WP: JK's point being taken, maybe "connect with" or "connect by"? I
like any of the ones that give you a hint.
* JWL: The separator can be a sequence, can't it? And it can be
empty.
+ ... So there's an argument for insert separator*s*.
Proposal: we have consensus for fn:insert-separator.
Accepted.
And MK to merge when it's changed.
* CG: Maybe if there are other features that we think we could
revert. Maybe we should do that now?
* MK: I think the problem is that you discover the problems as you
try to use them.
* CG: I opened one issue for the predicate filters.
2.3. PR #2324 & #2282: bin:infer-encoding / bin:decode-string
See PR [32]#2324 and [33]#2282.
CG introduces the topic.
* CG: We had some discussion on bin:decode-string. We currently have
a bin:decode-string with an offset that defaults to 0. There are
too many ways to similar things. Can we make it more composable?
+ ... My proposal is to invoke bin:part wehnever an offset is
provided.
+ ... After that, we don't have to look at the offset and size
anymore
+ ... Then we invoke bin:infer-encoding to retrieve the
effectiver encoding.
* CG: I've extended bin:infer-encoding to accept an encoding
argument. That's for resolving UTF-16 endianness. A processor may
have a heuristic if no encoding is provided. If there's no byte
order mark, the encoding specified is used.
* CG: There's no reference to fn:unparsed-text and the rules are
simpler again.
+ ... Whenever you have substrings in your binary data, if the
substring begins with a BOM, then it will be respected.
* MK: I'm okay with that.
* NW: I think that works for me.
* JWL: Are there cases where you could be building a binary structure
where you've got combining strings that have different byte order
marks inside them?
* CG: In this case, you could have different byte order marks.
* MK: I can imagine that happening in an archive format like ZIP.
* JWL: It might be worth adding a note about that.
Proposal: accept #2342, drop #2282
Accepted.
2.4. PR #2313: 2298 XQFO rules: definition of default values
See PR [34]#2313.
CG introduces the issue.
* CG: Right now we have more than 100 built-in functions with default
values.
+ ... I noticed while implementing them that we have two types
of default values.
+ ... For some functions, you get identical behavior for absent
value or empty sequence
o fn:string-join
+ ... For others, you get different behavior for absent value
and empty sequence
o fn:node-name
* CG: The problem is that looking at the signature, you can't tell
what will happen.
+ ... You can look it up, but that might be tedious for 100+
functions.
* CG: Another example is the case where there's a default value but
it can't be the empty sequence.
+ fn:sort
* CG: My attempt was to make all this consistent in one way. The
approach I chose is one we have to discuss.
+ ... Most of the function signatures are hard to read in the
diff version.
* CG: My thought would be to change the rules for intepreting
function signatures for XQFO so that you can look at the signature
and know what is going to happen.
+ ... If the value supplied matches the type, that value is used
+ ... If no value is supplied, the default value is selected
+ ... If the value is teh empty sequence, the default value is
selected
+ ... Otherwise a type error
* CG: This would let you know what is going to happen just by looking
at the signature.
* CG: So for example, in fn:string-join, the ? is removed from
xs:string because the default is used if you supply an empty
sequence.
* CG: Many of the specific rules from the prose are no longer
required.
+ ... That prose is hard to find because there's a long history.
So this also makes the whole document more consistent.
* MK: I'm very sympathetic to the intent: both to increased
consistency and relying more on declarative ways of describing the
semantics.
+ ... I'm concerned that this appears to attach semantics to
signatures in the F&O spec that don't apply to the same syntax
used for a user-defined function in XQuery or XSLT.
+ ... I'm also concerned that there's possible confusion between
the notation here and the symantics of function calls defined
in XPath.
+ ... For example "the supplied option matches" doesn't mention
the coercion rules.
+ ... As it happens, I don't think coercion plays an especially
significant rule because we don't coerce to or from an empty
sequence.
* MK: I wonder if we could do this with an alternative way using the
properties mechanism.
+ ... We adopt some markup convention that allows the rule to be
expressed in the properties section.
* CG: I had similar thoughts.
* NW: The rules that only apply to F&O functions is confusing.
* JK: Could we hear more about the fn:adjust-dateTime-to-timezone?
The empty sequence has a different meaning there.
+ ... I'm concerned that people may be using empty sequence to
avoid the default.
Some discussion of whether or not the rules provided cover this case.
Some discussion of how this change would effect test generation.
* WP: So the item xs:integer would be satisfied with an empty
sequence?
* NW: What's the markup approach?
Some discussion of the fn:array-get function because it's two argument
form can't be represented by any default for the third argument.
* MK: We need an "empty sequence = default" notation.
ACTION QT4CG-146-01: NW to attempt to provide a markup solution for
argument defaults
2.5. PR #2336: 2334 Revise XSLT pattern syntax and semantics
See PR [35]#2336.
* MK: This is probably too big for today.
* JWL: I'll try to run my grammar generators over it and see if I can
find out if there are any ambiguities.
2.6. PR #2323: 2322 Generalize simplified stylesheets
See PR [36]#2323.
* MK: This arose because I wondered why we can't use simplified
stylesheets for JSON documents.
+ ... I don't use simplified stylesheets very often, but
sometimes they are handy.
* MK: The essential change is that instead of the outermost element
being a literal result element, it can be any instruction.
* MK: The stylesheet that unsimplifies the stylesheet is about the
same.
+ ... The top level match pattern is no longer "/", it's now
".".
* NW: What about silly things?
* MK: I haven't tried to rule them out.
* JWL: The select="'.'" in the expansion, what does that mean?
* MK: It's going to generate a literal ".".
+ ... I've used xsl:element only very, very rarely.
* WP: This could be interesting.
Proposal: accept this PR
Accepted.
2.7. PR #2283: 2276 Relax XSLT rules on Extension Attributes
See PR [37]#2283.
* MK: This is an attempt to bring the spec into align with common
practice.
+ ... In practice, people (including Saxon) use extension
attributes to do anything where it's useful to vary the
processor.
+ ... Tracing and debugging, that are entirely conformant, and
other things like saying that the collection function is
non-stable, that are not.
* MK: This proposal slightly changes the rules to say that it's okay
to change the behavior if you have good reason, for example,
security.
* MK: The PR also brings extension attributes more in line with
extension functions and elements.
MK reviews the prose of the PR.
* JWL: I can well understand these changes.
Proposal: accept this PR.
Accepted.
3. Any other business
* NW: Enjoy the holidays and Happy New Year!
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/2025/12-16.html#minutes
7. https://qt4cg.org/meeting/minutes/2025/12-16.html#new-actions
8. https://qt4cg.org/meeting/minutes/2025/12-16.html#administrivia
9. https://qt4cg.org/meeting/minutes/2025/12-16.html#roll-call
10. https://qt4cg.org/meeting/minutes/2025/12-16.html#agenda
11. https://qt4cg.org/meeting/minutes/2025/12-16.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2025/12-16.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2025/12-16.html#open-actions
14. https://qt4cg.org/meeting/minutes/2025/12-16.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2025/12-16.html#merge-without-discussion
16. https://qt4cg.org/meeting/minutes/2025/12-16.html#technical-agenda
17. https://qt4cg.org/meeting/minutes/2025/12-16.html#pr-2342
18. https://qt4cg.org/meeting/minutes/2025/12-16.html#pr-2329
19. https://qt4cg.org/meeting/minutes/2025/12-16.html#pr-2324
20. https://qt4cg.org/meeting/minutes/2025/12-16.html#pr-2313
21. https://qt4cg.org/meeting/minutes/2025/12-16.html#pr-2336
22. https://qt4cg.org/meeting/minutes/2025/12-16.html#pr-2323
23. https://qt4cg.org/meeting/minutes/2025/12-16.html#pr-2283
24. https://qt4cg.org/meeting/minutes/2025/12-16.html#any-other-business
25. https://qt4cg.org/meeting/agenda/2025/12-16.html
26. https://qt4cg.org/meeting/minutes/2025/12-09.html
27. https://qt4cg.org/meeting/minutes/2025/12-16.html#technical-agenda
28. https://qt4cg.org/dashboard/#pr-2347
29. https://qt4cg.org/dashboard/#pr-2346
30. https://qt4cg.org/dashboard/#pr-2342
31. https://qt4cg.org/dashboard/#pr-2329
32. https://qt4cg.org/dashboard/#pr-2324
33. https://qt4cg.org/dashboard/#pr-2282
34. https://qt4cg.org/dashboard/#pr-2313
35. https://qt4cg.org/dashboard/#pr-2336
36. https://qt4cg.org/dashboard/#pr-2323
37. https://qt4cg.org/dashboard/#pr-2283
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 16 December 2025 17:42:58 UTC