- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 15 Nov 2022 18:00:42 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2edu49jx6.fsf@saxonica.com>
See
https://qt4cg.org/meeting/minutes/2022/11-15.html
QT4 CG Meeting 011 Minutes 2022-11-15
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [1/8]
* [3]1. Administrivia
+ [4]1.1. Roll call [10/13]
+ [5]1.2. Accept the agenda
+ [6]1.3. Next meeting
+ [7]1.4. Approve minutes of the previous meeting
+ [8]1.5. Review of open action items [7/8]
+ [9]1.6. Merging PRs that are accepted in principle
+ [10]1.7. Meeting logistics
* [11]2. Technical Agenda
+ [12]2.1. Review pull request #197 (was 166; variadic
functions)
+ [13]2.2. Review pull request #210: Issue 80: fn:while
+ [14]2.3. Review pull request #202 (was 196; subtyping)
+ [15]2.4. Review pull request #207: new expanded-QName function
+ [16]2.5. Review pull request #215: parse-uri/build-uri
+ [17]2.6. Review pull request #222: sequence comparisons
+ [18]2.7. Review pull request #228: make F&O spec valid XML
+ [19]2.8. Review pull request #230: guarded expressions, issue
#71
* [20]3. Any other business
Draft Minutes
Summary of new and continuing actions [1/8]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-011-01: MK to fix the reference to "function" in XPath
4.4.1.
* [ ] QT4CG-011-02: CG to work with DN to propose an "until" variant.
* [ ] QT4CG-011-03: MK to change the references to URI qualified name
in both QName-related functions.
* [ ] QT4CG-011-04: NW to define the parse-uri/build-uri record types
in a separate section
* [ ] QT4CG-011-05: NW to update the history for parse-uri/build-uri
to indicate that details are still being resolved
* [ ] QT4CG-011-06: NW to make sure ednotes are rendered.
* [X] QT4CG-011-07: NW to make sure the meeting passcode is on the
logistics page
+ This is already the case
1. Administrivia
1.1. Roll call [10/13]
Regrets BTW
* [X] Anthony (Tony) Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [0:15-]
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Ed Porter (EP)
* [ ] Liam Quin (LQ)
* [ ] Adam Retter
* [X] C. M. Sperberg-McQueen (MSM)
* [ ] Bethan Tovey-Walsh (BTW). Scribe. Chair.
* [X] Norm Tovey-Walsh (NW)
1.2. Accept the agenda
Proposal: Accept [21]the agenda.
Accepted.
1.3. Next meeting
The next meeting [22]is scheduled for Tuesday, 22 November.
Regrets: JL for 22 and 29 November.
1.4. Approve minutes of the previous meeting
Proposal: Accept [23]the minutes of the previous meeting.
Accepted.
1.5. Review of open action items [7/8]
(Items marked [X] are believed to have been closed via email before
this agenda was posted.)
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [X] QT4CG-007-05: NW to make an issue for Martin's proposed
ammendment to map:build
+ See [24]issue #236.
* [X] QT4CG-008-04: MK to submit a PR for fn:parseQName() to resolve
PR #207
+ Mike reports the action is complete in PR #207
* [X] QT4CG-009-01: NW to coordinate with MK on an agenda for 8
November.
* [X] QT4CG-009-02: NW to work with MK to make sure PR #197 is
updated correctly
* [X] NW to update PR #215
+ [X] QT4CG-009-03: NW to investigate the relationship between
PR #215 and resolve-uri.
+ [X] QT4CG-009-04: NW to review RFC 3896 wrt relative URIs
+ [X] QT4CG-009-05: NW to fix the return type for parse-uri;
consider using a record type.
+ [X] QT4CG-009-06: NW to add error tests for parse-uri.
+ [X] QT4CG-009-07: NW to make the query segments an array of
maps.
* [X] QT4CG-010-01: DN to create an issue for proposing an optional
else in XPath/XQuery
* [X] QT4CG-010-02: MK to incorporate the suggestions made by MSM on
@then/@else on xsl:if
+ [25]https://lists.w3.org/Archives/Public/public-xslt-40/2022No
v/0013.html
1.6. Merging PRs that are accepted in principle
We've been keeping PRs open while detailed comments are worked out. I
think that's a fine model, but it has the consequence that we end up
with a lot of PRs open for a long time. That increases the chances that
we'll create merge conflicts, making our life more difficult later, and
means that there are many slightly different copies of each spec to
review.
I propose that we agree to merge PRs as soon as the group feels that
the proposal is complete enough to accept in principle. We can add a
note in the history (for functions, at least) that it's provisionally
accepted until detailed comments are resolved, or words to that effect.
In the very short term, I would especially like to merge all of the PRs
that are open against F&O so that the XML validity errors and the new
markup for "type references" can be sorted out.
* RD: That makes sense
* JL: Where do discussions happen?
* NW: I think we get discussion in the issues until there's a PR,
then on the PR.
* MSM: In groups that I have been in that use a two-pass approach,
the point of not considering things changed until the wording is
all correct, one side effect is that if there are minor side
effects in the wording, if we merge earlier, is there a way to
ensure that nits don't fall under the table?
* MK: I've usually seen that managed through actions
* MSM: Okay.
* NW: At least in F&O, we have a history section where we can observe
that it's unresolved.
* MK: XMLSpec also has an ednote; we could render them.
ACTION QT4CG-011-06: NW to make sure ednotes are rendered.
Proposal: merge PRs when they're accepted in principle.
Agreed.
1.7. Meeting logistics
DN observes that he had trouble getting into the meeting. There was a
different Zoom link and passcode last week and, for some reason, Zoom
asked DN for a passcode this week.
ACTION QT4CG-011-07: NW to make sure the meeting passcode is on the
logistics page
2. Technical Agenda
2.1. Review pull request #197 (was 166; variadic functions)
* See [26]pull request #197 (you'll find links to formatted versions
of the specs at [27]https://qt4cg.org/).
* See also the nexus of issues [28]#162, [29]#161, [30]#160,
[31]#159, [32]#158, [33]#157, and [34]#155.
* See the discussion from [35]meeting 006, [36]meeting 007, and
[37]meeting 008.
NW updated the PR with MK's most recent changes.
We hope to resolve this PR this week.
* MSM: I noticed that somewhere in the middle, some of the new text
uses the unqualified term "function" and it caught my eye partly
because early on in this pull requestion there's a note that we use
the term "function item". Was that change intentional, or does it
need a tweak?
* MK: This crosses a couple of PRs. The Data Model uses the term
"function" to mean an item. I've for the moment stuck to that, but
I've also proposed changing it otherwise it gets too confused with
static functions which aren't function items.
* MSM: I had the impression that in a lot of cases in this PR we were
using function item.
* MK: Yes, but it's probably not uniformly applied.
* MSM: I'm pretty sure that the bit that caught my eye was "apropos
of lookup" where there's a reference that's neither to a function
definition or a function item, just a "function".
Subsequent discussion reveals that the editor thinks the sentence is
(too?) informal.
ACTION QT4CG-011-01: MK to fix the reference to "function" in XPath
4.4.1.
* RD: Looking through the grammar, the function signature with
defaults is a sequence of param with defaults with optional default
values. So according the grammar you can interleave optional and
non-optional parameters. But elsewhere we say that required ones
have to come first.
* MK: I decided to make that an extra-grammatical rule.
* RD: That makes sense, the grammar is difficult to get right.
* NW: An action to add it to A.1.2?
* MK: No, I don't think that's necessary. We have too many
constraints like this that aren't mentioned.
Proposal: Accept this PR?
Accepted.
2.2. Review pull request #210: Issue 80: fn:while
* See [38]pull request #210 and the [39]minutes of two weeks ago.
We hope to resolve this PR this week.
* CG: I renamed the function from fn:while to fn:iterate-while per
DN. Most use cases can be realized with this function, so I haven't
explored the until variant.
* MSM: The one question I have relates to a remark that MK made. If
you want to generate a sequence of items until something happens,
is there a way to do that using fn:iterate-while. This isn't a
reason not to accept the proposal, I'm just curious.
* CG: I think it's absolutely possible, you can generate any kind of
data structure you want. You can pass the sequence along, etc.
Proposal: Accept this PR?
* DN: I think that it would be good to discuss fn:iterate-until now.
* MK: Do we have a spec for fn:iterate-until?
* MSM: How would it be different?
* DN: The condition is just the opposite condition.
* CG: We also talked about having the action performed at least once.
Then we wouldn't need to negate the predicate.
* MK: Point of order: there's no proposal for this.
ACTION QT4CG-011-02: CG to work with DN to propose an "until" variant.
Proposal: Accept this PR?
Accepted.
2.3. Review pull request #202 (was 196; subtyping)
See [40]pull request #202
* MK: The principle changes are to the section on defining subtyping
rules. There were two major comments on the original proposal: lots
of good detail from RD and a question of the fundamental nature of
atomic values from MSM. I propose to address the latter in a
different issue.
+ ... This primarily addresses the subtyping rules that are
common between XPath and XQuery.
* NW: The diffs are awful, they don't deal with the notation changes.
* MK: Where RD raised technical questions, I've managed to persuade
myself that it's only more explicit.
* RD: I'm happy with the changes. The only minor thing is that in the
generated output, the example blocks don't have the proper styling.
* MSM: An editorial point, hopefully not a bike-shedding issue, you
are using the notation "itemtype-subtype" with two arguments as a
more verbose way of notating the subtype relation. But my instinct
is that if you are going to name a binary relation for the types or
roles of its arguments, the order of the name should be the same as
the name of the arguments. So, change the order or change the name
to "subtype-itemtype"
* MK: I kept the function notation basically in case people refer to
it.
* MSM: So that pseudo function with its backwards arguments, as I see
it, is a ship that has sailed.
* MK: Yes. And it always confused me which is why I got rid of it.
Proposal: Accept this PR?
Accepted.
2.4. Review pull request #207: new expanded-QName function
See [41]pull request #207
* RD: The spec references braced URI literal, which is the "U{" part
of the construct. What it needs to be is the "URI qualified name"
instead. That's the "Q{}local-name".
* MK: Uhm...
* RD: If you look at the expanded QName section.
* MK: Yes, you're right.
* MSM: I think there's another place where braced URI literal is
referred to that should perhaps be expanded QName. I'm looking at
F&O section 10.1.2 under fn:parse-QName().
ACTION QT4CG-011-03: MK to change the references to URI qualified name
in both QName-related functions.
* MK: In the last paragraph, the reference to BracedURILiteral is ok.
Proposal: Accept the PR?
Accepted.
2.5. Review pull request #215: parse-uri/build-uri
See [42]pull request #215
Waiting on actions QT4CG-009-0{3,4,5,6,7} on NW.
* RD: Make a separate subsection like RegEx pattern and point to it
from both places.
ACTION QT4CG-011-04: NW to define the parse-uri/build-uri record types
in a separate section
ACTION QT4CG-011-05: NW to update the history for parse-uri/build-uri
to indicate that details are still being resolved
2.6. Review pull request #222: sequence comparisons
See [43]pull request #222
Accepted at [44]meeting 009, waiting for MK to resolve a merge
conflict.
2.7. Review pull request #228: make F&O spec valid XML
See [45]pull request #228
Approved by RD, waiting for open PRs on F&O to be accepted, then NW
will resolve any merge conflicts that arise and commit it.
Proposal: Accept the PR (after resolving merge conflicts)?
Accepted.
2.8. Review pull request #230: guarded expressions, issue #71
See [46]pull request #230 and related [47]issue #71.
Approved by CG.
* MK: The section on errors and optimization, which was always
troublesome, gives implementations an awful lot of license to
rearrange expressions in ways that introduce and eliminate errors.
There's a very limited set of exceptions for conditional
expressions. What this does is take out that text for conditional
expressions from 2.3.4 and generalize it into the concept of
guarded expressions in 2.3.5. It gives similar guarantees for a
number of other cases: "and" and "or" expressions where it says the
first is guarded by the second; the same for multiple predicates,
they behave like "and".
+ ... It also says that for loops, if you pull something out of
the loop, it can't raise an error if the loop is executed zero
times.
* MSM: I'm not up to speed on this, if I've understood correctly, the
upshot is that implementations can still reorder things, but if the
reordered code raises an error, you have to work out if it would
have raised the error in the original order.
* JL: Why is this in XQuery instead of XPath?
* MK: It's in both.
* DN: I fully support this, but it just touches on the surface and we
need to consider the topic of short circuit operators. Many
languages have short circuiting operators. Maybe we can consider
allowing the programmer to specify hints about possible lazy
evaluation.
* MK: I'm very conscious that the whole treatment of error handling
is still extremely informal and this is a small step in the
direction of making it a bit more formal. Unfortunately, I'm not a
formalist. It would be nice to have someone who could really do the
formal semantics of error handling much more thoroughly.
+ ... With respect to lazy evaluation, we've done hints before
(ordered vs unordered) and they've been spectacularly
unsuccessful. Implementors ignore them, users don't understand
them, so I have doubts about hints are likely to be of
widespread benefit.
* RD: There is a formal semantics for XPath/XQuery 1.0 but that got
abandoned.
Proposal: Accept this PR?
Accepted.
3. Any other business
None heard.
References
1. https://qt4cg.org/meeting/minutes/2022/11-15.html#minutes
2. https://qt4cg.org/meeting/minutes/2022/11-15.html#new-actions
3. https://qt4cg.org/meeting/minutes/2022/11-15.html#administrivia
4. https://qt4cg.org/meeting/minutes/2022/11-15.html#roll-call
5. https://qt4cg.org/meeting/minutes/2022/11-15.html#agenda
6. https://qt4cg.org/meeting/minutes/2022/11-15.html#next-meeting
7. https://qt4cg.org/meeting/minutes/2022/11-15.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2022/11-15.html#open-actions
9. https://qt4cg.org/meeting/minutes/2022/11-15.html#merging-prs
10. https://qt4cg.org/meeting/minutes/2022/11-15.html#meeting-logistics
11. https://qt4cg.org/meeting/minutes/2022/11-15.html#technical-agenda
12. https://qt4cg.org/meeting/minutes/2022/11-15.html#pr-variadic-functions
13. https://qt4cg.org/meeting/minutes/2022/11-15.html#pr-fn-while
14. https://qt4cg.org/meeting/minutes/2022/11-15.html#pr-subtyping
15. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-743C4A9D-BAEF-4C75-A412-BDFAA9C89856
16. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-11CAAAFD-8175-4D10-83FA-BEC6AA3312A6
17. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-04B58DC1-A005-4AD5-83F0-B3BCE110FB76
18. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-37009862-494E-4CCE-9FA7-DE5B2E9F8474
19. https://qt4cg.org/meeting/minutes/2022/11-15.html#h-A132F93F-0414-4495-A868-A7F32A6D642A
20. https://qt4cg.org/meeting/minutes/2022/11-15.html#any-other-business
21. https://qt4cg.org/meeting/agenda/2022/11-15.html
22. https://qt4cg.org/meeting/agenda/2022/11-22.html
23. https://qt4cg.org/meeting/minutes/2022/11-08.html
24. https://github.com/qt4cg/qtspecs/issues/236
25. https://lists.w3.org/Archives/Public/public-xslt-40/2022Nov/0013.html
26. https://qt4cg.org/dashboard/#pr-197
27. https://qt4cg.org/
28. https://github.com/qt4cg/qtspecs/issues/162
29. https://github.com/qt4cg/qtspecs/issues/161
30. https://github.com/qt4cg/qtspecs/issues/160
31. https://github.com/qt4cg/qtspecs/issues/159
32. https://github.com/qt4cg/qtspecs/issues/158
33. https://github.com/qt4cg/qtspecs/issues/157
34. https://github.com/qt4cg/qtspecs/issues/155
35. https://qt4cg.org/meeting/minutes/2022/10-11.html#pr-variadic-functions
36. https://qt4cg.org/meeting/minutes/2022/10-18.html#pr-variadic-functions
37. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-variadic-functions
38. https://qt4cg.org/dashboard/#pr-210
39. https://qt4cg.org/meeting/minutes/2022/11-01.html#pr-fn-while
40. https://qt4cg.org/dashboard/#pr-202
41. https://qt4cg.org/dashboard/#pr-207
42. https://qt4cg.org/dashboard/#pr-215
43. https://qt4cg.org/dashboard/#pr-222
44. https://qt4cg.org/meeting/minutes/2022/11-01.html
45. https://qt4cg.org/dashboard/#pr-228
46. https://qt4cg.org/dashboard/#pr-230
47. https://github.com/qt4cg/qtspecs/issues/71
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 15 November 2022 18:01:28 UTC