- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Tue, 21 Nov 2023 20:00:30 -0800
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org, Dimitre Novatchev <dnovatchev@gmail.com>
- Message-ID: <CAK4KnZegETWPvVFZHuhppkGNofOS2zL5mzdWqAe3VFVn+rY=qw@mail.gmail.com>
> * 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.
Not exactly. See
https://github.com/qt4cg/qtspecs/issues/825#issue-1984686108 for one way
to produce all members, each in a separate array.
Here is a short and complete example:
let $members-at := function(
$input as array( *),
$indexes as xs:integer*
) as array(*)*
{
for $ind in $indexes
return [$input($ind)]
}
return
$members-at([1, (2, 3), (4, 5, 6)], (1 to 3) )
Which produces the wanted result:
[1], [(2,3)], [(4,5,6)]
[image: image.png]
On Tue, Nov 21, 2023 at 9:28 AM Norm Tovey-Walsh <norm@saxonica.com> wrote:
> 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
>
Attachments
- image/png attachment: image.png
Received on Wednesday, 22 November 2023 04:00:49 UTC