- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 21 Nov 2023 17:25:48 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2wmubhv8y.fsf@saxonica.com>
Hello,
Here are the draft minutes for meeting 055:
https://qt4cg.org/meeting/minutes/2023/11-21.html
QT4 CG Meeting 055 Minutes 2023-11-21
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/4]
* [3]1. Administrivia
+ [4]1.1. Roll call [11/12]
+ [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 [0/3]
+ [10]1.6. Review of open pull requests and issues
o [11]1.6.1. Blocked
o [12]1.6.2. Merge without discussion
o [13]1.6.3. XSLT focused
o [14]1.6.4. Substantive PRs
o [15]1.6.5. Proposed for V4.0
* [16]2. Technical Agenda
+ [17]2.1. PR #837: 297 Deep Lookup Operator "??" and wildcard
qualifier "::"
+ [18]2.2. PR #832: 77 Add map:deep-update and array:deep-update
* [19]3. Any other business?
* [20]4. Adjourned
[21]Agenda index / [22]QT4CG.org / [23]Dashboard / [24]GH Issues /
[25]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [0/4]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [ ] QT4CG-052-05: MK to rename the hexBinary-equal function to
binary-equal?
* [ ] QT4CG-052-06: MK to consider the editorial question of
"promotion" for the symmetric relations.
* [ ] QT4CG-055-01: MK to clarify that the return type of the deep
lookup operator is a flat sequence.
* [ ] QT4CG-055-02: DN to open an issue requesting examples of
implausible expressions to clarify the spec
1. Administrivia
1.1. Roll call [11/12]
JK gives regrets. WP gives possible regrets.
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [ ] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Matt Patterson (MP)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [X] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [26]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2023-11-21.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2023-11-21.png
Figure 2: Open issues by specification
[[./issues-by-type-2023-11-21.png]
1.3. Approve minutes of the previous meeting
Proposal: Accept [27]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [28]is scheduled for Tuesday, 28 November 2023.
Any regrets for the following meeting?
CG gives regrets.
Shall we make 28 November an XSLT-focused meeting?
Yes.
1.5. Review of open action items [0/3]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [ ] QT4CG-052-05: MK to rename the hexBinary-equal function to
binary-equal?
* [ ] QT4CG-052-06: MK to consider the editorial question of
"promotion" for the symmetric relations.
1.6. Review of open pull requests and issues
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]#795: 655: fn:sort-with
* PR [30]#529: 528: revision of json(), and renaming to
elements-to-maps()
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 [31]#846: 845 Drop mention of tuples
* PR [32]#842: Improve stylesheet for generating keyword tests
* PR [33]#841: 840: Typo in fn:seconds-from-duration example
* PR [34]#833: Fix the line endings, force a single lf in text files
Proposal: merge without discussion?
* RD: What about PR [35]#846? (845 Drop mention of tuples) Does
removing the tuple wording cause confusion on the XQuery side?
* MK: I don't think so. They aren't really necessary in the context
of some and every in either spec.
* RD: What about the variable binding change?
* MK: It's just simpler.
With that clarifiction, the list is accepted.
1.6.3. XSLT focused
The following PRs appear to be candidates for a future XSLT-focussed
meeting.
* PR [36]#470: 369: add fixed-prefixes attribute in XSLT
* PR [37]#412: 409, QT4CG-027-01: xsl:next-match
These issues identify the XSLT-focused changes that have been made to
the specifications but which have not been established by the community
group as the status quo.
* Issue [38]#742: xsl:function-library: keep, drop, or refine?
* Issue [39]#169: Handling of duplicate keys in xsl:map
* Issue [40]#168: XSLT Extension Instructions invoking Named
Templates
1.6.4. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [41]#837: 297 Deep Lookup Operator "??" and wildcard qualifier
"::"
* PR [42]#832: 77 Add map:deep-update and array:deep-update
* PR [43]#798: 479: fn:deep-equal: Input order
* PR [44]#737: 295: Boost the capability of recursive record types
1.6.5. Proposed for V4.0
The following issues are labled "proposed for V4.0".
* Issue [45]#716: Generators in XPath
* Issue [46]#689: fn:stack-trace: keep or drop?
* Issue [47]#583: array:replace(), etc
* Issue [48]#557: fn:unparsed-binary: accessing and manipulating
binary types
* Issue [49]#340: fn:format-number: Specifying decimal format
* Issue [50]#260: array:index-of
* Issue [51]#33: json parsing number type option
* Issue [52]#31: Extend FLWOR expressions to maps
2. Technical Agenda
2.1. PR #837: 297 Deep Lookup Operator "??" and wildcard qualifier "::"
See PR [53]#837
* MK: General agreement that it's a good idea. Simply saying * to
select everything often gave too much, so I've proposed a qualifyer
using ::.
+ ... Very often useful with a record test. This makes it very
similar to the way you select elements by name in a tree.
+ ... Seemed equally useful for the "shallow" lookup.
+ ... Deep lookup defines the concept of "recursive content"
+ ... Do shallow lookup on maps and arrays.
+ ... But there are no errors in this case
* DN: I find the idea really good, but I think it's underspecified
here. What exaclty is the type of the result? If the result is a
sequence that's not useful because the will flatten. So this should
be a sequence of singleton arrays, or maybe or an array of arrays.
+ ... This needs to be specified, otherwise we're hanging in the
air.
* MK: Like "/" and "//", it's a flat map operator.
* DN: Then it's not useful.
* MK: There are two reasons for this, one is that it optimizes for
JSON which doesn't have multi-member sequences within things; empty
sequence is certainly a challenge here. The problem is that if you
try to return a structured result, you can't chain the operators
together. That becomes very unwieldy. This worked for the use cases
I tried it on.
* DN: With this issue, I don't think it's workable or useful.
* MK: It could do with presentation of more use cases and examples to
show how it is useful. Yes, those cases where you have arrays whose
members are sequences might need to be addressed differently.
* CG: I think there are a number of use cases with this syntax. But
you shouldn't imagine that you can do everything with this syntax.
You can use existing methods to traverse through complex nested
structures. But for simple lookups, this is really nice. This is
similar to what you can do with XML structures. These examples show
when this syntax is helpful, but clearly you can't do everything
with it.
* JL: I understand what DN is saying. If the return result was a
sequence of arrays, where every found thing, then you could have
sequences. If you then want to flatten it, you need a first stage
flattening of a sequence of arrays. Does * do that?
* MK: I think it's another ?* that does it. But a lot of the reason
for these operators are to avoid them.
* MSM: The :: operator feels like a simple kind of predicate.
* MK: Yes, it's essentially equivalent to [. instanceof ...] but it's
much shorter to write.
* MSM: Part of me wants to use square brackets, but I can see why we
can't.
* MK: It's exactly the same for axis steps; you can't do anything
with :: in an axis step that you couldn't do with a predicate.
* DN: I didn't understand what question MK was asking about ::.
MK points to LookupWildcard in 4.15.3.1.
* DN: We have too many uses of question marks in the language. I'm
worried about how easy it is to mistype this. It's not like "/"
which is used just in path expressions.
+ ... It seems a bit overwhelming to me.
* MK: You will get the same problem that you get with "/" and "//"
where users will use "??" instead of "?" just like they sometimes
use "//" without really understanding what it does.
+ ... There are a lot of symbols that have multiple meanings.
The * has at least three distinct meanings. There's a limited
number of ASCII punctuation symbols so we live with that.
+ ... The clear analogy between single and double / and single
and double ? helps.
* DN: The specification should make it very clear that the return
type is a flat sequence.
ACTION QT4CG-055-01: MK to clarify that the return type of the deep
lookup operator is a flat sequence.
Proposal: Accept this PR.
* DN: I object. I think this needs more work. Returning a flat
sequence destroys all nested structure.
* NW: Consensus seems to be in favor of adding it. DN, are you
willing to accept that consensus if your objection is clearly
noted?
* DN: Okay.
Accepted.
* DN: I'd like to see examples of implausible expressions. (I thought
they were connected to this PR, but maybe they aren't.)
They weren't part of this PR.
ACTION QT4CG-055-02: DN to open an issue requesting examples of
implausible expressions to clarify the spec
2.2. PR #832: 77 Add map:deep-update and array:deep-update
See PR [54]#832
* MK: I think this needs discussion. The aim here is to do something
where the appearance to the typical user is of something reasonably
intuitive and fairly clear, despite the fact that if you think
deeply about it, there is a lot of complexity under the hood.
+ ... We don't have identity for maps and arrays which is
troubling.
+ ... The 3.1 DM spec suggests that we might want to provide IDs
for maps and arrays to support update in the future.
+ ... I have always thought we could avoid that, but you do need
some sort of transient notion of identity during the update to
"retrace your steps".
+ ... The other thing to say is that this is very much based on
the model of "zipper" data structures which is used in
functional programming for a number of algorithms on lists,
graphs, and such-like.
+ ... The idea is that the data structures are immutable so a
modification returns a new data structure. To do that, you
need at least a transient and local notion of identity so that
you can traverse the structure successfully.
+ ... The other point about this relates to CG's comments. I've
defined this as a single higher-order function. My natural
instinct would probably be to define XQuery and XSLT for this,
but we can do that on top of the function. That's a next
stage: adding syntactic sugar on top. It's also possible that
we might need variants for doing "delete" and "insert".
+ ... I think everything can be done with an update, but it
might be easier to be able to specify delete explicitly.
* MK: The other problem in defining it is that we don't have a
collective noun for maps and arrays. It would be convenient if
arrays could be treated as a special kind of map.
+ ... There's a significant challenge in implementing this, but
one thing I've learned in twenty years of doing this exercise
is that it's better to make life difficult for the implementor
than the user.
+ ... Acceptance of this does depend on demonstration of
feasibility.
+ ... We've had an implementation of ideas long these lines in
Saxon for quite a while. They haven't been widely used, and
they aren't as complete as this proposal, but I think it
indicates that it's implementable.
* CG: I think that it's interesting to see that one function is
enough to do everything. I'm thinking of XQuery Update and this is
much simpler. Maps and arrays are much easier because we don't have
namespaces and such. I can still imagine that it could be helpful
to have at least a few update primitives.
+ ... Another issue is that the syntax with function items could
be a primitive that we use to define better syntax. Many
people think in terms of special characters like in XQuery
Update.
CG shares his screen and walks through some of the examples he
describes in [55]issue #832.
* CG: The use of compact syntax for function chaining makes the
examples shorter, but some users that I showed it to didn't
understand it.
+ ... Having delete and replace functions could help.
+ ... We could also use an array to define the steps to
traverse.
+ ... Using an array syntax does limit the kinds of queries that
you can do.
* DN: In 19.2.1, in op:deep-update, I think the change function
should accept item()*, not just item().
* MK: There is definitely an issue here about whether you do updates
at the level of individual items within the value of a sequence or
map or whether you do it on the value as a whole.
+ ... There are use cases for doing both and I've had problems
combining them. This proposal currently just does it at the
item level.
+ ... DN is absolutely right that there are use cases where this
isn't sufficient.
* DN: This is something that we need to work upon. I quite like the
proposal is a common approach. We shouldn't be influenced by the
fact that just the XQuery community is used to doing things a
certain way. We should be trying to unify everything.
+ ... There are probably small changes that we could make to
improve the syntax.
* MK: Another thing that's worth looking at in this area is the
JSONPath specification.
+ ... It provides a selector syntax for looking into maps and
arrays. The result is not just a value but also a path to a
value. That's like the annotations in here.
* RD: I was wondering if it would be worth updating the XQuery Update
spec to provide update syntax sugar on top of this.
+ ... As CG mentioned, people are familiar with XQuery Update
expressions; being able to do that on maps and arrays would be
a nice extension to the current node facilities.
+ ... That might be better than having two different ways.
* MSM: (thumbsup)
* MK: I don't think the semantic style of creating a pending update
list and applying it is appropriate. But syntactically, it would be
good.
* MSM: I just wanted to second what RD said and what I think CG said
earlier. I confess, I don't do use the update facility very often,
but I've learned to use it successfully and I think syntax has a
certain appeal. Parallels would be very helpful. It won't trouble
me if the syntax is the same but the semantics are quite different.
FWTIW.
* DN: I think we do need to have identity of values, even though that
should be invisible to the user. If you update one, you should
duplicate "shared" copies.
* MK: Conceptually, you have to create duplicates.
We're running out of time, but I hope that was useful.
3. Any other business?
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2023/11-21.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/11-21.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/11-21.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/11-21.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/11-21.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/11-21.html#so-far
7. https://qt4cg.org/meeting/minutes/2023/11-21.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2023/11-21.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2023/11-21.html#open-actions
10. https://qt4cg.org/meeting/minutes/2023/11-21.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2023/11-21.html#blocked
12. https://qt4cg.org/meeting/minutes/2023/11-21.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2023/11-21.html#xslt-focused
14. https://qt4cg.org/meeting/minutes/2023/11-21.html#substantive
15. https://qt4cg.org/meeting/minutes/2023/11-21.html#proposed-40
16. https://qt4cg.org/meeting/minutes/2023/11-21.html#technical-agenda
17. https://qt4cg.org/meeting/minutes/2023/11-21.html#pr-837
18. https://qt4cg.org/meeting/minutes/2023/11-21.html#pr-832
19. https://qt4cg.org/meeting/minutes/2023/11-21.html#any-other-business
20. https://qt4cg.org/meeting/minutes/2023/11-21.html#adjourned
21. https://qt4cg.org/meeting/minutes/
22. https://qt4cg.org/
23. https://qt4cg.org/dashboard
24. https://github.com/qt4cg/qtspecs/issues
25. https://github.com/qt4cg/qtspecs/pulls
26. https://qt4cg.org/meeting/agenda/2023/11-21.html
27. https://qt4cg.org/meeting/minutes/2023/11-14.html
28. https://qt4cg.org/meeting/agenda/2023/11-28.html
29. https://qt4cg.org/dashboard/#pr-795
30. https://qt4cg.org/dashboard/#pr-529
31. https://qt4cg.org/dashboard/#pr-846
32. https://qt4cg.org/dashboard/#pr-842
33. https://qt4cg.org/dashboard/#pr-841
34. https://qt4cg.org/dashboard/#pr-833
35. https://qt4cg.org/dashboard/#pr-846
36. https://qt4cg.org/dashboard/#pr-470
37. https://qt4cg.org/dashboard/#pr-412
38. https://github.com/qt4cg/qtspecs/issues/742
39. https://github.com/qt4cg/qtspecs/issues/169
40. https://github.com/qt4cg/qtspecs/issues/168
41. https://qt4cg.org/dashboard/#pr-837
42. https://qt4cg.org/dashboard/#pr-832
43. https://qt4cg.org/dashboard/#pr-798
44. https://qt4cg.org/dashboard/#pr-737
45. https://github.com/qt4cg/qtspecs/issues/716
46. https://github.com/qt4cg/qtspecs/issues/689
47. https://github.com/qt4cg/qtspecs/issues/583
48. https://github.com/qt4cg/qtspecs/issues/557
49. https://github.com/qt4cg/qtspecs/issues/340
50. https://github.com/qt4cg/qtspecs/issues/260
51. https://github.com/qt4cg/qtspecs/issues/33
52. https://github.com/qt4cg/qtspecs/issues/31
53. https://qt4cg.org/dashboard/#pr-837
54. https://qt4cg.org/dashboard/#pr-832
55. https://github.com/qt4cg/qtspecs/pull/832
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 21 November 2023 17:27:52 UTC