QT4CG Draft Minutes 051, 24 October 2023

Hello,

Here are the draft minutes from today’s meeting:

     https://qt4cg.org/meeting/minutes/2023/10-24.html

QT4 CG Meeting 051 Minutes 2023-10-24

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [0/8]
     * [3]1. Administrivia
          + [4]1.1. TODO Roll call [9/11]
          + [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 [5/7]
          + [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
               o [14]1.6.4. XSLT focused
               o [15]1.6.5. Substantive PRs
               o [16]1.6.6. Proposed for V4.0
     * [17]2. Technical Agenda
          + [18]2.1. Issue 129: Context item -> Context value?
          + [19]2.2. Issue 238: Support Invisible XML
          + [20]2.3. PR #635: 451: Schema compatibility
          + [21]2.4. PR #734: 517: fn:chain
     * [22]3. Any other business?
     * [23]4. Adjourned

   [24]Agenda index / [25]QT4CG.org / [26]Dashboard / [27]GH Issues /
   [28]GH Pull Requests

Draft Minutes

Summary of new and continuing actions [0/8]

     * [ ] QT4CG-046-01: MK to continue the work on #129 for the other
       specs (we accepted #703)
     * [ ] QT4CG-050-02: MP to attempt to summarize this discussion and
       identify specific issues
     * [ ] QT4CG-051-01: NW to attempt to craft a new issue for the
       remaining items in #129
     * [ ] QT4CG-051-02: NW to attempt to draft a proposal for
       fn:invisible-xml
     * [ ] QT4CG-051-03: MK to check that in our view schema components
       don't indirectly reference the schema root
     * [ ] QT4CG-051-04: DN to make the point that in simple, static
       cases, the arrow operators may be better.
     * [ ] QT4CG-051-05: DN to correct the typo in item 3 "could be
       sequence" => "could
     * [ ] QT4CG-051-06: MK to help DN with the markup in fn:chain
       examples.

1. Administrivia

1.1. TODO Roll call [9/11]

     * [X] Reece Dunn (RD)
     * [ ] Sasha Firsov (SF)
     * [X] Christian Gr¸n (CG)
     * [X] Joel Kalvesmaki (JK) [:10-]
     * [X] Michael Kay (MK)
     * [X] John Lumley (JL)
     * [X] Dimitre Novatchev (DN)
     * [X] Wendell Piez (WP)
     * [ ] Ed Porter (EP)
     * [X] C. M. Sperberg-McQueen (MSM)
     * [X] Norm Tovey-Walsh (NW). Scribe. Chair.

1.2. Accept the agenda

   Proposal: Accept [29]the agenda.

   Accepted.

1.2.1. Status so far...

   issues-open-2023-10-24.png

   Figure 1: "Burn down" chart on open issues

   issues-by-spec-2023-10-24.png

   Figure 2: Open issues by specification

   issues-by-type-2023-10-24.png

   Figure 3: Open issues by type

1.3. Approve minutes of the previous meeting

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

   Accepted.

1.4. Next meeting

   ATTENTION: Europe and the United Kingdom switch from daylight saving
   time to standard time on Sunday, October 29, 2023. The meeting on
   Tuesday, 31 October 2023, will occur at a time one hour later in The
   United States.

   The next meeting [31]is scheduled for Tuesday, 31 October 2023.

   No regrets heard.

1.5. Review of open action items [5/7]

     * [ ] QT4CG-046-01: MK to continue the work on #129 for the other
       specs (we accepted #703)
     * [X] QT4CG-046-04: CG to flesh out changes related to annotations in
       other parts of the specs
     * [X] QT4CG-046-05: NW to updated parse-uri to use decode-from-uri
       (issue #566)
     * [X] QT4CG-048-02: MK to clean up the proposal for adding @as to
       xsl:sequence and elsewhere
          + MK proposes to close as unclear
     * [ ] QT4CG-050-02: MP to attempt to summarize this discussion and
       identify specific issues
     * [X] QT4CG-050-01: MK to revise #749 to retain only the editorial
       parts.
     * [X] QT4CG-050-03: MK to make the proposed editorial improvements to
       PR #659

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 [32]#538: 480: Attempt to allow xs:string to be 'promoted to'
       xs:anyURI

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 [33]#766: 765 Update version references etc to 4.0 status
     * PR [34]#763: 686: XQFO diagnostic function documentation
     * PR [35]#762: 758: XQFO minor edits 3
     * PR [36]#749: 653: Add string literals E".." and L".." to control
       entity expansion
     * PR [37]#659: 647: schema location hints

   Proposal: Merge without discussion.

   Accepted.

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 [38]#383: fn:deep-equal: Order of child elements
       (unordered-elements)

   Proposal: Close without action.

   Accepted.

1.6.4. XSLT focused

   The following PRs appear to be candidates for a future XSLT-focussed
   meeting.
     * PR [39]#470: 369: add fixed-prefixes attribute in XSLT
     * PR [40]#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 [41]#742: xsl:function-library: keep, drop, or refine?
     * Issue [42]#169: Handling of duplicate keys in xsl:map
     * Issue [43]#168: XSLT Extension Instructions invoking Named
       Templates

1.6.5. Substantive PRs

   The following substantive PRs were open when this agenda was prepared.
     * PR [44]#761: 554/754 Simplify the new transitive-closure function
     * PR [45]#753: 65: Allow xmlns="xxx" to NOT change the default
       namespace for NameTests
     * PR [46]#737: 295: Boost the capability of recursive record types
     * PR [47]#736: 730: Clarify (and correct) rules for maps as instances
       of function types
     * PR [48]#734: 517: fn:chain
     * PR [49]#719: 413: Spec for CSV-related functions
     * PR [50]#635: 451: Schema compatibility
     * PR [51]#529: 528: revision of json(), and renaming to
       elements-to-maps()

1.6.6. Proposed for V4.0

   The following issues are labled "proposed for V4.0".
     * Issue [52]#716: Generators in XPath
     * Issue [53]#479: fn:deep-equal: Input order
     * Issue [54]#340: fn:format-number: Specifying decimal format
     * Issue [55]#260: array:index-of
     * Issue [56]#238: Support Invisible XML
     * Issue [57]#130: New super/union type xs:binary?
     * Issue [58]#129: Context item -> Context value?
     * Issue [59]#31: Extend FLWOR expressions to maps

2. Technical Agenda

2.1. Issue 129: Context item -> Context value?

   See issue [60]#129: does this need to remain open? Can we create
   actions for the unresolved edits instead?

   ACTION QT4CG-051-01: NW to attempt to craft a new issue for the
   remaining items in #129

2.2. Issue 238: Support Invisible XML

   See issue [61]#238: time boxed discussion to see if the group wants to
   do this.

   ACTION QT4CG-051-02: NW to attempt to draft a proposal for
   fn:invisible-xml

2.3. PR #635: 451: Schema compatibility

   See PR [62]#635.

   MK introduces the issue.
     * MK: We say very little about what happens if you import multiple
       schemas.
          + ... MK reviews what the various specs say, or don't say.
          + ... This PR defines a compatibility relationship between two
            schemas
          + ... It then specifies that schemas must be compatible where
            they intersect.
     * MK walks through the Data Model changes
          + ... The most basic comaptibilty condition is that they don't
            have different components with the same name.
          + Cases where things can be different (but still compatible):
               o Subsitution group membership
               o Different extensions for the same base type
               o Lax wildcards
          + ... When you validate with one schema and then pass the
            document to another module, there are some gaurantees, but
            there are also things that can vary.
          + ... The rest of the changes are about how these rules are
            applied.
     * RD: Do we want to bring in some other definitions from XML Schema
       for completeness. There's a discussion on the XML.com Slack by Adam
       Retter about the definition of the base type which is defined in
       XML Schema but not used here.
     * MK: Is that directly relevant to this topic, or is it something
       wider?
     * RD: It's not specific to the schema consistency changes but it's
       part of the process of bringing in schemas.
     * MK: I think we should have a separate issue for that.

   Some further discussion of the type derivation rules and the discussion
   that took place on the XML.com Slack.
     * MSM: My recollection is that there were two schools of thought
       within the Schema WG and consequently perhaps in the specification
       about what it meant for one component to point to another. One
       school of thought was knowing the base type name. The other school
       of thought was that what you had was transclusion; you had to
       dereference that pointer so if you had two schemas where the base
       types were slightly different, they were different even though they
       had the same name. Connected with this there was a mechanism that
       allowed one to construct a link of references to the schema
       components. This meant adding any item to a schema changed all the
       items in the schema.
          + ... What I'm hearing you say is that we expect most people to
            take the identity of names view.
     * MK: I don't think it makes a difference whether you take the
       reference as being a name or a pointer to a component. If the names
       are the same, then the components have to be the same by recursive
       application of the rule.
          + ... The point about a chain of references back up to the root
            of the tree is more concerning. If that's the case, then this
            theory fails. I guess I'd need to search exhaustively to see
            if there exists such a property.
     * MSM: That sounds to me as if there is some non-zero chance that
       there's a problem.
     * MSM: The second question is, if I do have two incompatible schemas,
       and I want to use one to validate and expression and then feed it
       into a stylesheet where a different schema is used. I imagine I'm
       going to want to say at this point that the processor is going to
       have to revalidate. Is that feasible?
     * MK: I've raised a separate issue about multiple schemas where I'm
       starting to think about being able to import two schemas, give them
       names, and then say which one you want to validate against. That's
       not part of this proposal.
          + ... If you want to convert between incompatible schemas, you
            can't do that within a single module or stylesheet. Resolving
            that is another step.

   Proosal: Merge this PR.

   Accepted.

   ACTION QT4CG-051-03: MK to check that in our view schema components
   don't indirectly reference the schema root

2.4. PR #734: 517: fn:chain

   See [63]#734.
     * DN walks us through the function
     * DN: One of the features of the fn:chain function is that it adapts
       the results of the previous function to the arity of the next
       function.
          + ... DN describes the examples
     * JL: If we curry this against the first argument, then we have the
       composition of a set of functions.
          + ... We have the arrow operators that allow us to string things
            together that can handle a number of these static cases.
          + ... The difficult bit is going to be modeling what it means
            when the arity varies across the sequence of functions.
     * DN: I didn't hear a question, but thank you for mentioning the
       chaining operators. This is useful to know the difference between
       the arrow operators and fn:chain.
          + ... In the arrow operators, we have only expressions, but here
            we have functions with names. The fact that the arity can
            change makes the fn:chain function more powerful.
          + ... Others have asked about this more complicated case with
            changing arities. Nothing requires users to use the more
            complicated case, so I don't think that's a point of concern.
     * JL: We have two forms of arrow operators now. We have examples
       where you can go back and forth between those examples. You can use
       functions and expressions. The thing that what's much more
       complicated here is that the list of functions can very variable.
     * MSM: Can we clarify briefly the interaction of this wit variable
       arity functions? I guess if I have a variable arity function that
       can accept 3, 4, or 5 arguments then I really have three functions.
     * DN: Yes, and there are examples that demonstrate these things.
     * MK: Function items don't have variable arity; function definitions
       can have variable arity from which you can derive funtion items
       with specific arities.
     * MSM: In answering JL's comment, DN said these are always named
       functions. But if I'm handing fn:chain a sequence of functions, I
       can hand it anonymous functions, can't I?
     * DN: Yes, but that would be defeating part of the purpose of this
       function which is to provide a meaningful set of functions to be
       applied.

   A proposal to accept the PR is made, more discussion follows.
     * CG: Can we limit this to arity one functions? It could be hard to
       understand how this works if the semantics of the function varies
       depending on the arguments.
     * DN: The real power here is to make it possible to do more
       complicated things, but we aren't requiring users to use functions
       with arities greater than one. This is an extension of the idea of
       chaining.
     * CG: In this case, it would be useful to show some examples that
       require functions that have arities greater than one.
     * DN: Yes, we could have many more examples.
     * JL: I would say that in the notes for this function, I think it
       might be useful to say that in simple, static cases, it might be
       better to use the chaining operators.

   ACTION QT4CG-051-04: DN to make the point that in simple, static cases,
   the arrow operators may be better.
     * MSM: Editorially, in item 3 in the list, the fact that the sequence
       has "N" items is not parenthetical.

   ACTION QT4CG-051-05: DN to correct the typo in item 3 "could be
   sequence" => "could be sequences".

   ACTION QT4CG-051-06: MK to help DN with the markup in fn:chain
   examples.

   Proposal: Accept this PR.

   Accepted.

3. Any other business?

   None heard.

4. Adjourned

References

   1. https://qt4cg.org/meeting/minutes/2023/10-24.html#minutes
   2. https://qt4cg.org/meeting/minutes/2023/10-24.html#new-actions
   3. https://qt4cg.org/meeting/minutes/2023/10-24.html#administrivia
   4. https://qt4cg.org/meeting/minutes/2023/10-24.html#roll-call
   5. https://qt4cg.org/meeting/minutes/2023/10-24.html#agenda
   6. https://qt4cg.org/meeting/minutes/2023/10-24.html#so-far
   7. https://qt4cg.org/meeting/minutes/2023/10-24.html#approve-minutes
   8. https://qt4cg.org/meeting/minutes/2023/10-24.html#next-meeting
   9. https://qt4cg.org/meeting/minutes/2023/10-24.html#open-actions
  10. https://qt4cg.org/meeting/minutes/2023/10-24.html#open-pull-requests
  11. https://qt4cg.org/meeting/minutes/2023/10-24.html#blocked
  12. https://qt4cg.org/meeting/minutes/2023/10-24.html#merge-without-discussion
  13. https://qt4cg.org/meeting/minutes/2023/10-24.html#close-without-action
  14. https://qt4cg.org/meeting/minutes/2023/10-24.html#xslt-focused
  15. https://qt4cg.org/meeting/minutes/2023/10-24.html#substantive
  16. https://qt4cg.org/meeting/minutes/2023/10-24.html#proposed-40
  17. https://qt4cg.org/meeting/minutes/2023/10-24.html#technical-agenda
  18. https://qt4cg.org/meeting/minutes/2023/10-24.html#h-C2A69248-3E52-4051-A730-215B90AFF39E
  19. https://qt4cg.org/meeting/minutes/2023/10-24.html#h-A9F70A82-FE82-442A-B9C1-2027CB9628D8
  20. https://qt4cg.org/meeting/minutes/2023/10-24.html#schema-compatibility
  21. https://qt4cg.org/meeting/minutes/2023/10-24.html#chain
  22. https://qt4cg.org/meeting/minutes/2023/10-24.html#any-other-business
  23. https://qt4cg.org/meeting/minutes/2023/10-24.html#adjourned
  24. https://qt4cg.org/meeting/minutes/
  25. https://qt4cg.org/
  26. https://qt4cg.org/dashboard
  27. https://github.com/qt4cg/qtspecs/issues
  28. https://github.com/qt4cg/qtspecs/pulls
  29. https://qt4cg.org/meeting/agenda/2023/10-24.html
  30. https://qt4cg.org/meeting/minutes/2023/10-17.html
  31. https://qt4cg.org/meeting/agenda/2023/10-31.html
  32. https://qt4cg.org/dashboard/#pr-538
  33. https://qt4cg.org/dashboard/#pr-766
  34. https://qt4cg.org/dashboard/#pr-763
  35. https://qt4cg.org/dashboard/#pr-762
  36. https://qt4cg.org/dashboard/#pr-749
  37. https://qt4cg.org/dashboard/#pr-659
  38. https://github.com/qt4cg/qtspecs/issues/383
  39. https://qt4cg.org/dashboard/#pr-470
  40. https://qt4cg.org/dashboard/#pr-412
  41. https://github.com/qt4cg/qtspecs/issues/742
  42. https://github.com/qt4cg/qtspecs/issues/169
  43. https://github.com/qt4cg/qtspecs/issues/168
  44. https://qt4cg.org/dashboard/#pr-761
  45. https://qt4cg.org/dashboard/#pr-753
  46. https://qt4cg.org/dashboard/#pr-737
  47. https://qt4cg.org/dashboard/#pr-736
  48. https://qt4cg.org/dashboard/#pr-734
  49. https://qt4cg.org/dashboard/#pr-719
  50. https://qt4cg.org/dashboard/#pr-635
  51. https://qt4cg.org/dashboard/#pr-529
  52. https://github.com/qt4cg/qtspecs/issues/716
  53. https://github.com/qt4cg/qtspecs/issues/479
  54. https://github.com/qt4cg/qtspecs/issues/340
  55. https://github.com/qt4cg/qtspecs/issues/260
  56. https://github.com/qt4cg/qtspecs/issues/238
  57. https://github.com/qt4cg/qtspecs/issues/130
  58. https://github.com/qt4cg/qtspecs/issues/129
  59. https://github.com/qt4cg/qtspecs/issues/31
  60. https://github.com/qt4cg/qtspecs/issues/129
  61. https://github.com/qt4cg/qtspecs/issues/238
  62. https://qt4cg.org/dashboard/#pr-635
  63. https://qt4cg.org/dashboard/#pr-734

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 24 October 2023 17:09:15 UTC