QT4CG Draft Minutes 056, 28 November 2023 (XSLT-focused)

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 Tuesday, 28 November 2023 17:38:21 UTC