- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 27 May 2025 17:37:26 +0100
- To: public-xslt-40@w3.org
Hello,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2025/05-27.html
QT4 CG Meeting 123 Minutes 2025-05-27
[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/7]
* [8]1. Administrivia
+ [9]1.1. Roll call [9/12]
+ [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 [1/6]
+ [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. Substantive PRs
* [18]2. Technical agenda
+ [19]2.1. Review of pull requests
+ [20]2.2. What about fn:chain?
+ [21]2.3. PR #1959: 1953 (part) XSLT Worked example using
methods to implement atomic sets
+ [22]2.4. PR #2013: 748 Parse functions: consistency
* [23]3. Any other business
* [24]4. Adjourned
Draft Minutes
Summary of new and continuing actions [0/7]
* [ ] QT4CG-082-02: DN to work with NW to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-112-01: JLO to propose a concrete example that uses "."
in a ~%method~s.
* [ ] 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-119-02: MK to add a note about how schema composition is
done for multiple options
* [ ] QT4CG-123-01: MK to do the set example in XQuery.
1. Administrivia
1.1. Roll call [9/12]
Regrets: BTW, 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] Dimitre Novatchev (DN)
* [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 [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 scheduled for 10 June 2025. (The CG will not meet
on 3 June).
DB gives regrets.
1.5. Review of open action items [1/6]
(Items marked [X] are believed to have been closed via email before
this agenda was posted.)
* [ ] QT4CG-082-02: DN to work with NW to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-112-01: JLO to propose a concrete example that uses "."
in a ~%method~s.
* [ ] 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-119-02: MK to add a note about how schema composition is
done for multiple options
* [X] QT4CG-121-01: MK to raise a new issue which may propose a
subset of the QNameLiteral which doesn't permit a namespace.
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. Blocked
The following PRs are open but have merge conflicts or comments which
suggest they aren't ready for action.
* PR [28]#2019: 1776: XSLT template rules for maps and array
* PR [29]#1883: 882 Replace fn:chain by fn:compose
* PR [30]#1283: 77b Update expressions
* PR [31]#1062: 150bis revised proposal for fn:ranks
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 [32]#2024: Add rules for $V?$X
Proposal: merge without discussion.
Accepted.
1.6.3. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [33]#1984: 882 Drop fn:chain
* PR [34]#1894: Additional examples to fn:chain - in a new branch
* PR [35]#2013: 748 Parse functions: consistency
* PR [36]#1959: 1953 (part) XSLT Worked example using methods to
implement atomic sets
* PR [37]#2011: 675(part): Add XSLT static typing rules for new kinds
of XPath expression
* PR [38]#1942: 37 Support sequence, array, and map destructuring
declarations
* PR [39]#1888: 366 xsl:package-location
* PR [40]#2019: 1776: XSLT template rules for maps and array
* PR [41]#2015: 2009 Avoid constructing document node when it makes
no sense
* PR [42]#2014: QT4CG-122-01 Add notes, examples, and rationale for
xsl:select
2. Technical agenda
2.1. Review of pull requests
2.2. What about fn:chain?
We had a couple of meetings discussing the proposal to replace fn:chain
with fn:compose. The PR for discussion this week simply removes
fn:chain. (In previous straw polls, no one preferred "only fn:chain";
this PR changes the status quo to reflect that.)
I don't expect there's a lot of new technical ground to cover here, so
we'll attempt to time box the discussion. Ultimately, I hope the CG can
express a clear consensus and that everyone in the minority can accept
that consensus.
See PR [43]#1984: 882 Drop fn:chain, and PR [44]#1894: Additional
examples to fn:chain
* DN: I don't think that's correct. I voted for both, that was not a
vote against only fn:chain.
* MK: The PR was a response to the straw poll. People were asked if
they wanted chain or compose or both or neither. There were various
votes, the one that came out lowest was fn:chain only. That's the
status quo, but there was an unwillingness to confirm that change.
So I'm offering the group the simple option of removing it.
* DN: I would first want to apologies on the issue of the PR that
we've spent so much time on. If we couldn't decide in four
attempts, perhaps the arguments against it are unfounded.
DN shares PR #1984 on the screen
* DN: The arguments against are:
+ ... (a) it is more useful to have a function that combines
several functions into a single function, without actually
applying that function to a set of supplied arguments
o ... I have shown this isn't true.
+ ... (b) The function has special-case behaviour for arrays (if
the input is not an array and the function has arity > 1 then
the input sequence is converted to an array).
o ... Previously, the argument was different.
o ... The fn:apply function uses an array and has for eight
years.
o ... The fn:chain function is adhering to this principle.
o ... And array() is the only data type we can use for
this.
+ (c) The need for the function is not clearly motivated; the
examples given can all be achieved in some simpler more
intuitive way.
o ... The argument that something is "more intuitive" is
very subjective.
DN shows some examples. Starting with this from the spec:
(1 to 5) =!> xs:double() =!> math:sqrt() =!> fn($a) { $a + 1 }() => sum()
* DN: I have a lot of sympathy for the end user who has to read or
write this expression.
* DN: Doing this with fn:chain is:
let $increment := fn($x) {$x + 1}
return
chain(1 to 5, (for-each(? chain(? (xs:double#1, math:sqrt#1, $increment))), su
m#1)
* DN: This is much more understandable, there's no repetition of
operators. Chain is being used to compose a chain of functions. And
because chain is also a function, it can be used in chain.
Some discussion of getting rid of =!>. We decided not to.
* JLO: Why would we just drop fn:chain if we don't have fn:compose?
NW attempts to explain that the rational is described in the PR and the
agenda.
* JK: I initially supported fn:chain but I changed my mind. But I
don't find his example motivating at all. I think his alternative
is about 10% longer plus five levels of nesting.
+ ... If that's the sort of thing you like, you can already do
that with a function.
* DN: It is just a little bit longer because it saves three operators
and we have an mnemonic name.
* NW: I find both of these hard to understand.
* JWL: Because we can't agree what the signature of a chain/compose
function, we aren't going to have any?
* MK: Yep.
* JWL: That's kind of sad. If you want to use arrays, you can do
that.
* MK: A quick observation on the example. My PR raised three points,
one about it's special case use of arrays. That's not needed in
this example. And it's better to have something that returns a
function instead of applying it. That's why we have partial
application in it. That's why fn:compose would have been better.
* DN: There are no arrays to be seen here for the user.
+ ... The formal definition uses arrays but that doesn't have
anything to do with what the user sees.
+ ... Besides it's main use case, fn:chain also has another use
case to do the plumbing regardless of the arity of the
function in the chain, which fn:compose couldn't do.
* CG: I would like to remind us that the numbers of users who will
use fn:chain will be very small. Most users don't use function
items at all. Most people will find this irrelevant.
* JLO: The points that MK makes in the PR were the same concerns I
had. Users who want to do this can.
Proposal: accept the PR.
* DN: I object. I think people will regret this decision. We still
have time to fix it.
Accepted over DN's objection.
2.3. PR #1959: 1953 (part) XSLT Worked example using methods to implement
atomic sets
See PR [45]#1959
* MK: The PR still needs a worked example in XQuery. I don't want to
close this until we have.
MK walks thorugh the PR in XSLT.
* MK: I've add an option to not construct an implicit constructor
from the record type.
+ ... Skipping the editorial work of fixing the description of a
binary tree.
MK reviews the example in 5.3.3. Example: Defining an Atomic Set.
* MK: It's interesting that we get a prose description, then a field
definition that describes the API, then we get the function
definitions. We might want to try to do better.
+ ... There's a field we'd like to make private, but we can't,
so I named it with a leading "_".
* JWL: This would be just as easy to put this in as a map in XPath,
wouldn't it?
* MK: Yes.
* JWL: This may be an example of a case where using a record doesn't
really help.
* MK: I experimented with various ways, and I agree that xsl:record
doesn't add that much.
* JLO: That's a complex example that uses "." in record methods.
+ ... Is this meant as an example of the record in XSLT?
* MK: You don't have to use xsl:record. You could replace it with
xsl:map or with an XPath expression that uses a map constructor.
Some discussion of the use of %method in or out of a map or record. MK:
there are several options.
* JLO: Using "_" for a semi-private method reminds of JavaScript in
the old days.
+ ... I would really like to see the merging of the human and
machine readable documentation part.
* MK: Yes, one disadvantage of using xsl:record is that we can't do
that, but we could with xsl:map. That might look better.
+ ... I'm not sure the XPath way would work any better; the
documentation would be in comments.
* DN: This demonstrates the high power we have with methods in
records. We've also had for more than two years to have a set data
type. This demonstration shows that there are no significant
obstacles to doing it.
* JWL: To Mike's point about the documentation, we've added xsl:note.
We could also add an attribute flavor an @xsl:note attribute.
* MK: Yes, but you couldn't have structured text in there.
* RD: Looking at the definition of xsl:note, that says it can appear
anywhere. So should that be updated?
* MK: The problem is the list of attributes in the definition.
Proposal: accept this PR.
Accepted.
ACTION: QT4CG-123-01: MK to do the set example in XQuery.
2.4. PR #2013: 748 Parse functions: consistency
See PR [46]#2013
CG reviews the PR.
* CG: We've added parse-html and json-doc and parse-json and doc.
There are inconsistencies between them I'd I've tried to align
them. And I've added document functions for CSV.
+ fn:parse-xml: Basically the same as before but you can specify
binary input.
o ... There were questions about this. But there are cases
where binary input comes in.
o ... You can manage that by writing to disk and loading
the file, but this is easier.
o ... I think the same arguments apply to fn:parse-html.
o ... The encoding may be embedded in the binary, so you
can't just convert it to a string first.
o ... Mostly the rules have been extended a little. My
description of how encoding is detected is a bit vague,
but it should be more similar to fn:doc. But that
function doesn't give much detail either. All that fn:doc
says is that the data is "parsed as XML".
* RD: Could we express fn:doc in terms of fn:parse-xml?
* CG: Maybe we could. In many cases fn:doc depends on the
implementation.
RD sketches out how it might be possible.
* MK: All the material we have that talks about the dynamic context
having a mapping from URIs to resources is something that it would
be nice to unify across these functions.
* CG: Right.
* RD: Or maybe we could talk about parsing them into a string.
* MK: It'd be nice to say that the functions are the composition of
three functions: getting a resource from a URI, turning a binary
into a string, and the parsing a string.
* RD: Or have those as separate sections.
* CG: fn:parse-xml-fragment is similar.
* CG: fn:html-doc is new, it's an alignment with JSON doc mostly
+ ... That description uses some composition.
* CG: We allow binary input to for JSON, similarly, and we add a
fn:csv-doc function.
* CG: I haven't added binary flavors of CSV parsing, but those are
all accessible in the XPath. We don't need to serialize those.
* JWL: Brave to change the fn:doc function given it's been around for
twenty years!
* JK: The one thing I don't like about allowing binary in
fn:parse-xml, I want to be forced to use another function and keep
fn:parse-xml() simple.
+ ... Are there really use cases to motivate this?
* RD: The use case is, if you have a blob of binary data, detecting
the encoding of XML and HTML is complicated. You have to deal with
byte order, etc.
* JK: I understand, but why are we putting this in fn:parse-xml
instead of some sort of handler function.
* CG: What's the alternative?
* JK: I'm not proposing one, but I think this muddies the water. If I
accidentally send binary data to fn:parse-xml(), I want an error to
be raised.
Some discussion of parsing UTF 8 or parsing binary XML.
* RD: With XML and HTML parsers, they accept binary data. So having
binary data as an option to these functions let's you pass the data
straight through to those parsers without preprocessing. But I
wouldn't object to separate functions.
* JLO: I am a fan of opening this up. It will allow streaming
parsing. I was wondering if the use of new functions (html-doc and
csv-doc) that are expressed in terms of unparsed text. Is that good
enough?
+ Could parse-csv use binary; then it gets muddy.
* CG: Maybe a "parse binary" option would be good.
* JK: I'd like to add an option to specify the parser to fn:doc()!
* MK: I think the reasons that the specifications wind up being muddy
is that the three operations I described aren't as independent of
each other as we might like. In particular, the encoding detection
is done on the fly by the parser.
+ ... But I think CG's proposal is going in the right direction.
I think it should just be more explicit that the decoding is
delegated to the relevant spec.
Some discussion of whether to accept it or not.
We'll look again in two weeks.
3. Any other business
* JK: I've made a couple of pull requests to the XSLT test suite?
* MK: I'll take a look. I look occasionally.
4. Adjourned
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/05-27.html#minutes
7. https://qt4cg.org/meeting/minutes/2025/05-27.html#new-actions
8. https://qt4cg.org/meeting/minutes/2025/05-27.html#administrivia
9. https://qt4cg.org/meeting/minutes/2025/05-27.html#roll-call
10. https://qt4cg.org/meeting/minutes/2025/05-27.html#agenda
11. https://qt4cg.org/meeting/minutes/2025/05-27.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2025/05-27.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2025/05-27.html#open-actions
14. https://qt4cg.org/meeting/minutes/2025/05-27.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2025/05-27.html#blocked
16. https://qt4cg.org/meeting/minutes/2025/05-27.html#merge-without-discussion
17. https://qt4cg.org/meeting/minutes/2025/05-27.html#substantive
18. https://qt4cg.org/meeting/minutes/2025/05-27.html#technical-agenda
19. https://qt4cg.org/meeting/minutes/2025/05-27.html#technical-prs
20. https://qt4cg.org/meeting/minutes/2025/05-27.html#fn-chain
21. https://qt4cg.org/meeting/minutes/2025/05-27.html#pr-1959
22. https://qt4cg.org/meeting/minutes/2025/05-27.html#pr-2013
23. https://qt4cg.org/meeting/minutes/2025/05-27.html#any-other-business
24. https://qt4cg.org/meeting/minutes/2025/05-27.html#adjourned
25. https://qt4cg.org/meeting/agenda/2025/05-27.html
26. https://qt4cg.org/meeting/minutes/2025/05-20.html
27. https://qt4cg.org/meeting/minutes/2025/05-27.html#technical-agenda
28. https://qt4cg.org/dashboard/#pr-2019
29. https://qt4cg.org/dashboard/#pr-1883
30. https://qt4cg.org/dashboard/#pr-1283
31. https://qt4cg.org/dashboard/#pr-1062
32. https://qt4cg.org/dashboard/#pr-2024
33. https://qt4cg.org/dashboard/#pr-1984
34. https://qt4cg.org/dashboard/#pr-1894
35. https://qt4cg.org/dashboard/#pr-2013
36. https://qt4cg.org/dashboard/#pr-1959
37. https://qt4cg.org/dashboard/#pr-2011
38. https://qt4cg.org/dashboard/#pr-1942
39. https://qt4cg.org/dashboard/#pr-1888
40. https://qt4cg.org/dashboard/#pr-2019
41. https://qt4cg.org/dashboard/#pr-2015
42. https://qt4cg.org/dashboard/#pr-2014
43. https://qt4cg.org/dashboard/#pr-1984
44. https://qt4cg.org/dashboard/#pr-1894
45. https://qt4cg.org/dashboard/#pr-1959
46. https://qt4cg.org/dashboard/#pr-2013
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 27 May 2025 16:37:32 UTC