- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Tue, 24 Oct 2023 12:40:28 -0700
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
- Message-ID: <CAK4KnZcCQC=eMWfU87iTLP43PoWhxZX7B1voJdUEvjgD3tYXPw@mail.gmail.com>
> 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