AW: XQuery 4, Current Draft: Feedback

Hi there,

I would be interested if any of you think it’s worth revisiting the feedback that I shared with you at our next meeting (or the week after), or if you believe we have enough other things to do.

Thanks in advance, feel free to be candid,
Christian
________________________________________

Von: Christian Grün <cg@basex.org>
Gesendet: Freitag, 23. Juni 2023 08:56
An: public-xslt-40@w3.org
Betreff: XQuery 4, Current Draft: Feedback

Dear all,

I regularly communicate new language features to (mostly German) customers that I count to the advanced/expert user group. Originally, I didn’t plan to pass on the feedback that I have been gathering since the beginning of this year. It feels interesting and relevant enough to me, though, so I have prepared a summary of the answers and quotes. I have tried suppress noise.

Disclaimer:

• The answers don’t reflect my/our (BaseX’s) opinion.
• I need to assume that I have presented some features more favorably than others, but I have tried to stay neutral as best as I could.
• I have included feedback that I would like to have omitted (both positive and negative).
• I haven’t managed to ask for feedback on all new (current and proposed) features.
• Please be aware that some Germans like to be honest and direct (but I think you are).

Here we go!

1. Common feedback is that everyone is excited about the upcoming new version: “Please, soon!”, “Better more small versions rather that one that arrives in 2030”, …
2. An obvious tendency is that people are confused to see new features for things that are “already working”, and that may cause new uncertainty about which approach is the best to pursue. “If existing features are broken, don’t introduce surrogates that are similarly broken.”
3. A particular example is the concept of “Key-Value Pair Maps” that was conceived as bulky, compared to conventional maps. Similarly, it was not understood why a member of an array can be returned as a map: “We have map:merge and array:join (bad names, but work)”, “Do we really need 4 new functions map:build, map:of, array:build, array:of that do would you can already do?”
4. In contrast, the feedback for `for member $m` was very positive (everyone loves FLWORs).
5. For maps, the answer was (twice!): „Just add `for key $k value $v`”.
6. People are waiting for `for … while …`: “Recursive solutions are difficult to understand and maintain”.
7. Variadic functions received mixed feedback: “Drop variadic concat”, “Would only work for last argument”, “We have become used to parentheses”, “Why not extend fn:concat to allow single parenthesized argument, and avoid introducing other functions of that type?”
8. There is general vagueness about the number of new built-in functions that have been added so far: “I cannot see the direction you are going. Who decides what’s important and what is not?”, “Wouldn’t the external FunctX/EXPath approach be a better solution?”
9. The idea of a mapping arrow operator was considered positive, but the chosen symbol "=!>" was repeatedly discussed. Other suggestions: !>, ->, !=>, ==>. “Not more than 2 characters, please”
10. People definitely don’t like characters in the standard syntax that cannot be accessed with standard keyboards (I presented ×, ÷, ＜, and ＞): “You’re getting esoteric.”, “I thought this was going to be a language accessible to everyone.”
11. Shortcuts for the `function` are welcome, but the feedback was too mixed to be concisely summarized: “Please provide ->, as everyone else does”, “Can `function` simply be dropped?”, …

…and the kudos:

12. Feedback on keyword and optional parameters is generally positive (“Intuitive”, “Helpful when code is refactored”).
13. “otherwise”, if then without else: “Finally!” (…but BaseX already provided solutions for that, so our users were infected)
14. Focus functions: “Nice; there are so functions with just a single data argument.”
15. Union node tests, `child::(a|b)`: “Cool!”
16. String templates: “Much easier to grasp than ``[ ... ]``”
17. Someone loved fn:trunk & fn:foot: “Funny, thus easy to remember. Serious computer science and history has always been about fun…”

Summary:

I didn’t create a public issue for it to avoid too much discussion. We definitely have more than enough to do, but I’d really like us to spend at least 15 (or 30, not more) minutes on the feedback at one of the next meetings before the summer break to decide which items are relevant to us and which ones we want to ignore. What do you think?

Thanks,
Christian

Received on Wednesday, 5 July 2023 12:25:16 UTC