- From: Michael Kay <mike@saxonica.com>
- Date: Wed, 29 Nov 2023 12:15:24 +0000
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
PRs 412 and 470 are now ready for merging. I propose adding PR 863 to the "accept without discussion" list. I have merged PR 856 which we accepted. Mike > On 28 Nov 2023, at 17:37, Norm Tovey-Walsh <norm@saxonica.com> wrote: > > Hello, > > Here are the minutes from today’s meeting: > > https://qt4cg.org/meeting/minutes/2023/11-28.html > > QT4 CG Meeting 056 Minutes 2023-11-28 > > Table of Contents > > * [1]Draft Minutes > * [2]Summary of new and continuing actions [0/9] > * [3]1. Administrivia > + [4]1.1. Roll call [10/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 [0/3] > + [10]1.6. Review of open pull requests and issues > o [11]1.6.1. Merge without discussion > o [12]1.6.2. XSLT focused > * [13]2. Technical Agenda > + [14]2.1. PR #470: 369: add fixed-prefixes attribute in XSLT > + [15]2.2. PR #412: 409, QT4CG-027-01: xsl:next-match > + [16]2.3. Issue #742: xsl:function-library: keep, drop, or > refine? > + [17]2.4. Issue #169: Handling of duplicate keys in xsl:map > + [18]2.5. Issue #323: add select attribute to xsl:text > * [19]3. Any other business? > * [20]4. Adjourned > > [21]Agenda index / [22]QT4CG.org / [23]Dashboard / [24]GH Issues / > [25]GH Pull Requests > > Draft Minutes > > Summary of new and continuing actions [0/9] > > * [ ] QT4CG-052-02: NW to consider how to schedule an "editor's > meeting" > * [ ] QT4CG-052-05: MK to rename the hexBinary-equal function to > binary-equal? > * [ ] QT4CG-052-06: MK to consider the editorial question of > "promotion" for the symmetric relations. > * [ ] QT4CG-055-01: MK to clarify that the return type of the deep > lookup operator is a flat sequence. > * [ ] QT4CG-055-02: DN to open an issue requesting examples of > implausible expressions to clarify the spec > * [ ] QT4CG-056-01: MK to update PR #479 so that it merges cleanly. > * [ ] QT4CG-056-02: MK to update PR #412 so that it merges cleanly. > * [ ] QT4CG-056-03: MK to draft a PR to remove the > function-namespaces feature. > * [ ] QT4CG-056-04: MK to write a proposal for adding a select > attribute to xsl:text > > 1. Administrivia > > 1.1. Roll call [10/11] > > CG gives regrets. > * [X] Reece Dunn (RD) > * [X] Sasha Firsov (SF) > * [ ] Christian Gr¸n (CG) > * [X] Joel Kalvesmaki (JK) > * [X] Michael Kay (MK) > * [X] John Lumley (JL) > * [X] Dimitre Novatchev (DN) > * [X] Wendell Piez (WP) > * [X] Ed Porter (EP) > * [X] C. M. Sperberg-McQueen (MSM) [0:10-] > * [X] Norm Tovey-Walsh (NW). Scribe. Chair. > > 1.2. Accept the agenda > > Proposal: Accept [26]the agenda. > > Accepted. > > 1.2.1. Status so far... > > issues-open-2023-11-28.png > > Figure 1: "Burn down" chart on open issues > > issues-by-spec-2023-11-28.png > > Figure 2: Open issues by specification > > issues-by-type-2023-11-28.png > > Figure 3: Open issues by type > > 1.3. Approve minutes of the previous meeting > > Proposal: Accept [27]the minutes of the previous meeting. > > Accepted. > > 1.4. Next meeting > > The next meeting [28]is scheduled for Tuesday, 5 December 2023. > > Any regrets for the following meeting? > > None heard. > > When are we going to meet over the next few weeks? > * X 5 December (yes) > * X 12 December (yes) > * X 19 December (yes) > * X 26 December (no) > * X 2 January, 2024 (no) > > 1.5. Review of open action items [0/3] > > * [ ] QT4CG-052-02: NW to consider how to schedule an "editor's > meeting" > * [ ] QT4CG-052-05: MK to rename the hexBinary-equal function to > binary-equal? > * [ ] QT4CG-052-06: MK to consider the editorial question of > "promotion" for the symmetric relations. > * [ ] QT4CG-055-01: MK to clarify that the return type of the deep > lookup operator is a flat sequence. > * [ ] QT4CG-055-02: DN to open an issue requesting examples of > implausible expressions to clarify the spec > > 1.6. Review of open pull requests and issues > > 1.6.1. 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 [29]#857: 856 Drop reference to obsolete error condition in > deep-equal() > > Leave it for next week. > > 1.6.2. XSLT focused > > * PR [30]#470: 369: add fixed-prefixes attribute in XSLT > * PR [31]#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 [32]#742: xsl:function-library: keep, drop, or refine? > * Issue [33]#169: Handling of duplicate keys in xsl:map > * Issue [34]#168: XSLT Extension Instructions invoking Named > Templates > > 2. Technical Agenda > > 2.1. PR #470: 369: add fixed-prefixes attribute in XSLT > > See PR [35]#470. > > MK reviews the PR. > * MK: Background is frustration with the number of namespace > declarations that are needed at the start of a stylesheet model. > + ... Coupled with the fact that users would prefer to remove > some of the boilerplate. > + ... There's an internal perspective that if the namespace > bindings in scope change, we have to generate runtime code to > check them even though the chances that they have any effect > is negligible. > + ... Function inlining and ohter optimizations are more > complicated if the namespace bindings change. > + ... Removing unnecessary namespace declarations is useful. > * MK: Proposal begins with a rewrite of the section on XSLT > namespaces. > + ... Native namespace bindings and fixed namespace bindings. > + ... Must appear at the beginning of a model, cannot be changed > in the module. > + ... Uses a pre-defined catalog of shortname to URI mappings. > + ... The stylesheet still has to be conformant with XML > Namespaces. > + ... But in XPath patterns, match patterns, etc. you can use > the fixed ones. > > Mike reviews the details of the changes in the XSLT elements and > attributes. > * MK: The fixed-namespaces attribute defines all of the bindings in > the static context. You can use #standard or a list of short names > or prefix=URI bindings, or a pointer to a document that has the > desired bindings. > + ... The pointer trick lets all sub-modules refer to the > bindings on the main module. > + ... Declaring namespaces in fixed-namespaces has no effect on > runtime execution. There are things that use namespace context > at runtime, for example element constructors. Those have to be > declared the conventional way. Another is casting strings to > QNames. These namespaces aren't going to be carried through to > runtime just in case that happens. > * DN: I greatly support this. It would be very useful. I'm > disappointed that this doesn't have any effect on the stylesheet. I > think the fixed namespaces attribute should default to #standard. > * MK: Yes, you could do that if 4.0 is specified. > * RD: With the type of the fixed name attribute, we should really > specify that more precisely. In the cases where there are a > constant or alist of constants it does things like #default or > prefixes. We should define the things like namespace declaration > that are described separately and unioned against. > + ... Then when defining the schema, define the proper > validation type for it. > * MK: Yes, but I haven't attempted to do that. > * JL: Does this have any effect on namespace-alias? > * MK: No, because that only effects prefixes used in literal result > elements. > * JL: I use a lot of namespace aliasing to generate code. But you > can't get away from declaring the namespace. > + ... You said it had no effect on the runtime. Does that mean > that it implies a discard prefixes setting? > * MK: Yes, these prefixes are excluded automatically. > * NW: Prefix=URI? What about space? Should document that it will be > broken. > * DN: I'm disappointed that this can't apply to the stylesheet > itself. I was hoping it would be a pre-processing step that would > automatically generate the namespaces. When I mentioned XInclude, > that's a kind of pre-processor. I think we have other cases where > we have to think about a general pre-processor for all X-languages. > > Some discussion of how XInclude works. > * SF: I heard that modular development approaches are being > incorporated. But is there a way of controlling the namespaces for > subsequent stylesheets? If a module uses another module, can the > caller override what's used? > * MK: No, it's the other way around. > * SF: But that's the problem I'm highlighting. Many development > scenarios can be simplified if the calling module can push things > downstream. I think that we need support for that. > * MK: I think one of the conflicts here is trying to keep modules as > independent as possible. > * SF: What about modules that are meant to be overridden? > * MK: I agree there are use cases there that this doesn't try to > address. > + ... We already have a problem that a module can refer to > variables and functions that are defined in another module. In > a sense, there's already too much dependency. At least the > namespaces are unambiguous! > * SF: We do have the principles of in/out and out/in control. There > are two sides in this equation. I want to have both. Do you think > that the basic principle of modular development where everything > can be overriden is necessary? > * MK: We have some features that work that way, template overrides > for example. But it makes testing and debugging terribly difficult. > The xs:redefine mechanism introduces the same kinds of problems > into XML Schema. That's why xs:redefine tries to restrict what you > can do and similarly, why packaging in XSLT 3.0 tries to control > what kinds of overrides you can apply. This proposal doesn't > attempt to introduce any new overriding or redefining mechanism. > + ... There are clever tricks you can apply; using a shadow > attribute for the fixed-namespaces attribute, for example. But > the author of the module has to invite you to do that. > * SF: I would like to see the modular practices legitimized. I can > always preprocess things. It would be nice to have more control. > * MK: Declaring the fixed-namespaces attribute to be the value of the > static parameter is something you can do if you want to organize > your workflow that way. > + ... Whether I'd advise people to use that may depend on > experience. > > Proposal: accept this PR. > > Accepted. > > ACTION: MK to update PR #479 so that it merges cleanly. > > 2.2. PR #412: 409, QT4CG-027-01: xsl:next-match > > See PR [36]#412. > * MK: Again, this only effects XSLT. The issue this addresses is that > we now allow template rules to match things by type. That's > particularly designed for processing JSON where you can match maps > by record type. The problem is that the type hierarchy doesn't give > you a strict ordering which means that in xsl:next-match, you can't > just say take the next template rule in the precedence and priority > order. > + ... You have to take the type hierarchy into account and it > doesn't give you a linear order. > + ... In the rules for conflict resolution ß6.5, we change some > of the rules. > > MK reviews the new and udpated rules. > * MK: It won't always give the right answer, it's a heuristic that > often gives the right answer. > + ... There are also new rules for import precedence. > * RD: If I understand this, the xsl:next-match works on the same > element. > * MK: Yes, xsl:next-match says I've applied a template rule, but what > would I have chosen next if I hadn't chosen this one. > * RD: Right, so there's no way for previous rules to be selected > again. > * MK: Yes, there are rules to enforce that it's the same item. > > Proposal: accept this PR. > > Accepted. > > ACTION: MK to update PR #412 so that it merges cleanly. > > 2.3. Issue #742: xsl:function-library: keep, drop, or refine? > > See issue [37]#742. > * MK: This is in the spec, but hasn't been discussed. > + ... I did this in an attempt to reduce the number of > namespaces you need to declare. > + ... I don't now think it's an ideal solution to the problem. > + ... The previous discussion came to the conclusion that this > makes things more complicated. > * MK: I think my proposal is that we drop this. > + ... I'd still like to find a solution to the problem of having > to prefix function names, but I don't think this is it. > * DN: I agree. I think JK's observation about the name is relevant. > For me, clearly the solution is using a separate function > namespaces mechanism. We have good examples of this from other > programming languages. > * MSM: I may be in a minority. This is a solution to a problem that I > don't think is a problem. I do think it should be said, I'm happy > for functions to have namespace prefixes. When I was trying to > learn Java, I found the absence of any notion of where things came > from a constant source of irritation and confusion. > > Propsal: drop this feature. > > Accepted. > > ACTION: MK to draft a PR to remove the function-namespaces feature. > > 2.4. Issue #169: Handling of duplicate keys in xsl:map > > See issue [38]#169. > * MK: This is a fairly minor change that just needs endorsement. > + ... There's a new on-duplicates attribute on xsl:map that > defines what to do when duplicates occur. > + ... The expression on on-duplicates evalutes to a function > that is called when duplicate keys arise. > * DN: Minor question: I don't remember seeing any type restrictions > on this function. Shouldn't its return type be the type of the > expected value type? > * MK: There isn't an expected value type of xsl:map. If you wrap it > in an xsl:variable, there's a check that what you constructed is > appropriate. > > Proposal: Accept this change > > Accepted. Issue #169 reflects the status quo. > > 2.5. Issue #323: add select attribute to xsl:text > > See issue [39]#323. > * MK: Should we do this? It's very similar to xsl:value-of. > * NW: I think that might be worth doing, just for users. > * RD: I like it to. > * DN: Don't we already have a string interpolation? > * NW: Yes, but turning it on and off can be a pain in the neck. > * MK: Should you be able to have child instructions in xsl:text. In > xsl:value-of, you can build the text one instruction at a time and > it concatenates them. But very few people use it. > * RD: Would that confuse the content model of xsl:text. If you mixed > text and element instructions, what would you get? > * MK: That's the rules for constructing simple content. > * DN: I think xsl:text is the simplest possible thing in XSLT and I > think it would not be useful. We're making things more complicated. > Especially taking that there are already other mechnisms. > * WP: I'm on the fence, but one of the original uses of xsl:text is > to insert spaces. Both directions are veering away from the lean > and mean model of xsl:text. That being said, I'm split on the > feature. I see the virtues, but I think DN is making a point. > * RD: I like the consistency of it and the symmetry of it with the > other properties. It can be confusing to a user which instructions > support select and which ones don't. And xsl:text seems like a > better name than xsl:value-of. > > Straw poll: who'd like to see a proposal? > > In favor: 7 or 8. A clear plurality. > * MK: Ok, I'll invest the time to write it. > > ACTION: MK to write a proposal for adding a select attribute to > xsl:text > > 3. Any other business? > > None heard. > > 4. Adjourned > > References > > 1. https://qt4cg.org/meeting/minutes/2023/11-28.html#minutes > 2. https://qt4cg.org/meeting/minutes/2023/11-28.html#new-actions > 3. https://qt4cg.org/meeting/minutes/2023/11-28.html#administrivia > 4. https://qt4cg.org/meeting/minutes/2023/11-28.html#roll-call > 5. https://qt4cg.org/meeting/minutes/2023/11-28.html#agenda > 6. https://qt4cg.org/meeting/minutes/2023/11-28.html#so-far > 7. https://qt4cg.org/meeting/minutes/2023/11-28.html#approve-minutes > 8. https://qt4cg.org/meeting/minutes/2023/11-28.html#next-meeting > 9. https://qt4cg.org/meeting/minutes/2023/11-28.html#open-actions > 10. https://qt4cg.org/meeting/minutes/2023/11-28.html#open-pull-requests > 11. https://qt4cg.org/meeting/minutes/2023/11-28.html#merge-without-discussion > 12. https://qt4cg.org/meeting/minutes/2023/11-28.html#xslt-focused > 13. https://qt4cg.org/meeting/minutes/2023/11-28.html#technical-agenda > 14. https://qt4cg.org/meeting/minutes/2023/11-28.html#pr-470 > 15. https://qt4cg.org/meeting/minutes/2023/11-28.html#pr-412 > 16. https://qt4cg.org/meeting/minutes/2023/11-28.html#iss-742 > 17. https://qt4cg.org/meeting/minutes/2023/11-28.html#iss-169 > 18. https://qt4cg.org/meeting/minutes/2023/11-28.html#iss-323 > 19. https://qt4cg.org/meeting/minutes/2023/11-28.html#any-other-business > 20. https://qt4cg.org/meeting/minutes/2023/11-28.html#adjourned > 21. https://qt4cg.org/meeting/minutes/ > 22. https://qt4cg.org/ > 23. https://qt4cg.org/dashboard > 24. https://github.com/qt4cg/qtspecs/issues > 25. https://github.com/qt4cg/qtspecs/pulls > 26. https://qt4cg.org/meeting/agenda/2023/11-28.html > 27. https://qt4cg.org/meeting/minutes/2023/11-21.html > 28. https://qt4cg.org/meeting/agenda/2023/12-05.html > 29. https://qt4cg.org/dashboard/#pr-857 > 30. https://qt4cg.org/dashboard/#pr-470 > 31. https://qt4cg.org/dashboard/#pr-412 > 32. https://github.com/qt4cg/qtspecs/issues/742 > 33. https://github.com/qt4cg/qtspecs/issues/169 > 34. https://github.com/qt4cg/qtspecs/issues/168 > 35. https://qt4cg.org/dashboard/#pr-470 > 36. https://qt4cg.org/dashboard/#pr-412 > 37. https://github.com/qt4cg/qtspecs/issues/742 > 38. https://github.com/qt4cg/qtspecs/issues/169 > 39. https://github.com/qt4cg/qtspecs/issues/323 > > Be seeing you, > norm > > -- > Norm Tovey-Walsh > Saxonica
Received on Wednesday, 29 November 2023 12:15:44 UTC