QT4CG meeting 093 draft minutes, 8 October 2024

Hello folks,

Here are the draft minutes from today’s meeting:

   https://qt4cg.org/meeting/minutes/2024/10-08.html

Note that PR #1480: 1450 Disallow reserved names… is currently blocked by a merge conflict.

QT4 CG Meeting 093 Minutes 2024-10-08

   [1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
   Pull Requests

Table of Contents

     * [6]Draft Minutes
     * [7]Summary of new and continuing actions [0/8]
     * [8]1. Administrivia
          + [9]1.1. Roll call [12/12]
          + [10]1.2. Accept the agenda
               o [11]1.2.1. Status so far...
          + [12]1.3. Approve minutes of the previous meeting
          + [13]1.4. Next meeting
          + [14]1.5. Review of open action items [1/6]
          + [15]1.6. Review of open pull requests and issues
               o [16]1.6.1. Blocked
               o [17]1.6.2. Close without action
               o [18]1.6.3. Substantive PRs
     * [19]2. Technical agenda
          + [20]2.1. PR #1355: 1351 Add "declare record" in XQuery
          + [21]2.2. PR #1482: 1468 Revise the xsl:array instruction
          + [22]2.3. PR #1481: 1448 Component extraction on gregorian
            types
          + [23]2.4. PR #1480: 1450 Disallow reserved names in
            element/attribute constructors
          + [24]2.5. PR #1477: 1475 Stylesheet change to mark optional
            fields with '?'
          + [25]2.6. PR #1476: 1474 xml-to-json: ensure numbers are JSON
            conformant
     * [26]3. Any other business
     * [27]4. Adjourned

Draft Minutes

Summary of new and continuing actions [0/8]

     * [ ] QT4CG-080-07: NW to update the build instructions in the README
     * [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
       fn:ranks proposal
     * [ ] QT4CG-088-01: NW to consider how best to add a dedication to
       MSM.
     * [ ] QT4CG-088-04: [Someone] needs to update the processing model
       diagram needs vis-a-vis the static typing feature
     * [ ] QT4CG-089-01: CG to draft a PR that attempts to resolve the
       operators described in #755 to a smaller number of orthogonal
       choices.
     * [ ] QT4CG-093-01: NW to fix the bug in the burndown charts
     * [ ] QT4CG-093-02: NW to resolve the F&O search box one way or the
       other
     * [ ] QT4CG-093-03: NW to make dashboard links redirect to the
       issue/PR when they're no longer on the dashboard

1. Administrivia

1.1. Roll call [12/12]

     * [X] David J Birnbaum (DB)
     * [X] Reece Dunn (RD)
     * [X] Sasha Firsov (SF) [-:35]
     * [X] Christian Gr¸n (CG)
     * [X] Joel Kalvesmaki (JK) [:10-]
     * [X] Michael Kay (MK)
     * [X] Juri Leino (JLO)
     * [X] John Lumley (JWL)
     * [X] Dimitre Novatchev (DN)
     * [X] Wendell Piez (WP)
     * [X] Ed Porter (EP)
     * [X] Norm Tovey-Walsh (NW). Scribe. Chair.

1.2. Accept the agenda

   Proposal: Accept [28]the agenda.

   Accepted.

1.2.1. Status so far...

   These charts have been adjusted so they reflect the preceding six
   months of work.

   issues-open-2024-10-08.png

   Figure 1: "Burn down" chart on open issues

   issues-by-spec-2024-10-08.png

   Figure 2: Open issues by specification

   issues-by-type-2024-10-08.png

   Figure 3: Open issues by type

1.3. Approve minutes of the previous meeting

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

   Accepted.

1.4. Next meeting

   This next meeting is planned for 15 October. Any regrets?

   None heard.

   Note: The QT4CG operates on European civil time. In Europe and the
   United Kingdom, summer time ends on 27 October. In the United States,
   summer time ends on 3 November. That means the meeting of 29 October
   will be one hour later in the United States.

1.5. Review of open action items [1/6]

   (Items marked [X] are believed to have been closed via email before
   this agenda was posted.)
     * [ ] QT4CG-080-07: NW to update the build instructions in the README
     * [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
       fn:ranks proposal
     * [ ] QT4CG-088-01: NW to consider how best to add a dedication to
       MSM.
     * [ ] QT4CG-088-04: [Someone] needs to update the processing model
       diagram needs vis-a-vis the static typing feature
     * [ ] QT4CG-089-01: CG to draft a PR that attempts to resolve the
       operators described in #755 to a smaller number of orthogonal
       choices.
     * [X] QT4CG-091-01: MK to make sure there's an editorial note about
       parameter renaming.

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]#1296: 982 Rewrite of scan-left and scan-right
     * PR [31]#1283: 77b Update expressions
     * PR [32]#1062: 150bis revised proposal for fn:ranks
     * PR [33]#529: 528 fn:elements-to-maps

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 [34]#1305: Almost all functions in FO that must process
       multiple string items, can have as a parameter only a single
       collation
     * DN: I think the problem is clear, but I don't feel there's any
       understanding or agreement on the thread. We need to agree that
       there's a problem and then find a solution. I wouldn't publish the
       documents without solving the problem.
     * NW: It would be good to have a plan to make some progress.
     * DN: I have proposed two solutions, a special case and a more
       general solution.
          + When we have a comparison that involves more than a sequence
            of strings, at the present, our signatures only allow a single
            collation. But an article written by several people may
            require different collations for different names.
          + Just providing a single collation won't solve the issue. I
            think this is a real problem in practice.
     * CG: I haven't comment on the issue, but I would need to have a full
       PR to see what the problem is. I haven't encountered this problem
       and I haven't seen any examples in this issue that demonstrates how
       an existing problem can't be solved.
     * MK: I don't think we should spend a lot of time today discussing
       the issue. I think we should concentrate on process. There are 130
       open issues, some with extensive discussion that hasn't lead to
       consensus. Sometimes that there's a problem, sometimes what the
       solution is.
          + We have focus on finishing things, not starting them.
     * JL: Given that this isn't a very common thing, is it something that
       could be sorted by complex comparitor functions? That you could
       solve this problem with a higher order function if you needed to.
     * DN: I think this is a problem everywhere deep equal is used. If we
       don't solve this, we need to note that it may not produce the right
       result.
     * RD: In order for this proposal to work, two things need to be
       resolved.
         1. How implementations on things like SQL database backends or
            Java and such will work in terms of working with multiple
            collations
         2. And how things like things like comparisons and such will work
            when you have incompatible locales.
     * NW: Okay. I'm inclined to leave this open for another week. If this
       is important to you, try to advance it. If it doesn't advance,
       we'll revisit closing it next week.

1.6.3. Substantive PRs

   The following substantive PRs were open when this agenda was prepared.
     * PR [35]#1482: 1468 Revise the xsl:array instruction
     * PR [36]#1481: 1448 Component extraction on gregorian types
     * PR [37]#1480: 1450 Disallow reserved names in element/attribute
       constructors
     * PR [38]#1477: 1475 Stylesheet change to mark optional fields with
       '?'
     * PR [39]#1476: 1474 xml-to-json: ensure numbers are JSON conformant
     * PR [40]#1472: 1471 JSON Serialization: Sequences on Top Level
     * PR [41]#1470: 689 fn:stack-trace: replace with $err:stack-trace
     * PR [42]#1467: Modest editorial corrections to XSLT specs through
       2.7
     * PR [43]#1454: 1449 Relax rules on multiple xsl:includes
     * PR [44]#1442: 1394 Add new default priority rules
     * PR [45]#1378: 1375 bugs in pattern syntax
     * PR [46]#1355: 1351 Add "declare record" in XQuery
     * PR [47]#1227: 150 PR resubmission for fn ranks

2. Technical agenda

2.1. PR #1355: 1351 Add "declare record" in XQuery

   See [48]#1355

   MK introduces the issue. This is a substantial issue but we have
   discussed it before. MK reviews the changes in the XQuery spec.
     * MK: There is a bunch of noise because of terminology changes, but
       thhe meat of the proposal is in 5.20 Named Record Types.
          + ... Doesn't remove item type declaration, but supplements it
            with declare record.
          + ... (MK talks through several of the examples)
          + ... Declared records can be recursive where item types don't
            allow forward references.
          + ... You can use functions as entries in records; an area
            function for a rectangle record type, for example.
          + ... I'm intending to do something similar for XSLT, but that
            will be a follow-on action.
     * JLO: I'm wondering about the " *" in the example
     * MK: Yes, that's a feature we introduced a while ago.
     * CG: I really like the proposal, there's a remaining syntax error in
       5.22 but I've proposed a solution.
     * DN: You mentioned that there are two ways of defining a record type
       now, but only one allows recursive references. Which one?
     * MK: Declare record allows recursion. But the general declare item
       type doesn't.
     * DN: I want to reiterate that we should provide some standard record
       types.

   Proposal: accept this PR

   Accepted.

2.2. PR #1482: 1468 Revise the xsl:array instruction

   See [49]#1482

   MK introduces the proposal.
     * MK: Thanks JK for extensive comments; I've taken those on board and
       updated the PR.
     * MK: The bulk of the proposal is in 22.1 array construction which is
       essentially rewritten.
          + ... In the previous draft, there was a use expression.
          + ... In this proposal, you can do it in several different ways.
          + ... (MK walks through the prose of the PR)
          + ... The xsl:array-member instruction can be used to construct
            members.
          + ... (MK walks through several examples from the PR)
     * JWL: Basically, the xsl:array-member is a special tag that's
       understood by the array when it's pulled together: everything in
       here is one element in the array.
     * MK: Yes, it parcels up the values.
     * MK: It creates a value record, it can be used outside of
       xsl:array-member.
     * JWL: That's parallel to the xsl:map-entry
     * MK: Yes.
     * JWL: Is there a matrix inversion example? Can we have one, please?
     * MK: Yes, there's an example of inverting a nested array.
     * DN: My question is, if I can do this in XPath and it's simpler and
       shorter, why would I do this?
     * MK: The problem is when it comes to calling XSLT form XPath. If you
       want to use grouping, or apply-templates, or analyze-string, it's a
       lot harder to get back into XPath from there.
          + ... If you're converting to JSON, you might have arrays in
            maps in arrays and that's the use case.
     * DN: I think this could be improved by specifically indicating when
       to use one approach and when to use another.
     * MK: We always have to decide how much tutorial material to add.

   Some further discussion of the lack of composability between XPath
   expressions and XSLT instructions.
     * JK: This is a great proposal. I disagree with DN, the reader of
       this specification is already aware that there's overlap and we
       should try to keep them in tandem.
          + ... The example with xsl:apply-templates is realy compelling.
          + ... In the original issue I raised, MK raised a question about
            type safety. What's the issue there?
     * MK: There's a need to find a balance and this proposal changes the
       balance. You want it to be flexible and intuitive, but you also
       want it to scream loudly when the intuitive approach doesn't give
       you the result you want.
          + ... That's why this proposal doesn't allow you to construct
            heterogenous arrays. My gut feeling is that if you were using
            a heterogenous sequence, you were probably doing it by
            mistake.
     * JLO: I like this a lot. I think this is very nice and I'm not
       really an XSLT user. I was only confused by converting a sequence
       of arrays to an array of sequences. I'd like to know more about why
       you'd do that.
     * MK: I added it because other people thought it was a good idea, not
       because I did.
          + ... I think there are some use cases where the members will
            arrive as arrays. That might be a mistake, but we'll see.

   Proposal: accept this PR

   Accepted.

2.3. PR #1481: 1448 Component extraction on gregorian types

   See [50]#1481
     * MK: This is a quite simple proposal, but I expect some will love it
       and some will hate it.
          + ... It fills a longstanding gap around the g* date types.
          + ... Rather than introducing new functions to support them,
            I've extended the functions for extracting components from
            date times so that they work from all the "gregorian types".
     * NW: Seems like a good idea to me.
     * JWL: This seems like a good idea to me too.

   Proposal: accept this PR

   Accepted.

2.4. PR #1480: 1450 Disallow reserved names in element/attribute constructors

   See [51]#1480
     * MK: This is motivated by the syntax ambiguities that we found by
       introducing bare-brace map constructors.
          + ... It doesn't change them, but it is an enabler that allows
            us to revisit that.
          + ... A lot of the ambiguities with bare-brace map constructors
            had to do with special cases.
          + ... The bulk of the changes is in 4.12.3.1 Computed Element
            Constructors.
     * JWL: This is a lot easier to read on the non-diffed version

   MK switches to the non-diff version.
     * MK reviews the proposal in 4.12.3.1 Computed Element Constructors.
          + ... If you want to use reserved names like div and value, you
            have to quote them.
          + ... That's pretty much it, but the text is restructured a bit.
     * CG: Does that mean we can get rid of the rule for standalone
       expression again?
     * MK: I hope so, perhaps JWL can help review the ambigutities again.
     * JWL: I'll do that once this is merged.
     * RD: Is it possible to work out a subset of all the possible
       keywords that could conflict and then ohly do it with them. I think
       that when the keywords are the names of HTML elements that's going
       to be quite common.
     * MK: I don't know, but "div", for example, that is one that's
       umbiguous.
     * RD: But it's unlikely that you'd want a simplified map there.
     * MK: A lot of the problem here is that a lot of the things that
       won't parse are things you wouldn't want to write anyway.
          + ... It's unclear if we could isolate the cases, binary
            operators in particular, and have a shorter list.
     * RD: We can always accept this and then refine it later.
     * JLO: I'm in the same boat as RD. I expect that "div" occurs in a
       lot of code. To get rid of this one thing would already help a lot.
     * NW: But "div" is squarely in the list of things you can't have.
     * MK: It would be nice to argue that the problem is only when you
       have curly braces on the right hand side, but that's not how the
       parser works.
     * JLO: So the fact that div can't be followed by a curly brace isn't
       something we can do?
     * MK: It's very, very mess to make the grammar rules depend on type
       rules.
     * RD: Can we do something similar to what we do with the open element
       case.
     * MK: Which case?
     * RD: Where you've got something like if ($a <foo... where that <
       could be a less than or the start of an element.
          + ... In the current spec, in order for it to be an open element
            it has to match a more specific grammar rule.
     * MK: I'm not sure how you'd do that.
     * RD: Something like div { and then ... presumably that would be a
       string name colon or ... I can't remember if we allow general
       constructs as the key name.
          + ... I think it's something we need to discuss separately.
     * JWL: I've been working on this one with the generated grammars.
       It's the computed constructed nodes in XQuery that give the
       problem. This is where it hits hard. Anything like "div" and
       "return" in that place as an NCName between the type of the node
       you want to produce and the thing that could be the sequence
       constructor or an empty map is the one place this is most
       problematic.
     * WP: As a person who writes mostly XSLT, I'm thinking when I write
       XQuery I mostly don't use an element constructor unless I have to
       compute the name.
          + ... I think we should address the XQuery problem head on.
     * RD: Am I right in saying this is only an issue for empty maps?
     * MK: No, it's any map constructor.
     * RD: Could we limit this restriction to the case where the braces
       are empty?

   Proposal: accept this PR

   Accepted.

   (The PR was blocked by merge conflicts at the time of publication.)

2.5. PR #1477: 1475 Stylesheet change to mark optional fields with '?'

   See [52]#1477

   Proposal: accept this PR

   Accepted.

2.6. PR #1476: 1474 xml-to-json: ensure numbers are JSON conformant

   See [53]#1476

   Proposal: accept this PR

   Accepted.

3. Any other business

     * WP: Last week I was talking to someone doing an implementation and
       they remarked how clear the specifications are, so thanks to
       everyone involved.

   None heard.

4. Adjourned

References

   1. https://qt4cg.org/meeting/minutes/
   2. https://qt4cg.org/
   3. https://qt4cg.org/dashboard
   4. https://github.com/qt4cg/qtspecs/issues
   5. https://github.com/qt4cg/qtspecs/pulls
   6. https://qt4cg.org/meeting/minutes/2024/10-08.html#minutes
   7. https://qt4cg.org/meeting/minutes/2024/10-08.html#new-actions
   8. https://qt4cg.org/meeting/minutes/2024/10-08.html#administrivia
   9. https://qt4cg.org/meeting/minutes/2024/10-08.html#roll-call
  10. https://qt4cg.org/meeting/minutes/2024/10-08.html#agenda
  11. https://qt4cg.org/meeting/minutes/2024/10-08.html#so-far
  12. https://qt4cg.org/meeting/minutes/2024/10-08.html#approve-minutes
  13. https://qt4cg.org/meeting/minutes/2024/10-08.html#next-meeting
  14. https://qt4cg.org/meeting/minutes/2024/10-08.html#open-actions
  15. https://qt4cg.org/meeting/minutes/2024/10-08.html#open-pull-requests
  16. https://qt4cg.org/meeting/minutes/2024/10-08.html#blocked
  17. https://qt4cg.org/meeting/minutes/2024/10-08.html#close-without-action
  18. https://qt4cg.org/meeting/minutes/2024/10-08.html#substantive
  19. https://qt4cg.org/meeting/minutes/2024/10-08.html#technical-agenda
  20. https://qt4cg.org/meeting/minutes/2024/10-08.html#pr-1355
  21. https://qt4cg.org/meeting/minutes/2024/10-08.html#pr-1482
  22. https://qt4cg.org/meeting/minutes/2024/10-08.html#pr-1481
  23. https://qt4cg.org/meeting/minutes/2024/10-08.html#pr-1480
  24. https://qt4cg.org/meeting/minutes/2024/10-08.html#pr-1477
  25. https://qt4cg.org/meeting/minutes/2024/10-08.html#pr-1476
  26. https://qt4cg.org/meeting/minutes/2024/10-08.html#any-other-business
  27. https://qt4cg.org/meeting/minutes/2024/10-08.html#adjourned
  28. https://qt4cg.org/meeting/agenda/2024/10-08.html
  29. https://qt4cg.org/meeting/minutes/2024/10-01.html
  30. https://qt4cg.org/dashboard/#pr-1296
  31. https://qt4cg.org/dashboard/#pr-1283
  32. https://qt4cg.org/dashboard/#pr-1062
  33. https://qt4cg.org/dashboard/#pr-529
  34. https://github.com/qt4cg/qtspecs/issues/1305
  35. https://qt4cg.org/dashboard/#pr-1482
  36. https://qt4cg.org/dashboard/#pr-1481
  37. https://qt4cg.org/dashboard/#pr-1480
  38. https://qt4cg.org/dashboard/#pr-1477
  39. https://qt4cg.org/dashboard/#pr-1476
  40. https://qt4cg.org/dashboard/#pr-1472
  41. https://qt4cg.org/dashboard/#pr-1470
  42. https://qt4cg.org/dashboard/#pr-1467
  43. https://qt4cg.org/dashboard/#pr-1454
  44. https://qt4cg.org/dashboard/#pr-1442
  45. https://qt4cg.org/dashboard/#pr-1378
  46. https://qt4cg.org/dashboard/#pr-1355
  47. https://qt4cg.org/dashboard/#pr-1227
  48. https://qt4cg.org/dashboard/#pr-1355
  49. https://qt4cg.org/dashboard/#pr-1482
  50. https://qt4cg.org/dashboard/#pr-1481
  51. https://qt4cg.org/dashboard/#pr-1480
  52. https://qt4cg.org/dashboard/#pr-1477
  53. https://qt4cg.org/dashboard/#pr-1476

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 8 October 2024 16:36:50 UTC