Re: QT4CG Draft Minutes 051, 24 October 2023

   >  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-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.

I have completed both these action-items: QT4CG-051-04 and ACTION
QT4CG-051-05, by submitting a new PR:
https://github.com/qt4cg/qtspecs/pull/773

This just needs to be merged.

Thanks,
Dimitre

On Tue, Oct 24, 2023 at 10:09 AM Norm Tovey-Walsh <norm@saxonica.com> wrote:

> 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 19:40:49 UTC