- From: Mukul Gandhi <gandhi.mukul@gmail.com>
- Date: Wed, 13 Mar 2024 16:34:52 +0530
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: "public-xslt-40@w3.org" <public-xslt-40@w3.org>
Hi Norm & all,
I've just wanted to write this little mail.
Is it possible that I may, attend one of the next meeting on software
chat application that you all use to conduct those meetings?
I'll be happy to listen to this WG's thoughts within one of those
meetings, about this WG's current work on XSL 4.0 groups of spec
development.
Please advise.
On Tue, Mar 12, 2024 at 10:49 PM Norm Tovey-Walsh <norm@saxonica.com> wrote:
>
> Hello folks,
>
> Here are the draft minutes from today’s meeting:
>
> https://qt4cg.org/meeting/minutes/2024/03-12.html
>
> QT4 CG Meeting 069 Minutes 2024-03-12
>
> Table of Contents
>
> * [1]Draft Minutes
> * [2]Summary of new and continuing actions [0/6]
> * [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
> o [14]1.6.4. Substantive PRs
> * [15]2. Technical Agenda
> + [16]2.1. Brief demo
> + [17]2.2. Diversion between the spec and test suite
> + [18]2.3. PR #1062/#1027: fn:ranks
> + [19]2.4. PR #1066: 1052 Simplify the results of parse-csv
> + [20]2.5. PR #1059: 1019 XQFO: Unknown option parameters
> * [21]3. Any other business
> * [22]4. Adjourned
>
> [23]Meeting index / [24]QT4CG.org / [25]Dashboard / [26]GH Issues /
> [27]GH Pull Requests
>
> Draft Minutes
>
> Summary of new and continuing actions [0/6]
>
> * [ ] 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.
> * [ ] QT4CG-069-01: MK to list the remaining issues that need
> discussion.
> * [ ] QT4CG-069-02: NW to coordinate with MK to use the introspection
> features on the test suite.
>
> 1. Administrivia
>
> 1.1. Roll call [11/13]
>
> Regrets SF.
> * [X] Reece Dunn (RD)
> * [ ] 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)
> * [X] Dimitre Novatchev (DN)
> * [X] Wendell Piez (WP)
> * [X] Ed Porter (EP)
> * [ ] Adam Retter (AR)
> * [X] C. M. Sperberg-McQueen (MSM)
> * [X] Norm Tovey-Walsh (NW). Scribe. Chair.
>
> 1.2. Accept the agenda
>
> Proposal: Accept [28]the agenda.
> * CG: I'd like to talk about divergence between the spec and the test
> suite.
>
> Accepted, with that ammendment.
>
> 1.2.1. Status so far...
>
> issues-open-2024-03-12.png
>
> Figure 1: "Burn down" chart on open issues
>
> issues-by-spec-2024-03-12.png
>
> Figure 2: Open issues by specification
>
> issues-by-type-2024-03-12.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
>
> The next meeting [30]is scheduled for Tuesday, 19 March 2024.
>
> Any regrets for the next meeting?
>
> None heard.
>
> 1.5. Review of open action items [8/12]
>
> * [ ] 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.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 [31]#956: 850-partial Editorial improvements to parse-html()
> * PR [32]#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 [33]#1058: 1037 fn:json-to-xml: 'number-parser' option
>
> Proposal: accept 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 [34]#961: Simulating Objects: Performance
> * Issue [35]#960: Should ??KS flatten the results
> * Issue [36]#829: fn:boolean: EBV support for more item types
> * Issue [37]#825: array:members-at
> * Issue [38]#757: Function families
> * Issue [39]#314: Basic Operations on Maps and Arrays
> * Issue [40]#295: Extend support for self-reference in record types
> * Issue [41]#274: What would it take/would it be possible to build a
> module repository for QT?
> * Issue [42]#262: Navigation in deep-structured arrays
> * Issue [43]#220: Encapsulation
>
> Proposal: close without further action.
> * MK: I proposed closing some of these because the discussion hadn't
> lead to any clear course of action. Some have been overtaken by
> events. Some have been implemented.
> * NW: I think it makes sense to keep the list tidy; we can open them
> again.
>
> Accepted.
>
> Some discussion of the issue of flattening sequences. DN is concerned
> that flattening causes data loss and we should do something about that.
> The problem will continue to exist even if we close the issue!
>
> 1.6.4. Substantive PRs
>
> The following substantive PRs were open when this agenda was prepared.
> * PR [44]#1068: 73 fn:graphemes
> * PR [45]#1066: 1052 Simplify the results of parse-csv
> * PR [46]#1062: 150bis - revised proposal for fn:ranks
> * PR [47]#1059: 1019 XQFO: Unknown option parameters
> * PR [48]#1027: 150 fn:ranks
> * PR [49]#832: 77 Add map:deep-update and array:deep-update
>
> 2. Technical Agenda
>
> 2.1. Brief demo
>
> SF had to give regrets, we'll postpone this to next week.
>
> 2.2. Diversion between the spec and test suite
>
> * CG: We have some features that have been added to the spec but not
> agreed.
>
> ACTION QT4CG-069-01: MK to list the remaining issues that need
> discussion.
> * CG: In the beginning, the test suite was pretty easy to navigate.
> But now we have lots of tests for things that aren't in the
> specification. I have a growing list of things that I need to add
> to the test suite.
> + ... Before adding more features, it would be nice to tidy up
> the current test suite.
> * MK: There's a mechanism, the "covers 4.0 attribute" that we haven't
> been using as diligently as we might.
> + ... In theory the test suite has a list of features and tests
> can be tagged against those features.
> + ... Ideally, those tags should be PR numbers and we should
> change the tagging of tests to identify the PR number that
> they're associated with.
>
> We can use PR tags to identify missing tests, accepted tests, etc.
> * MK: Incorrect tests we should manage with issues.
> * JLY: The one I encountered this morning is that there are tests for
> things about map keys that aren't in the spec.
> * NW: How do we make progress?
> * MK: There are introspective tests that test the test suite against
> the changes. We can try modifying the list of changes to match the
> PR numbers.
>
> ACTION QT4CG-069-02: NW to coordinate with MK to use the introspection
> features on the test suite.
> * CG: For features that will probably be added, we should use PRs.
>
> 2.3. PR #1062/#1027: fn:ranks
>
> See PR [50]#1062: 150bis - revised proposal for fn:ranks and PR
> [51]#1027: 150 fn:ranks
> * MK: My PR was an attempt to implement the things that I understood
> or that seemed uncontroversial.
> + ... I was saying "this is what I think the function should
> do."
>
> Some discussion of how to proceed. DN proposes we review MK's draft.
> * MK reviews his draft (PR #1062).
> + ... I understood this to be essentially a group sort.
> + ... It's a sort followed by a partitioning, or vice-versa
> + ... The signature takes identical parameters to fn:sort but
> instead of delivering a list of items, it returns a list of
> arrays of items.
> + ... It doesn't allow you to do the partitioning independently
> from what the sort is doing, as the other proposal does.
> * RD: With DN's proposal, what additional flexibility would we get?
>
> DN comments on MK's proposal.
> * DN: I think op:same-sort-keys() is a nice addition, but I don't
> think it's defined anywhere.
> + ... The order of arguments is problematic because it requires
> an empty () collation to be provided.
> + ... In the fifth example, we use the argument name keys but
> the argument is a single function. That's very confusing. What
> we need is a ranking function. The name key is unsatisfying.
> * DN: I'm also concerned about the fact that in MK's proposal the
> function argument isn't a single function, it's a sequence of
> functions!
>
> DN switches to present his proposal, PR #1027.
> * DN: My function has arguments that are easier to use.
> + ... This function was borrowed from SQL and they don't care
> about the fact that items can occur more than once because
> they deal with sets. But we don't.
> + ... This is why the $distinct-ranks parameter is needed and
> defaults to true().
> + ... The collation only has to be used when it's required.
> * DN highlights the difference that $distinct-ranks makes.
> * DN: MK wants to use the same function arguments as fn:sort but I
> think that's unnecessary.
> * NW: How does the sequence of functions come into play?
>
> DN makes a passionate argument for simplicity on behalf of the users.
> * RD: I think the sequence of functions is to support sorting by
> author then title, this is the reason fn:sort has multiple
> functions.
> + ... In fn:ranks if you wanted to sort by string-length and
> whether the length is odd or even, you'd need two functions.
> That's why you have multiple functions.
>
> Some discussion of whether you can write a single function to do that.
> * RD: The function you pass isn't just a comparison function, it's
> used to select the keys.
>
> Further discussion of whether or not it's even possible to write a
> single function for this purpose.
> * CG: Can you give an example, please, it's not clear.
> * JLO: Comparing both proposals, I see that one thing that bugged me
> was having to provide the empty sequence as the second argument to
> support.
> + ... If it's so problematic, creating a wrapper function isn't
> too problematic.
> + ... I do like functions in our specification to behave the
> same way.
> + ... If fn:sort and fn:ranks both need the collation, I would
> like it to be in the same place.
> * JLO: In DN's proposal, why are there two collations?
> * DN: The $collation-input is needed if the inputs are strings and
> $distinct-ranks is true. The collation is needed to make the input
> strings distinct.
>
> Some discussion of the difference between fn:sort and fn:sort-with.
> * JLO: Can we get rid of all the collations that way?
> * CG: Did you consider comparitor functions?
> * DN: I think we need them to make the strings unique.
> * CG: But not if you use comparitor functions.
> * RD: Isn't one of the disadvantage of a comparitor function is that
> you can't hash the returned keys so you don't have to compute them
> every time. That makes it easier to build the ranked data
> structure.
> * CG: You can cache those in the comparitor case; the optimizations
> are different but it can be done.
>
> DN agrees to demonstrate a single function that can take the place of
> several.
>
> 2.4. PR #1066: 1052 Simplify the results of parse-csv
>
> See PR [52]#1066
> * MK: I don't think we can review the proposal this week.
> * NW: I'll make sure this is on the top of the agenda next week.
>
> 2.5. PR #1059: 1019 XQFO: Unknown option parameters
>
> See PR [53]#1059
> * CG reviews his PR.
> + ... The fact that unknown options are ignored means that typos
> aren't detected.
> + ... One question is what we do about vendor extension options.
> + ... I think it would be best to reject any option that isn't
> known to the implementation.
> + ... Do we say you MUST raise an error or SHOULD raise an
> error.
> * MK: I think there are two issues: backwards compatibility. We'll
> find stylesheets that use misspelled names that didn't previously
> given an error. And vendor extensions: we may find users have
> deliberately used option names that they know are known to only one
> processor.
> * JLY: This is a case where it may be permitted to raise an error,
> but it should be user-configurable. There may be legitimate reasons
> to want to use options that aren't recognized.
> * MSM: What JL said.
> * DN: I think CG is right, it is always better to be notified about
> errors. What JL said also applies. But errors should be raised by
> default.
> * WP: I can see the value; apart from the question of "lint"
> checking, it would be nice if a common option could be provided,
> that could be useful.
> * JLO: If I WP right, it would be a "can be raised" but you'd define
> the error.
> * WP: There are operational advantages, but out on the edges, there
> may be cases where you want the current behavior.
> * RD: One of the challenges is that if you want to take advantage of
> vendor extensions, there's currently no mechanism to detect whether
> the version you're on supports a specific property.
> + ... I wonder if we could take advantage of records and have a
> "does this record support this property" check. Then you could
> check on the options for the function. That would provide a
> mechanism for validating incorrect parameters.
> * WP: So in the code, you could explicitly validate?
> * RD: Yes. You could say "if format in record type, then create a
> record with a format key." You could build the map up like that.
> That would let thing be more extensible. You wouldn't have to say
> "is there a vendor function and is the vendor version greater than
> some value", etc.
>
> No obvious consensus has formed, we'll come back to this next week.
>
> 3. Any other business
>
> None heard.
>
> 4. Adjourned
>
> References
>
> 1. https://qt4cg.org/meeting/minutes/2024/03-12.html#minutes
> 2. https://qt4cg.org/meeting/minutes/2024/03-12.html#new-actions
> 3. https://qt4cg.org/meeting/minutes/2024/03-12.html#administrivia
> 4. https://qt4cg.org/meeting/minutes/2024/03-12.html#roll-call
> 5. https://qt4cg.org/meeting/minutes/2024/03-12.html#agenda
> 6. https://qt4cg.org/meeting/minutes/2024/03-12.html#so-far
> 7. https://qt4cg.org/meeting/minutes/2024/03-12.html#approve-minutes
> 8. https://qt4cg.org/meeting/minutes/2024/03-12.html#next-meeting
> 9. https://qt4cg.org/meeting/minutes/2024/03-12.html#open-actions
> 10. https://qt4cg.org/meeting/minutes/2024/03-12.html#open-pull-requests
> 11. https://qt4cg.org/meeting/minutes/2024/03-12.html#blocked
> 12. https://qt4cg.org/meeting/minutes/2024/03-12.html#merge-without-discussion
> 13. https://qt4cg.org/meeting/minutes/2024/03-12.html#close-without-action
> 14. https://qt4cg.org/meeting/minutes/2024/03-12.html#substantive
> 15. https://qt4cg.org/meeting/minutes/2024/03-12.html#technical-agenda
> 16. https://qt4cg.org/meeting/minutes/2024/03-12.html#demo
> 17. https://qt4cg.org/meeting/minutes/2024/03-12.html#test-suite
> 18. https://qt4cg.org/meeting/minutes/2024/03-12.html#pr-1062
> 19. https://qt4cg.org/meeting/minutes/2024/03-12.html#pr-1066
> 20. https://qt4cg.org/meeting/minutes/2024/03-12.html#pr-1059
> 21. https://qt4cg.org/meeting/minutes/2024/03-12.html#any-other-business
> 22. https://qt4cg.org/meeting/minutes/2024/03-12.html#adjourned
> 23. https://qt4cg.org/meeting/minutes/
> 24. https://qt4cg.org/
> 25. https://qt4cg.org/dashboard
> 26. https://github.com/qt4cg/qtspecs/issues
> 27. https://github.com/qt4cg/qtspecs/pulls
> 28. https://qt4cg.org/meeting/agenda/2024/03-12.html
> 29. https://qt4cg.org/meeting/minutes/2024/03-05.html
> 30. https://qt4cg.org/meeting/agenda/2024/03-19.html
> 31. https://qt4cg.org/dashboard/#pr-956
> 32. https://qt4cg.org/dashboard/#pr-529
> 33. https://qt4cg.org/dashboard/#pr-1058
> 34. https://github.com/qt4cg/qtspecs/issues/961
> 35. https://github.com/qt4cg/qtspecs/issues/960
> 36. https://github.com/qt4cg/qtspecs/issues/829
> 37. https://github.com/qt4cg/qtspecs/issues/825
> 38. https://github.com/qt4cg/qtspecs/issues/757
> 39. https://github.com/qt4cg/qtspecs/issues/314
> 40. https://github.com/qt4cg/qtspecs/issues/295
> 41. https://github.com/qt4cg/qtspecs/issues/274
> 42. https://github.com/qt4cg/qtspecs/issues/262
> 43. https://github.com/qt4cg/qtspecs/issues/220
> 44. https://qt4cg.org/dashboard/#pr-1068
> 45. https://qt4cg.org/dashboard/#pr-1066
> 46. https://qt4cg.org/dashboard/#pr-1062
> 47. https://qt4cg.org/dashboard/#pr-1059
> 48. https://qt4cg.org/dashboard/#pr-1027
> 49. https://qt4cg.org/dashboard/#pr-832
> 50. https://qt4cg.org/dashboard/#pr-1062
> 51. https://qt4cg.org/dashboard/#pr-1027
> 52. https://qt4cg.org/dashboard/#pr-1066
> 53. https://qt4cg.org/dashboard/#pr-1059
--
Regards,
Mukul Gandhi
Received on Wednesday, 13 March 2024 11:05:14 UTC