- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 28 Nov 2023 17:37:28 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2wmu1u6bg.fsf@saxonica.com>
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