- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 06 May 2025 17:38:06 +0100
- To: public-xslt-40@w3.org
Hi folks,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2025/05-06.html
QT4 CG Meeting 120 Minutes 2025-05-06
[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/6]
* [8]1. Administrivia
+ [9]1.1. Roll call [7/12]
+ [10]1.2. Accept the agenda
o [11]1.2.1. Status so far...
+ [12]1.3. Approve minutes of the previous meeting
+ [13]1.4. Next meeting
+ [14]1.5. Review of open action items [5/10]
+ [15]1.6. Review of open pull requests and issues
o [16]1.6.1. Blocked
o [17]1.6.2. Merge without discussion
o [18]1.6.3. Substantive PRs
* [19]2. Technical agenda
+ [20]2.1. Review of pull requests
+ [21]2.2. PR #1883/1894: fn:chain and fn:compose
+ [22]2.3. PR #1976: 1661 Introduce QName literals
+ [23]2.4. PR #1975: 1240 Allow operand of dynamic function call
to be a sequence
* [24]3. Any other business
* [25]4. Adjourned
Draft Minutes
Summary of new and continuing actions [0/6]
* [ ] QT4CG-082-02: DN to work with NW to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-107-05: JLO and DN to consider a proposal for system
defined records.
* [ ] 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
1. Administrivia
1.1. Roll call [7/12]
Regrets: JWL, JLO
* [X] David J Birnbaum (DB)
* [ ] Reece Dunn (RD)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [ ] Juri Leino (JLO)
* [ ] 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 [26]the agenda.
Accepted.
1.2.1. Status so far...
These charts have been adjusted so they reflect the preceding six
months of work.
issues-open-2025-05-06.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2025-05-06.png
Figure 2: Open issues by specification
issues-by-type-2025-05-06.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [27]the minutes of the previous meeting, as amended.
Accepted.
1.4. Next meeting
The next meeting is scheduled for 13 May 2025.
Unlikely to achieve quorem for a face-to-face meeting colocated with
MarkupUK.
Norm is at risk.
1.5. Review of open action items [5/10]
(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-107-05: JLO and DN to consider a proposal for system
defined records.
* [ ] 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
* [X] QT4CG-119-01: NW will add a bit of prose about * and then merge
the PR 1961
* [ ] QT4CG-119-02: MK to add a note about how schema composition is
done for multiple options
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 [28]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 [29]#1942: 37 Support sequence, array, and map destructuring
declarations
* 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]#1974: 1973 Cross-reference from type analysis to definition
of disjointedness
* PR [33]#1971: 1951 Clarifications on serialization parameters
* PR [34]#1969: 1952 Change option name xsi-schema-location
* PR [35]#1968: 1967 r/binary-resource/unparsed-binary/
* PR [36]#1964: 1957 xsl output allows mixed content
* PR [37]#1963: 1958 Fix simple typo in map:build
Proposal: accept these PRs without discussion.
Accepted.
1.6.3. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [38]#1977: 1889 Tidy up handling of HTML serialization version,
default to HTML5
* PR [39]#1976: 1661 Introduce QName literals
* PR [40]#1975: 1240 Allow operand of dynamic function call to be a
sequence
* PR [41]#1971: 1951 Clarifications on serialization parameters
* PR [42]#1964: 1957 xsl output allows mixed content
* PR [43]#1959: 1953 (part) XSLT Worked example using methods to
implement atomic sets
* PR [44]#1894: Additional examples to fn:chain - in a new branch
* PR [45]#1888: 366 xsl:package-location
* PR [46]#1883: 882 Replace fn:chain by fn:compose
2. Technical agenda
2.1. Review of pull requests
2.2. PR #1883/1894: fn:chain and fn:compose
Related PRs:
* PR [47]#1883: 882 Replace fn:chain by fn:compose
* PR [48]#1894: Additional examples to fn:chain - in a new branch
We need to come to some resolution on this issue. Recall that in last
week's straw poll, there were only two options that got any votes at
all: fn:compose (only) got 6 votes, both got 3 votes.
I'm going to time box this discussion to 10 minutes. If, after that
time, there is still a substantial majority in favor of fn:compose
only, I'm going to ask the minority to accept that the consensus does
not favor keeping fn:chain as well.
* JK: After looking a little bit closer, I'm not convinced we need
either. I would vote to drop both.
+ ... We should be wrapping things up; if there's a new
function, there should be higher bar.
* DN: Last week, we discussed several claims that I have shown to be
incorrect.
+ ... The chain function is easier to use than apply.
+ ... I asked JLO to give me an example of where fn:chain
doesn't behave as expected, but he didn't provide one.
+ ... You can't use arrow notation for consumers that have more
than one argument without more plumbing.
+ ... The fn:chain function is like checking your luggage all
the way through to your destination.
* DN: Replacing one function of with another that has less
functionality is not an improvement.
+ ... The fn:compose function has less functionality so it's not
a suitable substitution.
* DN: There are errors in the formal definition of fn:compose, so I'd
have to vote against it.
* MK: I think fn:compose is a much simpler function. It's an
improvement because it's simpler and easier to understand. It
doesn't try to be polymorphic depending on the arguments.
+ ... I know there are some editorial nits in the specification;
I'll fix those if the PR is accepted.
* WP: I'm on the fence. I've heard different claims that I find hard
to reconcile. JK made a case for abstaining altogether. Should we
have time to think about that.
* MK: They aren't primitives; these functions have formal
equivalents. You can write them yourself. You have to be fairly
expert to do that, but you can.
* WP: One thing that we lack is compelling examples of why your
average user, not your deep user, would want to use these
functions.
+ ... Maybe we should just show the deep user how to do that.
* DN: Function fn:chain was specifically produced as a response to
some very ugly examples of long lambda expressions containing a
variety of two and three character operators that were very hard to
understand.
+ ... I proposed fn:chain because it simplifies these cases.
* MK: Equally, the fn:compose function was motivated by a specific
use case; supplying not matches to a function that expected a
callback.
* DN: Both functions are complimentary.
NW asks if there are concrete actions we could take that would help us
resolve this next week?
* JK: I don't feel like the question I asked in the PR has been
answered, and for every example that I've seen, I think there are
two or three other ways to do it.
+ ... Every example should say something that other examples
haven't.
No proposals to undertake actions where forthcoming.
Straw poll:
Option Votes
fn:compose (only) 3
fn:chain (only) 0
both 1
neither 2
* WP: Examples would be helpful.
* NW: Perhaps, but no one voluntered to do that.
We reached no conclusion this week, the chair declares enough time has
been spent on this issue for this week.
2.3. PR #1976: 1661 Introduce QName literals
See PR [49]#1976
MK introduces the proposal without screen sharing.
* MK: We have a lot of functions that accept QNames as arguments, or
maps that have them as keys or values.
+ ... Constructing a QName is verbose.
+ ... There are two proposals for resolving that:
o ... CG proposed promoting strings to QNames; but it only
works for strings in no namespace.
o ... I've got a different proposal for the case where the
QName is statically known.
+ ... My preference is QName literals and I proposed a syntax
for it.
+ ... It only works if you know the names statically, but it
considerably simplfies things in those cases.
+ ... I think the groups reluctance to add new syntax is
healthy, but I think this is worther.
* CG: As MK said, I have some other suggestions. But I would
definitely vote for MK's proposal. I think it's a clear improvement
and my proposals aren't as general enough. I like the # syntax more
than the other one.
+ ... What I'd like is to allow curly braces to directly add the
URI without a prefix. In XQuery, the namespace context is
effected by context.
* MK: That's allowed; hash followed by an EQName.
* JK: I don't know that I fully undertand the implications without a
little bit of screen sharing. Can you explain?
MK switches to screen sharing.
* MK walks through the changes to XPath...
* JK: I've run into enough places where I've been forced to use
xs:QName(). I think this is a great improvement; I worry that it
might be overused.
* MK: Yes, I think there's some risk that it will get used in
function names and element names and in places where it's not
appropriate.
Some discussion of possible ambiguities. None are apparent.
Proposal: accept this PR.
Accepted.
2.4. PR #1975: 1240 Allow operand of dynamic function call to be a sequence
See PR [50]#1975
MK introduces the PR.
* MK: This is about dynamic function calls in XPath.
+ ... We no longer insist that the left hand side of a function
call be a single item.
+ ... we apply sequence concatentation to the results.
+ ... The example is illustrative: (MK walks through the example
in 4.5.3.)
+ ... The idea is to make method application work much more like
looking up fields and the "/" in an XML document.
* DN: MK missed something important, if a method is invoked on an
empty sequence it shouldn't raise an error. It should just return
an empty sequence.
+ ... This is an antipattern.
+ ... This would be a very foolish thing to do, but an error
must be raised if someone attempts to invoke a method on an
empty sequence.
* MK: The antipattern is operations on nulls, but we don't have a
null. We have an empty sequence and it's entirely reasonable to
call methods on an empty sequence.
* DN: Empty sequence is the closest thing we have to null.
* MK: This is the way the language has worked since XPath 1.0; it's
like XML. A book can have 0 or more authors; an XPath expression
can return 0 or more authors; asking for the names of the authors
will succeed even if there are no authors.
+ ... XPath has always worked that way; this use case is
actually the outlier.
* CG: I completely agree with MK that it's the very philosophy of
XPath to be able to handle empty sequences and just go on. It's
true of path expressions, simple lookup, etc.
+ ... This is one exception where we do something differently
and I think it would be completely justified to align the
behavior.
CG shows an example from the PR.
let $map := { 'giovanni': { 'city': 'roma' }, 'sara': { 'city': 'napoli' } }
return (
(: A :) $map?andrea?city
(: B :) $map('andrea')('city')
)
* CG: (A) works, but (B) raises an error. That's inconsistent.
+ ... Particularly for data access, I think there's no reason to
enforce a different behavior.
* JK: I think it's a nice convenience to be able to have multiples.
We can discuss errors separately.
* MK: There's a second PR from CG on the static type checking of
lookup expressions.
Proposal: Accept the PR.
DN objects.
The PR is accepted over DN's objection.
3. Any other business
None heard.
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-06.html#minutes
7. https://qt4cg.org/meeting/minutes/2025/05-06.html#new-actions
8. https://qt4cg.org/meeting/minutes/2025/05-06.html#administrivia
9. https://qt4cg.org/meeting/minutes/2025/05-06.html#roll-call
10. https://qt4cg.org/meeting/minutes/2025/05-06.html#agenda
11. https://qt4cg.org/meeting/minutes/2025/05-06.html#so-far
12. https://qt4cg.org/meeting/minutes/2025/05-06.html#approve-minutes
13. https://qt4cg.org/meeting/minutes/2025/05-06.html#next-meeting
14. https://qt4cg.org/meeting/minutes/2025/05-06.html#open-actions
15. https://qt4cg.org/meeting/minutes/2025/05-06.html#open-pull-requests
16. https://qt4cg.org/meeting/minutes/2025/05-06.html#blocked
17. https://qt4cg.org/meeting/minutes/2025/05-06.html#merge-without-discussion
18. https://qt4cg.org/meeting/minutes/2025/05-06.html#substantive
19. https://qt4cg.org/meeting/minutes/2025/05-06.html#technical-agenda
20. https://qt4cg.org/meeting/minutes/2025/05-06.html#technical-prs
21. https://qt4cg.org/meeting/minutes/2025/05-06.html#h-92337C4E-B551-4176-894D-E6A787B9E12D
22. https://qt4cg.org/meeting/minutes/2025/05-06.html#pr-1976
23. https://qt4cg.org/meeting/minutes/2025/05-06.html#pr-1975
24. https://qt4cg.org/meeting/minutes/2025/05-06.html#any-other-business
25. https://qt4cg.org/meeting/minutes/2025/05-06.html#adjourned
26. https://qt4cg.org/meeting/agenda/2025/05-06.html
27. https://qt4cg.org/meeting/minutes/2025/04-29.html
28. https://qt4cg.org/meeting/minutes/2025/05-06.html#technical-agenda
29. https://qt4cg.org/dashboard/#pr-1942
30. https://qt4cg.org/dashboard/#pr-1283
31. https://qt4cg.org/dashboard/#pr-1062
32. https://qt4cg.org/dashboard/#pr-1974
33. https://qt4cg.org/dashboard/#pr-1971
34. https://qt4cg.org/dashboard/#pr-1969
35. https://qt4cg.org/dashboard/#pr-1968
36. https://qt4cg.org/dashboard/#pr-1964
37. https://qt4cg.org/dashboard/#pr-1963
38. https://qt4cg.org/dashboard/#pr-1977
39. https://qt4cg.org/dashboard/#pr-1976
40. https://qt4cg.org/dashboard/#pr-1975
41. https://qt4cg.org/dashboard/#pr-1971
42. https://qt4cg.org/dashboard/#pr-1964
43. https://qt4cg.org/dashboard/#pr-1959
44. https://qt4cg.org/dashboard/#pr-1894
45. https://qt4cg.org/dashboard/#pr-1888
46. https://qt4cg.org/dashboard/#pr-1883
47. https://qt4cg.org/dashboard/#pr-1883
48. https://qt4cg.org/dashboard/#pr-1894
49. https://qt4cg.org/dashboard/#pr-1976
50. https://qt4cg.org/dashboard/#pr-1975
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 6 May 2025 16:38:13 UTC