QT4CG meeting 068 draft minutes, 5 March 2024

Hello,

Here are the draft minutes from today’s meeting:

   https://qt4cg.org/meeting/minutes/2024/03-05.html

QT4 CG Meeting 068 Minutes 2024-03-05

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [0/4]
     * [3]1. Administrivia
          + [4]1.1. Roll call [11/13]
          + [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 [8/12]
          + [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. Close without action
     * [14]2. Technical Agenda
          + [15]2.1. Review of blocked PRs
          + [16]2.2. PR #1053: 1047 Default predicate for some#1 and
            every#1
          + [17]2.3. PR #1049: 340-partial fn:format-number: Specifying
            decimal format
          + [18]2.4. PR #1027: 150 fn:ranks
          + [19]2.5. PR #832: 77 Add map:deep-update and array:deep-update
     * [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/4]

     * [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
       meeting"
     * [ ] QT4CG-063-04: NW to try to add test review to the editorial
       meeting.
     * [ ] 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.

1. Administrivia

1.1. Roll call [11/13]

   Regrets DN.
     * [X] Reece Dunn (RD)
     * [X] Sasha Firsov (SF) [-:30]
     * [X] Christian Gr¸n (CG)
     * [X] Joel Kalvesmaki (JK)
     * [X] Michael Kay (MK)
     * [X] Juri Leino (JLO)
     * [X] John Lumley (JLY)
     * [ ] Dimitre Novatchev (DN)
     * [X] Wendell Piez (WP)
     * [X] Ed Porter (EP)
     * [ ] Adam Retter (AR) [:10-]
     * [X] C. M. Sperberg-McQueen (MSM) [:10-]
     * [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-03-05.png

   Figure 1: "Burn down" chart on open issues

   issues-by-spec-2024-03-05.png

   Figure 2: Open issues by specification

   issues-by-type-2024-03-05.png

   Figure 3: Open issues by type

1.3. Approve minutes of the previous meeting

   Proposal: Accept [28]the minutes of the previous meeting.

   Accepted.

1.4. Next meeting

   The next meeting [29]is scheduled for Tuesday, 12 March 2024.

   Any regrets for the next meeting?

   Beware that the US switches to daylight saving time before the next
   meeting.

1.5. Review of open action items [8/12]

     * [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
       meeting"
     * [X] QT4CG-056-04: MK to write a proposal for adding a select
       attribute to xsl:text
          + This action can be tracked with issue #323
     * [X] QT4CG-058-02: MK to consider providing more advice about the
       pitfalls of mixing decimal and double when sorting
          + Discharged by raising issue #986
     * [X] QT4CG-063-01: MK to revise #956 especially with respect to the
       options parameter
          + PR is still marked "revise", this action is no longer
            necessary
     * [X] QT4CG-063-02: JK to consider whether the roman numeral example
       is appropriate for the spec.
          + On consideration, no it probably wouldn't be helpful
     * [ ] QT4CG-063-04: NW to try to add test review to the editorial
       meeting.
     * [X] QT4CG-063-05: MK to revise PR #953 to take account of CG's
       comments
          + Work ongoing, but this action has been overtaken by events
     * [ ] 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.
     * [X] QT4CG-066-01: MK to add a note that the grammar rules for
       regular expressions apply after comments are removed
     * [X] QT4CG-067-01: NW to ask the XML Prague organizers for hosting
     * [X] QT4CG-067-02: MK to revert the changes to the test suite for
       EBV (PR 1003)

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 [30]#956: 850-partial Editorial improvements to parse-html()
     * PR [31]#529: 528 fn: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 [32]#1051: 1043 Clarification of CSV edge cases
     * PR [33]#1046: 1038 take-while predicate no longer uses EBV

1.6.3. 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 [34]#1017: Change csv-to-xml() to produce an XHTML table
     * Issue [35]#825: array:members-at
     * Issue [36]#413: New function: parse-csv()

2. Technical Agenda

2.1. Review of blocked PRs

   What's the status on these?
     * PR [37]#956: 850-partial Editorial improvements to parse-html()
     * PR [38]#529: 528 fn:elements-to-maps

   MK reports: They're both mine; I'm aware of them. I've been working on
   more interesting things. I will get back to them.

2.2. PR #1053: 1047 Default predicate for some#1 and every#1

   See PR [39]#1053

   MK reviews the PR.
     * MK: Because of function coercion, fn:identity gets coerced and that
       made some of the prose incorrect. CG's suggestion of using
       boolean#1 fixes that.

   Proposal: accept this PR.

   Accepted.

2.3. PR #1049: 340-partial fn:format-number: Specifying decimal format

   See PR [40]#1049

   CG reviews the PR starting with the original issue.
     * CG: The fn:format-number function works well for English numbers,
       but you have to add a decimal format to the prolog for German
       numbers.
          + ... The intent is to make this simpler. The first step is the
            ability to include the decimal format inside the function (as
            a map).
          + ... The next step is to allow a user to specify the language.
     * CG reviews the spec changes.
     * CG: Is an implementation allowed to provide predefined decimal
       formats for languages?
          + ... Java already makes this easy.
     * JLY: If that map contains an arbitrary value that isn't meaningful,
       is that an error?
     * CG: It should be. The same rules should apply that apply to the
       prolog.
     * JK: I think this is a good improvement. Did you consider
       introducing an options map so that we can just add more things
       later?
     * CG: No, but we could.
     * JK: I remember think that there was something I wanted to add.
     * MK: Related to that is the question of whether the option
       conventions apply: atomization, etc.
     * JLO: Would it make sense for the name-format to be specified here,
       or should we reference some other spec normatively. So, for
       example, de means the same thing across implementations.
     * CG: It's an interesting question. But I think the existing rules
       are only recommendations.
     * MK: Yes. Generally in XQuery, the static context is implementation
       defined. But do we prescribe what "format=de" means?
          + ... I think we can't because there are so many languages.
     * RD: I was going to suggest referencing the [41]Unicode Common
       Locale Data Repository (CLDR) that has recommendations for all of
       the languages in Unicode and some variants.
          + ... That's where libraries like Java and ICU get their data
            from.
          + ... We can say that implementations should use the common
            locale registry.
          + ... We could go further and say that "-" corresponds to the
            character with the "minus" property in CLDR.
     * JLO: That was my idea too.
     * MK: Traditionally the default for minus has been hyphen, but it's
       probably better to use the Unicode "minus" character. That's a
       technical decision.
     * RD: Using the CLDR, it's all standardized in libraries.
     * MK: But it's not good at decisions like that which are at least
       partly typographic.
     * CG: You can still override all of the choices.
     * JLY: What happens when you try round-tripping one of these?
     * MK: In general it fails.
     * CG: You need to extend parse integer.
     * NW: I found $format-name and $format confusing.
     * MK: I tripped over the same thing in the paragraphs.
     * NW: CG's original question was, can you define "de" to mean
       something specific.
     * MK: Yes, I think you can. At least in XQuery, probably not in XSLT.

   Proposal: accept this PR.

   Accepted. (CG to merge after one editorial change.)

2.4. PR #1027: 150 fn:ranks

   See PR [42]#1027

   Defer until DN is available.

2.5. PR #832: 77 Add map:deep-update and array:deep-update

   See PR [43]#832

   MK introduces the discussion.
     * MK: I think this is now a fairly complete and viable spec; but I
       don't really expect it to be accepted without discussion of
       alternatives.
          + ... It's XQuery only which is one of the things we might like
            to discuss.
          + ... We start in 4.14.5 Update Expressions. I've replaced HoF
            with custom syntax.
          + ... The only reason we have map or array there is to
            disambiguate the grammar.

   MK walks through the prose of the spec.
     * MK: It turns out that the syntax is fairly intuitive but the
       underlying semantics are horrendous!
          + ... You have to make a small pipeline if you're making
            multiple updates; does that need more semantics to make it
            easier?

   MK walks through the rather hairy semantics.
     * MK: There's an open question about whether the new values still has
       the labels; it probably shouldn't.
     * RD: In previous version of XQuery, there was the update facility
       extension module. That was separate from the core specification.
       That defines things like insert/delete/replace/rename, etc. on
       nodes. My question is, is this syntax the remit of that
       specification, or if we're adding this into the core, does that
       mean it would make sense to incorporate modification on nodes as
       well.
     * MK: All good questions. The first thing to point out is that XQuery
       Update has an enormous amount of machinery in place to make sure
       the updates can't be seen while they're in progress, except for the
       copy-modify expression.
          + ... If anything, this is similar to the copy-modify expression
            but it doesn't use anything like the pending update lists.
          + ... It doesn't have the problems of node identity or
            functional purity.
          + ... What is certainly true is that you could do something
            similar to this for nodes as well. But it's harder because of
            node identity; you pretty much have to copy the whole subtree
            when you change a node.
          + ... Not having identity makes it harder to specify; it uses
            the labeling feature to assign transient ids.
          + ... But, yes, it could be extended.
     * RD: What's the overlap and syntax confusion going to be like?
     * MK: Another thing to consider is that it's operating on a much
       simpler data model.
     * JLY: The verification step is to check that you're inside the map
       or array that you're dealing with. It strikes me that you can
       determine that statically.
     * MK: Yes. But not always. And it's easy to do by mistake. I decided
       rather than trying to restrict the syntax of the expression, it was
       better to validate the result.
     * CG: Thank you. It's a comprehensive proposal. I haven't checked the
       semantics but we do use XQuery Update in most of our complicated
       projects. We have noticed that there are sequences of updates. We
       should definitely try to find a syntax that allows you to do more
       than one operation gracefully.
          + ... I made one proposal for a possible syntax. We could also
            think about using the same syntax as XQuery Update. I think it
            would be fairly complex to define XQuery Update again for the
            core specification.
     * MK: There's all the complexity of validation and namespaces; it's
       operating in a much more complicated world.
     * CG: It would be nice to find a unified syntax.
     * JLO: For me, that syntax is very close to what I see in code that
       updates or modifies XML. But this is a different thing.
          + ... So why don't we have an insert here?
     * MK: That really is entirely a question of trying to eat the
       elephant in bite sized chunks. Produce something that's useful but
       minimal first. If we can make the semantics work, we can grow from
       there.
     * RD: Building on this discussion, i wonder if it makes sense to keep
       the XQuery Update syntax but then for the core XQuery
       specification, don't worry about the update lists or any of those
       things.
          + ... And then only limit it to maps and arrays. We know we can
            do those without that complex machinery.
     * MK: I was reluctant to use the copy-modify verb because people need
       to realize this doesn't involve a wholesale copy. Conceptually it's
       a copy but there's no identity so that's trivial.
     * RD: With things like the replace, delete, insert rename syntax in
       XQuery Update. Ideally, we would have the same general syntax but
       instead of saying node or nodes, you'd say map or array. The update
       facility syntax would then define the extensions for nodes.
          + ... The advantage of that is that we won't have yet another
            syntax for doing the same sort of thing.
     * MK: I'll look at whether the syntax can be aligned; but I'm
       reluctant to take on something too large and complicated.
     * RD: BaseX has an update syntax similar to this.
     * CG: Yes.
     * RD: I wonder if we could align or standardize along those lines.
          + ... The replace expression is standalone so you could maybe
            leverage that.
     * CG: MK, could you please open the pull request for #832.
          + ... I [44]made a suggestion for how to attempt to unify the
            syntax.
          + ... Being able to bind intermediate results to variables can
            be helpful.

3. Any other business

     * NW: Should I make the highlighting colors a little different?

   Some general agreement that it might be nice.
     * JLO: The [45]update extension in eXist DB seems to be very similar.

4. Adjourned

References

   1. https://qt4cg.org/meeting/minutes/2024/03-05.html#minutes
   2. https://qt4cg.org/meeting/minutes/2024/03-05.html#new-actions
   3. https://qt4cg.org/meeting/minutes/2024/03-05.html#administrivia
   4. https://qt4cg.org/meeting/minutes/2024/03-05.html#roll-call
   5. https://qt4cg.org/meeting/minutes/2024/03-05.html#agenda
   6. https://qt4cg.org/meeting/minutes/2024/03-05.html#so-far
   7. https://qt4cg.org/meeting/minutes/2024/03-05.html#approve-minutes
   8. https://qt4cg.org/meeting/minutes/2024/03-05.html#next-meeting
   9. https://qt4cg.org/meeting/minutes/2024/03-05.html#open-actions
  10. https://qt4cg.org/meeting/minutes/2024/03-05.html#open-pull-requests
  11. https://qt4cg.org/meeting/minutes/2024/03-05.html#blocked
  12. https://qt4cg.org/meeting/minutes/2024/03-05.html#merge-without-discussion
  13. https://qt4cg.org/meeting/minutes/2024/03-05.html#close-without-action
  14. https://qt4cg.org/meeting/minutes/2024/03-05.html#technical-agenda
  15. https://qt4cg.org/meeting/minutes/2024/03-05.html#blocked-prs
  16. https://qt4cg.org/meeting/minutes/2024/03-05.html#pr-1053
  17. https://qt4cg.org/meeting/minutes/2024/03-05.html#pr-1049
  18. https://qt4cg.org/meeting/minutes/2024/03-05.html#pr-1027
  19. https://qt4cg.org/meeting/minutes/2024/03-05.html#pr-832
  20. https://qt4cg.org/meeting/minutes/2024/03-05.html#any-other-business
  21. https://qt4cg.org/meeting/minutes/2024/03-05.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/03-05.html
  28. https://qt4cg.org/meeting/minutes/2024/02-27.html
  29. https://qt4cg.org/meeting/agenda/2024/03-12.html
  30. https://qt4cg.org/dashboard/#pr-956
  31. https://qt4cg.org/dashboard/#pr-529
  32. https://qt4cg.org/dashboard/#pr-1051
  33. https://qt4cg.org/dashboard/#pr-1046
  34. https://github.com/qt4cg/qtspecs/issues/1017
  35. https://github.com/qt4cg/qtspecs/issues/825
  36. https://github.com/qt4cg/qtspecs/issues/413
  37. https://qt4cg.org/dashboard/#pr-956
  38. https://qt4cg.org/dashboard/#pr-529
  39. https://qt4cg.org/dashboard/#pr-1053
  40. https://qt4cg.org/dashboard/#pr-1049
  41. https://cldr.unicode.org/translation/number-currency-formats/number-and-currency-patterns
  42. https://qt4cg.org/dashboard/#pr-1027
  43. https://qt4cg.org/dashboard/#pr-832
  44. https://github.com/qt4cg/qtspecs/pull/832#issuecomment-1977135759
  45. https://exist-db.org/exist/apps/doc/update_ext

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 5 March 2024 17:29:27 UTC