- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 01 Nov 2022 17:30:00 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2fsf2lgza.fsf@saxonica.com>
Posted here:
https://qt4cg.org/meeting/minutes/2022/11-01.html
QT4 CG Meeting 009 Minutes 2022-11-01
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/9]
* [3]1. Administrivia
+ [4]1.1. Roll call [9/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 [4/6]
* [9]2. Technical Agenda
+ [10]2.1. Review pull request #197 (was 166; variadic
functions)
+ [11]2.2. Review pull request #202 (was 196; subtyping)
+ [12]2.3. Review pull request #210: Issue 80: fn:while
+ [13]2.4. Review pull request #215: parse-uri and build-uri
functions
+ [14]2.5. Review pull request #222: Sequence comparision
* [15]3. Any other business
Draft Minutes
Summary of new and continuing actions [0/9]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-007-05: NW to make an issue for Martin's proposed
ammendment to map:build
* [ ] QT4CG-009-01: NW to coordinate with MK on an agenda for next
week.
* [ ] QT4CG-009-02: NW to work with MK to make sure PR #197 is
updated correctly
* [ ] QT4CG-009-03: NW to investigate the relationship between PR
#215 and resolve-uri.
* [ ] QT4CG-009-04: NW to review RFC 3896 wrt relative URIs
* [ ] QT4CG-009-05: NW to fix the return type for parse-uri; consider
using a record type.
* [ ] QT4CG-009-06: NW to add error tests for parse-uri.
* [ ] QT4CG-009-06: NW to make the query segments an array of maps.
1. Administrivia
1.1. Roll call [9/13]
Regrets: BTW
* [ ] Anthony (Tony) Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [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)
* [X] Norm Tovey-Walsh (NW). Chair. Scribe.
1.2. Accept the agenda
Proposal: Accept [16]the agenda.
Accepted.
1.3. Next meeting
The next meeting [17]is scheduled for Tuesday, 8 November. This
conflicts with Declarative Amsterdam.
Shall we meet?
After some discussion, yes, next week will be chaired by MSM and will
focus on XSLT issues.
ACTION: QT4CG-009-01: NW to coordinate with MK on an agenda for next
week.
Regrets for 8 November: NW, JL, CG.
1.4. Approve minutes of the previous meeting
Proposal: Accept [18]the minutes of the previous meeting.
Accepted.
1.5. Review of open action items [4/6]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [X] QT4CG-005-03: RD to review the variadic functions proposal in
#197 (formerly #166)
* [ ] QT4CG-007-05: NW to make an issue for Martin's proposed
ammendment to map:build
* [X] QT4CG-008-01: MK to review RD's comments on PR #202
* [X] QT4CG-008-02: NW to review MKs comments on PR #215
+ Updates to PR [19]#215
* [X] QT4CG-008-03: MK to make a PR for issue #96,
starts|ends-with-sequence
+ PR [20]#222
2. Technical Agenda
2.1. Review pull request #197 (was 166; variadic functions)
See [21]pull request #197 (you'll find links to formatted versions of
the specs at [22]https://qt4cg.org/).
See also the nexus of issues [23]#162, [24]#161, [25]#160, [26]#159,
[27]#158, [28]#157, and [29]#155.
See the discussion from [30]three weeks ago, [31]two weeks ago, and
[32]last week.
We hope to resolve this PR this week.
* MK: I believe I responded to all the comments. None were
particularly problematic. Just minor mistakes. One technical issue
that is now an error condition.
* RD: I made a few comments about an hour ago.
+ RD walks us through [33]his comments on the pull request
It appears that MK's most recent commits haven't been reflected in the
diffs.
ACTION: QT4CG-009-02: NW to work with MK to make sure PR #197 is
updated correctly
We'll revisit this in two weeks.
2.2. Review pull request #202 (was 196; subtyping)
See [34]pull request #202
* MK: No progress, I haven't responded to the latest comments.
2.3. Review pull request #210: Issue 80: fn:while
See [35]pull request #210
* CG: The latest issue was how to name the function. If the function
is named fn:while then we can't introduce a while keyword later
because it will create a conflict. MK proposed fn:iterate. We could
also use fn:until with the semantics reversed.
* NW: I like the similarity of fn:iterate with XSLT.
* MSM: Is that a conflict with XSLT?
* NW: No, because it's an instruction in XSLT, not a function.
* MK: The semantics have enough of an analogy that it seems
reasonable.
* JK: Is there a way to setup the keyword while so that there's some
sytax after it that prevents any confusion?
Some discussion of whether or not we could distingish the keyword from
the function.
* MSM: Depending on exactly what people have in mind for a while
keyword, my gut feeling is that I expect a while to be followed by
a boolean expression. So we can't solve the lookahead problem that
way.
* RD: The only problem using while which would confuse it with a
keyword would be in the case where while would have a parenthesis
following it because that applies to keywords like typeswitch, if,
and others. Given that the while expression is following the FLOWR
syntax, I don't see it raising a clash in the grammar.
* MK: There would be a conflict if you allowed it as the first thing
in an expression and allowed it to be followed by an expresison.
* CG: Do we think in the future we may get rid of the for and let as
the beginning of the FLOWR clause?
* MK: I think this is a question of trying to avoid restricting our
options downstream.
* MSM: CG, was your alternative name until or repeat?
* CG: It was until but it could be repeat.
* MK: I quite like repeat.
* MSM: For those of us with Pascal backgrounds, repeat differs from
while in that the loop is bound to occur once.
* CG: If you inverted the condition, it would always execute at least
once. I like while because it's more popular and you don't have to
have a negated condition.
* DN: Comparing while and until, I don't think they're the same at
all.
* MSM: I think I could live with any (almost any?) of the proposed
names, but in the end if we don't want to use while, I think I lean
towards iterate for the parallel to xsl:iterate
* DN: There is also a proposal for a while keyword. What's the
difference?
* CG: I think the main difference is that if you have a FLOWR
epxression you're operating on a sequence . With the while function
you can have arbitrary inputs that are transformed by the body.
* MK: In that respect, it is quite different from xsl:iterate as that
does operate over a sequence.
* NW: Mmm, true.
* MSM: That pushes me back to repeat or until if we can't use while.
That difference that CG has just identifeid is significant.
Leave it for a week?
* MK: One approach is to adopt a name that we don't like and then
after you've used it for a while, and you can revisit the name
later.
* RD: Would it make sense to keep while for now in that case?
* DN: Can someone write some comments on the issue? I feel very
confused right now.
Let's come back to this in two weeks.
Let's all try to follow up in the issue so that in two weeks we're
ready to pick a name, or pick a name we don't exactly like to live with
for a while. In either case, pick a name!
2.4. Review pull request #215: parse-uri and build-uri functions
See [36]pull request #215
NW walks through the current prose for parse-uri.
* JL: Does reconstructing give back the original or an equivalent?
* NW: That's a little hard to answer before I redraft the build
function.
* MK: How well does this play with resolve-uri?
Some discussion. MK observes that if resolve-uri has stricter
semantics, you could end up deciding you had a relative path but then
it would be rejected by resolve-uri. That's a mess.
ACTION: QT4CG-009-03: NW to investigate the relationship between PR
#215 and resolve-uri.
* MSM: Two questions and a comment. you said in introducing the
function you had started by thinking we could parse against RFC
3986 and shifted to something else to deal with relative URIs. But
RFC 3986 has two roots, wouldn't that be sufficient.
ACTION: QT4CG-009-04: NW to review RFC 3896 wrt relative URIs
MSM highlights the rule about matching a drive letter that NW had
missed in his description.
* MSM: This rule and the backslash rule will be lossy. So to JL's
question, you'll get a functionally equivalent URI.
* RD: Three points. First, the return type is map where the value is
string, but some of the components return an array of strings.
Second, wouldn't this be better specified as a record type? Third,
Do we want to reference what the WHAT WG URL document?
ACTION: QT4CG-009-05: NW to fix the return type for parse-uri; consider
using a record type.
* DN: This question is more of a wish: I'd prefer if the test cases
included tests for the error conditions.
* NW: Yes, of course, that's an oversight.
ACTION: QT4CG-009-06: NW to add error tests for parse-uri.
* CG: Instead of returning an array of strings, what about returning
a map of the query segments?
* NW: That's tricky because the keys aren't necessarily unique, it
would have to be an array of maps.
* MK: We're considering improvements to the lookup operator that
would work on an array of maps.
* NW: Right then, that's enough to make me think that's better.
ACTION: QT4CG-009-06: NW to make the query segments an array of maps.
2.5. Review pull request #222: Sequence comparision
See [37]pull request #222 and issues [38]#94 and [39]#96.
* MK: I've propopsed three new functions. The main thing I discovered
is that these are far more poweful than I realized in that the
matching doesn't have to be an equality match. You can look for a
sequence of paragraphs by matching on the name of the child
element, for example.
Proposal: Accept this PR.
Accepted.
3. Any other business
None heard.
References
1. https://qt4cg.org/meeting/minutes/2022/11-01.html#minutes
2. https://qt4cg.org/meeting/minutes/2022/11-01.html#new-actions
3. https://qt4cg.org/meeting/minutes/2022/11-01.html#administrivia
4. https://qt4cg.org/meeting/minutes/2022/11-01.html#roll-call
5. https://qt4cg.org/meeting/minutes/2022/11-01.html#agenda
6. https://qt4cg.org/meeting/minutes/2022/11-01.html#next-meeting
7. https://qt4cg.org/meeting/minutes/2022/11-01.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2022/11-01.html#review-of-actions
9. https://qt4cg.org/meeting/minutes/2022/11-01.html#technical-agenda
10. https://qt4cg.org/meeting/minutes/2022/11-01.html#pr-variadic-functions
11. https://qt4cg.org/meeting/minutes/2022/11-01.html#pr-subtyping
12. https://qt4cg.org/meeting/minutes/2022/11-01.html#pr-fn-while
13. https://qt4cg.org/meeting/minutes/2022/11-01.html#pr-parse-uri
14. https://qt4cg.org/meeting/minutes/2022/11-01.html#pr-sequence-comparison
15. https://qt4cg.org/meeting/minutes/2022/11-01.html#any-other-business
16. https://qt4cg.org/meeting/agenda/2022/11-01.html
17. https://qt4cg.org/meeting/agenda/2022/11-08.html
18. https://qt4cg.org/meeting/minutes/2022/10-25.html
19. https://qt4cg.org/dashboard/#pr-215
20. https://qt4cg.org/dashboard/#pr-222
21. https://qt4cg.org/dashboard/#pr-197
22. https://qt4cg.org/
23. https://github.com/qt4cg/qtspecs/issues/162
24. https://github.com/qt4cg/qtspecs/issues/161
25. https://github.com/qt4cg/qtspecs/issues/160
26. https://github.com/qt4cg/qtspecs/issues/159
27. https://github.com/qt4cg/qtspecs/issues/158
28. https://github.com/qt4cg/qtspecs/issues/157
29. https://github.com/qt4cg/qtspecs/issues/155
30. https://qt4cg.org/meeting/minutes/2022/10-11.html#pr-variadic-functions
31. https://qt4cg.org/meeting/minutes/2022/10-18.html#pr-variadic-functions
32. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-variadic-functions
33. https://github.com/qt4cg/qtspecs/pull/197#pullrequestreview-1163389605
34. https://qt4cg.org/dashboard/#pr-202
35. https://qt4cg.org/dashboard/#pr-210
36. https://qt4cg.org/dashboard/#pr-215
37. https://qt4cg.org/dashboard/#pr-222
38. https://github.com/qt4cg/qtspecs/issues/94
39. https://github.com/qt4cg/qtspecs/issues/96
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 1 November 2022 17:31:10 UTC