- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 09 Apr 2024 17:54:47 +0100
- To: "public-xslt-40@w3.org" <public-xslt-40@w3.org>
- Message-ID: <m2edbezdaa.fsf@saxonica.com>
Hi folks,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2024/04-09.html
QT4 CG Meeting 072 Minutes 2024-04-09
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/10]
* [3]1. Administrivia
+ [4]1.1. Roll call [9/15]
+ [5]1.2. Accept the agenda
o [6]1.2.1. Status so far...
+ [7]1.3. Approve minutes of the previous meeting
+ [8]1.4. Next meeting
+ [9]1.5. Review of open action items [5/10]
+ [10]1.6. Review of open pull requests and issues
o [11]1.6.1. Merge without discussion
o [12]1.6.2. Close without action
* [13]2. Technical Agenda
+ [14]2.1. PR #1132: 122 Choice item types (generalizing local
union types)
+ [15]2.2. PR #1131: 796,231 - Extend XPath for and let
expressions
+ [16]2.3. PR #1120: 99v2 deep equal with callback
+ [17]2.4. PR #1108: 566-partial Describe a less aggressive
%-encoding for fn:build-uri
+ [18]2.5. PR #1098: 566-partial Editorial improvements for
parse-uri
+ [19]2.6. PR #1093: 1091 Add fn:collation function
* [20]3. Any other business
* [21]4. Adjourned
[22]Meeting index / [23]QT4CG.org / [24]Dashboard / [25]GH Issues /
[26]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [0/10]
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [ ] QT4CG-064-08: NW to open an issue to try to resolve $search to
$target consistently.
* [-] QT4CG-069-02: NW to coordinate with MK to use the introspection
features on the test suite.
+ In progress...
* [ ] QT4CG-070-01: NW to review how records are formatted.
* [ ] QT4CG-071-06: NW to clarify the cases that are distinguished by
the leading empty string in path segments
* [ ] QT4CG-072-01: MK to consider whether and when a choice type
should be classified as a schema type
* [ ] QT4CG-072-02: MK to clarify that the position variable is a
single, positive integer.
* [ ] QT4CG-072-03: NW to clarify the round-tripping of URIs
* [ ] QT4CG-072-04: DN to raise an issue about having a function to
test if a collation URI is supported
1. Administrivia
1.1. Roll call [9/15]
Regrets: WP, JK.
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [ ] Mukul Gandhi (MG)
* [X] Christian Gr¸n (CG)
* [ ] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JLY)
* [X] Dimitre Novatchev (DN)
* [ ] Wendell Piez (WP)
* [ ] Ed Porter (EP)
* [ ] Liam Quin (LQ)
* [ ] Adam Retter (AR)
* [X] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [27]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2024-04-09.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-04-09.png
Figure 2: Open issues by specification
issues-by-type-2024-04-09.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [28]the minutes of the previous meeting.
* JLO: The minutes mixed up JLO and JLY in one place.
* NW: Okay, send it in chat and I'll fix it.
Accepted with that revision.
1.4. Next meeting
The next meeting [29]is scheduled for Tuesday, 16 April 2024.
JLY gives regrets for 16 and 23 April.
1.5. Review of open action items [5/10]
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [ ] QT4CG-064-08: NW to open an issue to try to resolve $search to
$target consistently.
* [-] QT4CG-069-02: NW to coordinate with MK to use the introspection
features on the test suite.
+ In progress...
* [ ] QT4CG-070-01: NW to review how records are formatted.
* [X] QT4CG-071-01: MK to put namespace bindings for XQuery back on
the issue list
+ Issue [30]#1119
* [X] QT4CG-071-02: MK to raise a PR that changes map construction
examples as appropriate
* [X] QT4CG-071-03: MK to review the definition of map equality in
fn:equal
+ See PR [31]#1120
* [X] QT4CG-071-04: MK to update the prose to highlight differences
between fn:equal and fn:deep-equal
+ No longer relevant
* [X] QT4CG-071-05: MK to consider the name of the function argument.
+ No longer relevant
* [ ] QT4CG-071-06: NW to clarify the cases that are distinguished by
the leading empty string in path segments
1.6. Review of open pull requests and issues
1.6.1. 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]#1134: 1133 Correct map:filter callback signature
* PR [33]#1128: 1020 Further notes on the consequences of function
coercion
* PR [34]#1123: 1118 Drop the "map" keyword in adaptive serialization
output
* PR [35]#1112: 1110-partial New error codes
Proposal: merge without discussion.
Accepted.
1.6.2. 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 [36]#1105: Casting to numerical type from strings with
underscores
* Issue [37]#983: fn:reduce (or fn:fold without initial value)
* Issue [38]#834: Add creation function for `csv-row-record` type
* Issue [39]#713: Annotations: Editorial notes
* Issue [40]#666: Polyfill function implementations
* Issue [41]#613: Allow "union" as synonym for "|" everywhere
* Issue [42]#132: Clarify if redirects should be followed
* Issue [43]#67: Allow optional parameters and keyword arguments on
map and sequence variadic functions.
Proposal: close without further action.
Accepted.
2. Technical Agenda
2.1. PR #1132: 122 Choice item types (generalizing local union types)
See PR [44]#1132
MK describes the PR.
* MK: This PR replaces local union types and generalizes them.
+ ... Union of sequence types didn't satisfy the requirements
and got complicated
+ ... Stuck with a union of item types.
+ ... Kept the terminology "local union type" to reduce churn in
the spec
+ ... No substantial changes to enumeration types.
+ ... Subtyping turned out to be relatively easy.
* JLY: Two things: what is the semantics of casting when the union
type could be ambiguous?
* MK: You take the first one that works. It is ordered, as with union
types.
* JLY: So A union B isn't necessarily the same as B union A (wrt
casting)
* MK: That's right.
* JLY: Can you use union everywhere you can use |?
* MK: No, there are places where | and union are different
* MSM: At the very end of the first section, there was a paragraph
that said "this is a schema type even though it's not defined in
any schema?" Is it always true that it isn't in a schema, or is it
meant to say "even if it's created in some other way, it still
counts as a schema type?"
* MK: That's a good question. It relates to what we day about schema
types. It was primarily an attempt to avoid rewriting that section.
+ ... The current definition of "schema type" is a little bit
fuzzy.
* CG: Why were union types renamed to choice item types?
* MK: To avoid confusion with union types in XSD.
* JLO: I'm wondering about the decision not to use sequence types.
Can I still use them in a return type or parameter type?
* MK: Yes, but you're only allowed one occurrenc indicator. You can't
say it's a map or a sequence of strings. You have to say it's a
sequence of things that are maps or strings.
* DN: I like having this. I recently had to specify unions between
maps and arrays and this is an improvement over local union types.
We have too many union types now: pure union types, union types,
choice items types. It becomes confusing.
+ ... Can we say union types and not choice item types
* MK: Well, as I explained, I wanted to give it a different name so
it was distinct from XSD.
* DN: Perhaps "XSD union types" and "XPath union types"
* MK: I'd be worried about making sure all the existing uses of
"union types" got clarified.
* DN: Okay, then I just want to be on record as saying I think we
have too many union types.
* RD: I like the proposal. It would be nice to see if we could get
sequence type unions working. The example of "a list of strings or
a map" is used in some MarkLogic APIs. There might be some other
places too.
* MK: The area where I found it most difficult to deal with sequence
types was in coercion rules. General unions start by getting a
handle on the required item type, and that assumes you can base the
rules on what the target item type is.
Some discussion. Would require more thought. This is the "easy 80% of
the problem".
* JLO: Following up, what happens if I have a union type of
xs:integer and xs:string and I want to have a sequence of those.
This allows a mixed sequence of integers and strings.
* MK: Yes.
* RD: Yes, but you can't say "a list of strings or a list of only
strings"
* MK: Right. You can only have a list of things each of which is
either a string or an integer.
* DN: I was wondering how this would effect our rules for overloading
of functions. If one specifies a argument type as the union of
several types, that will make it more difficult to make the
overload more specific.
* RD: Overloading only functions on the arity of the function.
* MK: What you can do now is have one function with alternative item
types. You can't have two different functions in that case, but you
can have one function that accepts either.
* DN: That makes the logic in the function a little bit complex.
Some discussion of how you can currently use typeswitch in a function.
* MK: The current fn:serialize function accepts either an item or a
map, and now you can get a more precises signature for that.
* DN: We should comment that this facility can lead to cases where
things become more complex.
* JLY: Is there a proposal to put typeswitch into XPath?
* MK: Not at the moment.
* JLY: Why not?
* MK: The whole question of what should be in XPath ends up being a
matter of opinion: keep it as small as possible, or make it as
powerful as possible. Pick one.
* DN: I want to put as many things as possible in XPath. But I'm
against putting typeswitch in XPath because it would encourage
messy programming.
* RD: I just wanted to say that as opposed to what DN said, this lets
you be more restrictive about types.
ACTION QT4CG-072-01: MK to consider whether and when a choice type
should be classified as a schema type
Proposal: Accept this PR.
Accepted.
2.2. PR #1131: 796,231 - Extend XPath for and let expressions
See PR [45]#1131
* MK: This absorbs several separate issues. It allows XPath to have a
larger subset of FLOWR expressions.
+ ... The semantics are the same as XQuery, it just extends the
XPath subset a bit.
MK reviews the grammar changes.
* MK: The names have to be unique across XPath and XQuery, so we get
XPForClause
+ ... The grammar is defined in a slightly different way than
XQuery, but its still a subset.
+ ... There's not much change to the way its described.
+ ... Let expressions reuse the same constructs
* DN: The at argument allows variables; can it be a single integer or
a sequence...
* MK: It's a single integer.
* DN: Can we just say that the position variable should contain a
single, positive integer.
* RD: I found the recursive definition of the for and let expressions
to be a little confusing.
+ ... I initially wondered if this would allow a duplicated for
clause.
+ ... I wonder if the grammar could be similar to the XQuery
grammar where a ForLet expression is at the top.
* MK: Yes. This ties in closely to the way the semantics are
described in XPath. Doing the grammar differently would make it
harder to express the semantics in those terms.
+ ... In effect, this is just saying that you can leave out the
return keyword in some cases.
+ ... The recursive description would up being simplest.
ACTION QT4CG-072-02: MK to clarify that the position variable is a
single, positive integer.
Proposal: accept this PR.
Accepted.
2.3. PR #1120: 99v2 deep equal with callback
See PR [46]#1120
* MK: At the last meeting, we looked at a proposal I made for a
function named fn:equal. There was pushback on that proposal about
the limitations and there were questions about how it's different
from fn:deep-equal.
+ ... I decided that we could satisfy the requirement by adding
a callback to fn:deep-equal.
+ ... The fn:deep-equal function is extended with a items-equal
function.
+ ... The function can say two items are equal, or not equal, or
"ignore this call back and figure out per usual".
+ ... This means you can overload the logic only for nodes or
only for timestamps, etc.
* MK: It's not a big change, but it does satisfy all of the use
cases.
* JLY: This use of a triple-valued return, are there other places
where this might be helpful?
+ ... Strikes me as a technique we could use a little more
generally.
* MK: Potentially, though I can't think of any.
* DN: This could be generalized to provide a "deep compare" function.
+ ... We are in need of comparison function for two arrays.
+ ... Maybe we need to think how to unify these concepts.
* MK: I did go down that avenue, but fell back to "doing one thing at
a time." There's a gap in that area waiting to be filled.
Proposal: accept this PR.
Accepted.
2.4. PR #1108: 566-partial Describe a less aggressive %-encoding for
fn:build-uri
See PR [47]#1108
NW outlines the proposal and observes that this will require changes to
the test suite, but proposes to do them separately.
* CG: What about query parmaters, should they also use these new
rules?
* NW: ... uh ...
+ ... Dang it. I'm not going to try to decide that on the fly.
Apologies for having over looked them.
Some discussion about how round-tripping comes into play and what
effect it has. MSM proposes that it might be clearer if the spec
described how fully unescaped, fully escaped, and partially escaped
URIs are effected.
ACTION QT4CG-072-03: NW to clarify the round-tripping of URIs
2.5. PR #1098: 566-partial Editorial improvements for parse-uri
See PR [48]#1098
Not ready for review.
2.6. PR #1093: 1091 Add fn:collation function
See PR [49]#1093
MK reviews the proposal.
* MK: This is a convenience function that means you don't have to
remember the URIs for UCA collations.
+ ... it takes a map and does two things: constructs a string
consisting and then either returns it or reports an error if
the resulting collation isn't supported by the implementation.
+ ... There's a little subtlty in the option parameter
conventions; there's a slight difference with respect to
properties not defined in the spec. Implementation defined
options are aligned with UCA collations.
* DN: I think I like this. Everything seems logical, but what about
the fact that we don't have try/catch facilities in XPath. It would
be good to have a function to ask the question "is a collation
supported"?
* MK: If you say fallback=true, the function will never fail
* DN: How would I know that I can use the collation?
* MK: You don't. It's not exactly what you're looking for.
Some discussion of supporting try/catch in XPath
* JLY: Even better would be able to pass the map in where a collation
URI is used.
* CG: What about avoiding the camel case and converting them to UCA.
* MK: I wouldn't be opposed to that.
* RD: I concur.
ACTION QT4CG-072-04: DN to raise an issue about having a function to
test if a collation URI is supported
Proposal: accept this PR.
Accepted.
3. Any other business
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/04-09.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/04-09.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/04-09.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/04-09.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/04-09.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/04-09.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/04-09.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/04-09.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/04-09.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/04-09.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/04-09.html#merge-without-discussion
12. https://qt4cg.org/meeting/minutes/2024/04-09.html#close-without-action
13. https://qt4cg.org/meeting/minutes/2024/04-09.html#technical-agenda
14. https://qt4cg.org/meeting/minutes/2024/04-09.html#pr-1132
15. https://qt4cg.org/meeting/minutes/2024/04-09.html#pr-1131
16. https://qt4cg.org/meeting/minutes/2024/04-09.html#pr-1120
17. https://qt4cg.org/meeting/minutes/2024/04-09.html#pr-1108
18. https://qt4cg.org/meeting/minutes/2024/04-09.html#pr-1098
19. https://qt4cg.org/meeting/minutes/2024/04-09.html#pr-1093
20. https://qt4cg.org/meeting/minutes/2024/04-09.html#any-other-business
21. https://qt4cg.org/meeting/minutes/2024/04-09.html#adjourned
22. https://qt4cg.org/meeting/minutes/
23. https://qt4cg.org/
24. https://qt4cg.org/dashboard
25. https://github.com/qt4cg/qtspecs/issues
26. https://github.com/qt4cg/qtspecs/pulls
27. https://qt4cg.org/meeting/agenda/2024/04-09.html
28. https://qt4cg.org/meeting/minutes/2024/03-26.html
29. https://qt4cg.org/meeting/agenda/2024/04-16.html
30. https://github.com/qt4cg/qtspecs/issues/1119
31. https://qt4cg.org/dashboard/#pr-1120
32. https://qt4cg.org/dashboard/#pr-1134
33. https://qt4cg.org/dashboard/#pr-1128
34. https://qt4cg.org/dashboard/#pr-1123
35. https://qt4cg.org/dashboard/#pr-1112
36. https://github.com/qt4cg/qtspecs/issues/1105
37. https://github.com/qt4cg/qtspecs/issues/983
38. https://github.com/qt4cg/qtspecs/issues/834
39. https://github.com/qt4cg/qtspecs/issues/713
40. https://github.com/qt4cg/qtspecs/issues/666
41. https://github.com/qt4cg/qtspecs/issues/613
42. https://github.com/qt4cg/qtspecs/issues/132
43. https://github.com/qt4cg/qtspecs/issues/67
44. https://qt4cg.org/dashboard/#pr-1132
45. https://qt4cg.org/dashboard/#pr-1131
46. https://qt4cg.org/dashboard/#pr-1120
47. https://qt4cg.org/dashboard/#pr-1108
48. https://qt4cg.org/dashboard/#pr-1098
49. https://qt4cg.org/dashboard/#pr-1093
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 9 April 2024 16:55:34 UTC