- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 30 Sep 2025 17:49:46 +0100
- To: public-xslt-40@w3.org
Hello,
Here are the draft minutes from today’s meeting
https://qt4cg.org/meeting/minutes/2025/09-30.html
QT4 CG Meeting 136 Minutes 2025-09-30
[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/9]
* [8]1. Administrivia
+ [9]1.1. Roll call [8/11]
+ [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 [0/9]
+ [14]1.6. Review of open pull requests and issues
o [15]1.6.1. Blocked
o [16]1.6.2. Merge without discussion
o [17]1.6.3. Close without action
* [18]2. Technical agenda
+ [19]2.1. PR #2123: 2051: XSLT group by cluster
+ [20]2.2. PR #2211: 2210 Drop parse-html
include-template-content option
+ [21]2.3. PR #2209: 2165 Rephrase semantics of treat-as
+ [22]2.4. PR #2205: 2190 Drop binary input for parse-csv and
parse-json
* [23]3. Any other business
Draft Minutes
Summary of new and continuing actions [0/9]
* [ ] QT4CG-116-01: Add a specific error code for unsupported options
on doc and doc-available
* [ ] QT4CG-118-01: MK to make an incorrect type raise an error in
#1906
* [ ] QT4CG-127-01: NW to diagram the JTree representing arbitrary
XDM content.
* [ ] QT4CG-128-03: NW to compare the file: module against the
equivalent XProc 3.1 steps
* [ ] QT4CG-131-01: MK to add a non-schema aware result.
* [ ] QT4CG-131-02: MK to expand on the $E := <e A="p q r"... example
* [ ] QT4CG-131-03: MK to change "invert" to "transpose" in the
matrix example.
* [ ] QT4CG-133-01: MK to correct the use of "Expr" in examples for
get()
* [ ] QT4CG-135-01: MK to correct attribute rule 5/d to use the
schema component name
1. Administrivia
1.1. Roll call [8/11]
* [X] David J Birnbaum (DB) [:18-]
* [ ] Reece Dunn (RD)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:06-]
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [X] Wendell Piez (WP)
* [ ] Ed Porter (EP)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW) Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [24]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [25]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 7 October 2025.
No regrets heard.
1.5. Review of open action items [0/9]
(Items marked [X] are believed to have been closed via email before
this agenda was posted.)
* [ ] QT4CG-116-01: Add a specific error code for unsupported options
on doc and doc-available
* [ ] QT4CG-118-01: MK to make an incorrect type raise an error in
#1906
* [ ] QT4CG-127-01: NW to diagram the JTree representing arbitrary
XDM content.
* [ ] QT4CG-128-03: NW to compare the file: module against the
equivalent XProc 3.1 steps
* [ ] QT4CG-131-01: MK to add a non-schema aware result.
* [ ] QT4CG-131-02: MK to expand on the $E := <e A="p q r"... example
* [ ] QT4CG-131-03: MK to change "invert" to "transpose" in the
matrix example.
* [ ] QT4CG-133-01: MK to correct the use of "Expr" in examples for
get()
* [ ] QT4CG-135-01: MK to correct attribute rule 5/d to use the
schema component name
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 [26]Technical Agenda below for
the focus of this meeting.
1.6.1. Blocked
The following PRs are open but have merge conflicts or comments which
suggest they aren't ready for action.
* PR [27]#2124: 573 Functions to Construct Trees
* PR [28]#2120: 2007 Revised design for xsl:array
* PR [29]#2019: 1776: XSLT template rules for maps and array
1.6.2. 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 [30]#2212: 1980 Use HTML5-defined syntax for meta element
* PR [31]#2207: 2196 Clarify XQST0070
* PR [32]#2206: 2204 Change method call expansion so error code
becomes XPTY0004
Proposal: merge without discussion
Accepted.
1.6.3. 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 [33]#1965: The Generator record
+ JLO: I'm really interested in this.
+ MK: I'd be sympathetic to a proposal, but we don't have one.
+ CG: It's interesting, but lots of common data structures, like
linked queues, would be interesting. Are generator functions
really important enough to be in the core spec.
+ JLO: Can we build generators without the core spec?
+ CG: I think it can be built without in the core spec; the
solution from DN is completely written in XQuery.
+ WP: I've heard activity and there are alternative ideas and
that it could be put elsewhere. Can we time box it?
+ NW: The issue has been open for four months. I'm not sure how
setting a deadline is going to encourage proposals.
+ MK: The first issue is two years old.
+ JL: I think that items we can't write in our current language
need to be in the spec. But experimental features that you can
implement in XQuery or XPath don't need to be in the spec.
+ JLO: I think DN pointed out that he would need the generator
record to be defined by the language because you can't define
that in XPath itself.
o ... I also see that there is an XPath implementation.
+ NW: I think folks who want to do this should.
+ MK: I think that good ideas that aren't essential to
completion should be left open.
Proposal: close without further action.
Accepted. (With several in favor and no objections.)
* Issue [34]#1452: Links from the agendas/minutes to the dashboard
don't redirect when the PR is no longer on the dashboard
* Issue [35]#716: Generators in XPath
* Issue [36]#708: Toward a design for generators
Proposal: close with no further action
Accepted.
2. Technical agenda
2.1. PR #2123: 2051: XSLT group by cluster
See PR [37]#2123.
* JK introduces the issue with an example.
The example uses annotations that overlap other structures in the
markup. Another example is quotation detection. Another example is a
multidimensional plot of items. Another is an example of grouping
polygons that overlap or touch.
* JK: The polygon example is similar to a problem in OCR for
identifying paragraphs.
JK turns to the text of the PR.
* JK summarizes "split-when" and "merge-when".
* JK: Might not be used very often, but when it's needed it will be
very appreciated.
* MK: Is the result independent of the order in which you compare
groups?
* JK: I tried that, but the comparitors might be asymmetric. (See the
last example with animals.)
* MK: Do you always have to do n≤ comparisons?
* JK: No, if you can work out that the comparitors are symmetric then
the order doesn't matter.
* JLO: Very interesting. You have a mixture of the different cases
and the examples aren't presented like other examples. That would
be a nice change.
* JK: I did two larger examples, the others were more compact.
* JLO: Should we add a comment about optimization?
* MK: That's always true, but we could add hints if we think they're
useful.
* JWL: Why don't we use functions here, rather than expressions? Then
we wouldn't end up with variables that have special names.
+ ... Is there a reason for this?
* MK: I've had the same question with other things we've added.
Generally, the answer is that making it an expression or a pattern
makes simple cases simpler.
* JK: If we find an alternative that uses functions, we could do
that.
* JWL: In grouping we use reserved functions: `current-group()`,
`current-grouping-key()`
* JLO: This only effects XSLT, right?
* JK: Yes.
* MK: The more exotic features of the languages are sort of unevenly
distributed across XQuery and XSLT. Why do we do advanced windowing
in XQuery and advanced grouping in XSLT? I'm not sure we'd have a
good answer.
* JK: I'd love to see this in XQuery.
Proposal: accept this PR.
Accepted.
2.2. PR #2211: 2210 Drop parse-html include-template-content option
See PR [38]#2211.
* NW: Did we get any feedback from RD on this one?
* MK: I don't think so.
* NW: Shall we wait?
* MK: I'm pretty confident that we want to go ahead. I think the
option would make more sense for implementors than users. I don't
think there's any benefit to users in having a choice. I think the
intuitive way is not compatible with the DOM but the HTML parsers
do it by that way by default.
* JLO: I agree.
Proposal: accept this PR.
Accepted.
2.3. PR #2209: 2165 Rephrase semantics of treat-as
See PR [39]#2209.
MK introduces the PR.
* MK: Remember that treat as is a hangover from strong, static
typing. The way it's described has vestiges of that.
* MK: The main substantive change here is that if treat as fails it's
a type error not a dynamic error.
+ ... Most of the changes are just changing dynamic error to
type error.
+ ... It keeps the error code in case people are catching it.
+ ... The wording changes bring the description into line with
the rest of the spec prose.
* JWL: Can this be raised at runtime and at compile time?
* MK: Yes. It's a type error so you can statically report that 3
treat as xs:string is an error
Proposal: accept this PR.
Accepted.
2.4. PR #2205: 2190 Drop binary input for parse-csv and parse-json
See PR [40]#2205.
* MK introduces the PR. What CG had done in the interest of
consistency was to allow all the parse functions to accept binary
input in additionto text.
+ ... I think for CSV and JSON that's inappropriate and possibly
misleading.
+ ... It makes sense for HTML and XML because the encoding can
be in the file.
+ ... But for CSV and JSON there are no such rules in the
specifications. Decoding is completely orthogonal to the
parsing.
+ ... So I don't think they need to be combined. Except,
perhaps, to make the interfaces similar to other functions.
+ ... We might want a way to decode a string, but that's a
separate issue.
+ ... And if you start with binary input, the binary module
gives you a way to decode them data.
* CG: I think it would be helpful to allow both string and binary. If
you have binary data, the encoding or byte order mark might be in
the data. We don't have any way to infer an encoding from data. You
can do it from data, with unparsed-text(), but that might mean
writing the data to disk in order to infer the encoding.
+ ... I think it would be helpful to have for CSV and JSON data
as well.
+ ... For users who don't care about the specifics of the
specifications, I think it can be helpful to have a uniform
API to the functions.
* MK: If we don't have a function to decode binary based on inferring
the encoding, shouldn't we add one?
* CG: Yes. I've opened a proposal to extend decode-string to be able
to infer the encoding.
+ ... The functions csv-doc and json-doc, would you expect them
to infer the encoding?
* MK: I think the answer there is, if nothing is supplied, I would
expect it. It comes in HTTP headers, for example.
* CG: So I could imagine that someone might want to swap cvs-doc and
parse-csv because the data is already available. So it would be
helpful if the interface was the same. That would be a consistency
issue.
* MK: This is about the parse functions not the doc functions.
+ ... I think it's at the point where you're dealing with the
external resource where you want to decode.
* JLO: I'm uncomfortable dropping it. I'd like to not have the extra
step necessary. Now that I hear that there might be some usefulness
in interpreting the BOM, I'm torn.
* JK: CG, you mentioned another PR for decode string. Where is that?
* CG presents issue [41]#2217 where the proposal exists.
* JK: Would that be used to extend parse functions to do binary.
* CG: That's what I did by putting binary into all the parse
functions.
* MK: JSON and CSV start with characters, so you don't need binary.
* JWL: Is it a great deal of implementation work?
* MK: It's more about writing tests!
* CG: We might also want to consider adding an encoding option.
* MK: That's also a problem, once you add complexity, it starts to
multiply.
+ ... In fact, that's how this started. We have parse-csv that
accepts binary but we have no way of specifying the encoding.
* WP: I'm a bit out of my depth; but in my experience the problem
goes beyond what we can do. The specs say one thing and the world
does something else.
+ ... I think making it transparent and usable on the edges is
good.
+ ... If that's the case, I'd be in favor of allowing binary.
* JK: I think before deciding on the fate of this, we should look at
decode string.
There isn't consensus to make this change; we'll leave the status quo.
3. Any other business
* NW: Next week, I've agreed to let JWL and JLO give a brief summary
of what they're planing to present about QT4 at Declarative
Amsterdam.
* JLO: In the eXist-db community call yesterday, I observed that
there haven't been any plans to update XQuery Update or XQueryX.
* MK: Both were dropped in the 3.x time frame.
* CG: XQuery Update 3.0 is a working group note but many people are
maybe confused by that.
* JK: How can we make functions easier to find.
* MK: I've got an open issue to add better cross referencing from
functions to related functions.
* NW: Maybe we need to think about indexes.
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/09-30.html#minutes
7. https://qt4cg.org/meeting/minutes/2025/09-30.html#new-actions
8. https://qt4cg.org/meeting/minutes/2025/09-30.html#administrivia
9. https://qt4cg.org/meeting/minutes/2025/09-30.html#roll-call
10. https://qt4cg.org/meeting/minutes/2025/09-30.html#agenda
11. https://qt4cg.org/meeting/minutes/2025/09-30.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2025/09-30.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2025/09-30.html#open-actions
14. https://qt4cg.org/meeting/minutes/2025/09-30.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2025/09-30.html#blocked
16. https://qt4cg.org/meeting/minutes/2025/09-30.html#merge-without-discussion
17. https://qt4cg.org/meeting/minutes/2025/09-30.html#close-without-action
18. https://qt4cg.org/meeting/minutes/2025/09-30.html#technical-agenda
19. https://qt4cg.org/meeting/minutes/2025/09-30.html#pr-2123
20. https://qt4cg.org/meeting/minutes/2025/09-30.html#pr-2211
21. https://qt4cg.org/meeting/minutes/2025/09-30.html#pr-2209
22. https://qt4cg.org/meeting/minutes/2025/09-30.html#pr-2205
23. https://qt4cg.org/meeting/minutes/2025/09-30.html#any-other-business
24. https://qt4cg.org/meeting/agenda/2025/09-30.html
25. https://qt4cg.org/meeting/minutes/2025/09-23.html
26. https://qt4cg.org/meeting/minutes/2025/09-30.html#technical-agenda
27. https://qt4cg.org/dashboard/#pr-2124
28. https://qt4cg.org/dashboard/#pr-2120
29. https://qt4cg.org/dashboard/#pr-2019
30. https://qt4cg.org/dashboard/#pr-2212
31. https://qt4cg.org/dashboard/#pr-2207
32. https://qt4cg.org/dashboard/#pr-2206
33. https://github.com/qt4cg/qtspecs/issues/1965
34. https://github.com/qt4cg/qtspecs/issues/1452
35. https://github.com/qt4cg/qtspecs/issues/716
36. https://github.com/qt4cg/qtspecs/issues/708
37. https://qt4cg.org/dashboard/#pr-2123
38. https://qt4cg.org/dashboard/#pr-2211
39. https://qt4cg.org/dashboard/#pr-2209
40. https://qt4cg.org/dashboard/#pr-2205
41. https://github.com/qt4cg/qtspecs/issues/2217
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 30 September 2025 16:49:53 UTC