- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 18 Feb 2025 17:48:29 +0000
- To: public-xslt-40@w3.org
Hello,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2025/02-18.html
QT4 CG Meeting 110 Minutes 2025-02-18
[1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
Pull Requests
Table of Contents
* [6]Draft Minutes
* [7]Summary of new and continuing actions [0/10]
* [8]1. Administrivia
+ [9]1.1. Roll call [9/13]
+ [10]1.2. Accept the agenda
o [11]1.2.1. Status so far...
+ [12]1.3. Approve minutes of the previous meeting
+ [13]1.4. Next meeting
+ [14]1.5. Review of open action items [3/6]
+ [15]1.6. Review of open pull requests and issues
o [16]1.6.1. Blocked
o [17]1.6.2. Merge without discussion
o [18]1.6.3. Close without action
o [19]1.6.4. Substantive PRs
* [20]2. Technical agenda
+ [21]2.1. PR #1791: 1789 Fix singleton terminology
+ [22]2.2. PR #1766: 1715 Drop array bound checking
+ [23]2.3. PR #1763: 1716 Generalize syntax of arrow expressions
+ [24]2.4. Issue triage
o [25]2.4.1. Issue #322: Map construction in XSLT:
xsl:record instruction
o [26]2.4.2. Issue #323: add select attribute to xsl:text
o [27]2.4.3. Issue #366: Support xsl:use-package with
xsl:package-location
o [28]2.4.4. Issue #451: Multiple Schemas
o [29]2.4.5. Issue #714: Function annotations in XSLT
* [30]3. Any other business
* [31]4. Adjourned
Draft Minutes
Summary of new and continuing actions [0/10]
* [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-097-02: MK to make the XSD schema component references
into links to XSD
* [ ] QT4CG-107-05: JLO and DN to consider a proposal for system
defined records.
* [ ] QT4CG-110-01: MK to fix the incorrect termrefs in the data
model the merge the PR.
* [ ] QT4CG-110-02: MK to review the error pointed out in one of the
examples for arrow expressions and then merge
* [ ] QT4CG-110-03: JWL to consider writing a PR for issue #322,
xsl:record instruction
* [ ] QT4CG-110-04: JK to consider a PR for #366, xsl:use-package
with xsl:package-location
1. Administrivia
1.1. Roll call [9/13]
Regrets: CG, BTW, SF, JLO
* [X] David J Birnbaum (DB)
* [X] Reece Dunn (RD)
* [ ] Sasha Firsov (SF)
* [ ] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [ ] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [32]the agenda.
Accepted.
1.2.1. Status so far...
These charts have been adjusted so they reflect the preceding six
months of work.
issues-open-2025-02-18.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2025-02-18.png
Figure 2: Open issues by specification
issues-by-type-2025-02-18.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [33]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is planned for 25 February 2025.
1.5. Review of open action items [3/6]
(Items marked [X] are believed to have been closed via email before
this agenda was posted.)
* [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-097-02: MK to make the XSD schema component references
into links to XSD
* [X] QT4CG-107-01: MK to amend PR 1722 so the expansion of focus
functions includes the return type item()*
* [ ] QT4CG-107-05: JLO and DN to consider a proposal for system
defined records.
* [X] QT4CG-109-01: NW add JSON to the processing model diagrams
along side XML
* [X] QT4CG-109-02: NW to look again at adding tooltips to the
diagrams
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 [34]#1587: 557 Add fn:binary-resource
* PR [35]#1296: 982 Rewrite of scan-left and scan-right
* PR [36]#1283: 77b Update expressions
* PR [37]#1062: 150bis revised proposal for fn:ranks
* PR [38]#1227: 150 PR resubmission for fn ranks
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 [39]#1810: 1808 Add -> to list of tokens using lt and gt
characters
* PR [40]#1809: 1807 Two exceptions to the rule, not three
* PR [41]#1806: 1805 Drop middle dots from termref rendition in F+O
* PR [42]#1804: Drop "(Non-Normative)" from ToC
* PR [43]#1802: 1785 Fix two simple grammar bugs
* PR [44]#1790: 1788 Replace statement that maps are unordered
* PR [45]#1769: Add links from processing model diagrams
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 [46]#119: Allow a map's key value to be any sequence
* Issue [47]#1631: xsl:apply-templates (without select) should allow
inline content
Proposal: close without further action.
Accepted.
1.6.4. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
(See below for the PRs that we plan to discuss.)
* PR [48]#1801: Function fn:function-identity
* PR [49]#1791: 1789 Fix singleton terminology
* PR [50]#1778: 1456 Lookup expressions filtered by type
* PR [51]#1766: 1715 Drop array bound checking
* PR [52]#1763: 1716 Generalize syntax of arrow expressions
* PR [53]#1740: 1725b Further elaboration of duplicates handling in
maps
* PR [54]#1735: 1341 Drop $position callback from many functions
2. Technical agenda
2.1. PR #1791: 1789 Fix singleton terminology
See PR [55]#1791.
* MK: There's a typo in the data model that I need to fix; some of
the termrefs are expanded incorrectly.
* MK: Briefly: we use single-entry map and single-entry array instead
of "singleton" to avoid confusion.
* JWL: Do we need to be able to describe "optional singleton"?
* MK: I didn't see that.
Proposal: accept this PR.
Accepted.
ACTION: QT4CG-110-01: MK to fix the incorrect termrefs in the data
model the merge the PR.
2.2. PR #1766: 1715 Drop array bound checking
See PR [56]#1766.
* MK: This takes the fairly radical approach that you no longer get
an error if the array bounds are out-of-bounds, you get an empty
sequence.
+ ... If adds a new function array:get-if-present that raises an
error.
+ ... This was necessary because deep lookup fails all over the
place if you do bounds checking. And it's consistent with what
we do elsewhere, with maps for example.
* NW: CG asked me to remind us of his comment that head() and other
functions should have consistent behavior.
* MK: I think I agree, but I was hesitant to take it that far.
* DN: Is my understanding correct that this turning off of array
bounds checking is permanent.
* MK: Yes, there's no switch or mode for it. There's a function that
does array lookup with bounds checking.
* DN: What about an existing application that relies on bounds
checking and uses try/catch?
* MK: Those will break. That's why I introduced this as something
that users might not be comfortable with.
* DN: I think we should have a switch for this. And do I understand
that an empty sequence is returned?
* MK: Yes.
* DN: That seems very wrong to me; an empty sequence is a completely
valid return value.
* MK: It makes it consistent with maps where the same ambiguity
exists. If you need to disambiguate, you have to make an extra
test.
* DN: We should consider the alternative where we can turn this
checking on or off. Otherwise, I won't know what to expect when I
get an empty sequence as a result.
* JWL: Are there any grounds for doing a similar thing on the binary
accessor functions? We do the equivalent of bounds checking there.
* MK: I hadn't considered that.
* JWL: Might be worth considering for consistency.
* RD: I found a global mechanism like a declare statement in XQuery
to be problematic with respect to a feature. In an import chain,
you can end up with one module that wants one behavior and another
module that wants different behavior. Or you can get unexpected
behavior because a parent model declares a particular behavior. In
MarkLogic, this presents itself as a problem with feature
extensions.
* MK: Yes, and context switches make some things harder like function
inlining.
* DB: Doesn't the new array:get-if-present provide an opportunity to
build the switching into the code instead of an instruction?
* MK: Unfortunately, it doesn't handle all cases, like a deep lookup
for example. Or direct subscripting.
* WP: Practically, what is the impact and can we know? Are there
people who would be impacted, or is it a small constituency that
could easily adapt.
* MK: We know so little about the broader user community is that it's
hard to tell.
* WP: Can we ask? This seems like a good idea, except for this issue.
* MK: Assessing the impact of change on the user community is
something we have no way of quantifying. But it's often larger than
you imagine.
+ ... In some ways, it's not that it will cost a lot of money,
it's that they won't move forward if they've heard bad
stories.
* DN: Two things: if we approve this, we will be destroying backward
compatibility. And with respect to the user community, we don't
know how long users will continue to use version 3 and they will be
disappointed when they try to switch. I'm very much opposed to
this.
+ ... I think the right way is to allow users to turn this
feature on and off. That's how C# does it. We should look at
what other languages do.
+ ... We have several ways to access arrays; maybe we could make
array bounds checking apply to some, not others. Or we could
add a new operator.
* JWL: CG remarked that he went through his entire code base and
found no examples of anyone checking for that error.
* MK: There's even an incompatibility without the try/catch, users
might be relying on the bounds checking to abort their query.
* DN: This reminds me of a proposal I made a few years ago for maps:
the ability to specify what value or behavior should be returned or
occur if the bounds is out of range.
* MK: Yes, except that when you get arrays by parsing JSON, it's hard
to know where to put that function.
* DN: Who cares about JSON, we're talking about XPath.
* RD: The parse JSON case doesn't matter because that's serializing
the JSON into an array. It's not accessing the element of the
array.
* MK: Yes, but if the array has a property that says what it's
default value is, where would you get it from?
Some discussion of a context switch.
* DB: As I look at the proposal, it looks as if we'd be changing the
behavior of array:get and adding a new function. Would adding
array:get-or-else work?
* MK: The big problems are using an array as a function and the
lookup operator. The problem really arises when your working on a
lot of arrays. You don't want to look at them programmatically. In
a deep lookup, you just want ignore the things that aren't there.
+ ... It's very messy if you write an expression that involves
both deep and shallow lookup.
* RD: The fallback on array:get does that, so what value would this
proposal add?
+ ... In the places where we don't have a fallback, we should
add one for consistency. And then we remain backwards
compatible.
* MK: I think that fallback option is very unsatisfactory because it
bloats your code if you have to put it in everytime you want to use
a method.
* DN: I think that what RD says is a good possibility. We could also
have something (a function or notation) that says we're doing a
deep lookup that automatically turns off bounds checking. Or maybe
for this case, to be able to specify the default value that's
returned if the index or key is not present.
+ ... I agree with MK that we need to consider the options.
Leaving this open
2.3. PR #1763: 1716 Generalize syntax of arrow expressions
See PR [57]#1763.
* MK: This was an idea of Gunther Rademacher's and I'm amazed it
works.
MK reviews the grammar changes.
* MK: Basically, you can have any dynamic function call on the right
hand side of the arrow. Mostly this deletes code which must be a
good thing.
* RD: Which dynamic function calls does this allow?
* MK: Any. Any dynamic function call.
* RD: I mean compared to the old behavior.
* MK: In the past it had to be a variable reference or an expression
in parenthesis or an inline function.
+ ... I think you could write any dynamic function call provided
you put it in brackets.
* RD: We now have any postfix expression.
* DN: I think we should add an example of something that was not
previously allowed.
* JWL: So we have three arrows.
Proposal: accept this PR.
Accepted.
ACTION: QT4CG-110-02: MK to review the error pointed out in one of the
examples for arrow expressions and then merge
2.4. Issue triage
The plan this week was to focus on open XSLT issues that had not been
triaged. Since there are no such issues this week, I've put the
`optional' ones back on the list. There was a request to review several
these again.
For this week, please focus your attention on these issues:
2.4.1. Issue [58]#322: Map construction in XSLT: xsl:record instruction
* MK: It's a nice to have.
* JWL: Is it easy? Is it just a source level transformation?
* MK: Yes, I think it's just more concise syntax for something you
can already do.
* RD: What you're doing is mapping the third code block into the
first.
* MK: There are a few decisions to be made about what to do with
namespaced attributes and such. But it's not difficult.
Leave it optional.
ACTION: QT4CG-110-03: JWL to consider writing a PR for issue #322
2.4.2. Issue [59]#323: add select attribute to xsl:text
* JK: If there's a category between "optional" and "required", I'd
put it there.
* MK: Yes, but it's very, very hard to get rid of perceptions and
habits that have been around for twenty years. It's hard to provide
a new feature that will change community habits.
* WP: This doesn't force anyone to change?
+ ... Liam's observation was that people do this by mistake and
get into trouble.
* JWL: Shall we make it required?
* MK: I think it doesn't rise to that level.
Leave it optional.
2.4.3. Issue [60]#366: Support xsl:use-package with xsl:package-location
* MK: I think this comes close to being required. People are having a
lot of trouble using packages without this feature. You can't use
packages in some APIs because there's no where in those APIs to
provide that information.
+ ... The aim was to make the stylesheets not location
dependent, but that's also problematic.
Leave it optional.
ACTION: QT4CG-110-04: JK to consider a PR for #366, xsl:use-package
with xsl:package-location
2.4.4. Issue [61]#451: Multiple Schemas
* MK: I think this is a nice-to-have. You can't write a
transformation that transforms from one schema to another where you
validate the input and output against the schemas.
+ ... I have all the ideas in my head, but it needs a bit of
work.
Leave it optional.
2.4.5. Issue [62]#714: Function annotations in XSLT
* MK: There's an issue on annotations that they're only half-baked.
We could do better.
* JK: I'd say that because function annotations are a new feature of
4.0 XPath, I think this should be required.
Make it required.
3. Any other business
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/
2. https://qt4cg.org/
3. https://qt4cg.org/dashboard
4. https://github.com/qt4cg/qtspecs/issues
5. https://github.com/qt4cg/qtspecs/pulls
6. https://qt4cg.org/meeting/minutes/2025/02-18.html#minutes
7. https://qt4cg.org/meeting/minutes/2025/02-18.html#new-actions
8. https://qt4cg.org/meeting/minutes/2025/02-18.html#administrivia
9. https://qt4cg.org/meeting/minutes/2025/02-18.html#roll-call
10. https://qt4cg.org/meeting/minutes/2025/02-18.html#agenda
11. https://qt4cg.org/meeting/minutes/2025/02-18.html#so-far
12. https://qt4cg.org/meeting/minutes/2025/02-18.html#approve-minutes
13. https://qt4cg.org/meeting/minutes/2025/02-18.html#next-meeting
14. https://qt4cg.org/meeting/minutes/2025/02-18.html#open-actions
15. https://qt4cg.org/meeting/minutes/2025/02-18.html#open-pull-requests
16. https://qt4cg.org/meeting/minutes/2025/02-18.html#blocked
17. https://qt4cg.org/meeting/minutes/2025/02-18.html#merge-without-discussion
18. https://qt4cg.org/meeting/minutes/2025/02-18.html#close-without-action
19. https://qt4cg.org/meeting/minutes/2025/02-18.html#substantive
20. https://qt4cg.org/meeting/minutes/2025/02-18.html#technical-agenda
21. https://qt4cg.org/meeting/minutes/2025/02-18.html#pr-1791
22. https://qt4cg.org/meeting/minutes/2025/02-18.html#pr-1766
23. https://qt4cg.org/meeting/minutes/2025/02-18.html#pr-1763
24. https://qt4cg.org/meeting/minutes/2025/02-18.html#issue-triage
25. https://qt4cg.org/meeting/minutes/2025/02-18.html#h-0664C228-A723-42E4-95F8-CAABF24CA041
26. https://qt4cg.org/meeting/minutes/2025/02-18.html#h-9D109EB1-D2B9-465C-9D6E-D66E04ABD37F
27. https://qt4cg.org/meeting/minutes/2025/02-18.html#h-B3100951-4B76-4D09-A0CE-51F242F5B901
28. https://qt4cg.org/meeting/minutes/2025/02-18.html#h-FE6D972A-FFE4-4BBF-A56F-4D1E0E8E6D3A
29. https://qt4cg.org/meeting/minutes/2025/02-18.html#h-4E040A83-065C-4108-8910-F4158014C775
30. https://qt4cg.org/meeting/minutes/2025/02-18.html#any-other-business
31. https://qt4cg.org/meeting/minutes/2025/02-18.html#adjourned
32. https://qt4cg.org/meeting/agenda/2025/02-18.html
33. https://qt4cg.org/meeting/minutes/2025/02-11.html
34. https://qt4cg.org/dashboard/#pr-1587
35. https://qt4cg.org/dashboard/#pr-1296
36. https://qt4cg.org/dashboard/#pr-1283
37. https://qt4cg.org/dashboard/#pr-1062
38. https://qt4cg.org/dashboard/#pr-1227
39. https://qt4cg.org/dashboard/#pr-1810
40. https://qt4cg.org/dashboard/#pr-1809
41. https://qt4cg.org/dashboard/#pr-1806
42. https://qt4cg.org/dashboard/#pr-1804
43. https://qt4cg.org/dashboard/#pr-1802
44. https://qt4cg.org/dashboard/#pr-1790
45. https://qt4cg.org/dashboard/#pr-1769
46. https://github.com/qt4cg/qtspecs/issues/119
47. https://qt4cg.org/dashboard/#pr-1631
48. https://qt4cg.org/dashboard/#pr-1801
49. https://qt4cg.org/dashboard/#pr-1791
50. https://qt4cg.org/dashboard/#pr-1778
51. https://qt4cg.org/dashboard/#pr-1766
52. https://qt4cg.org/dashboard/#pr-1763
53. https://qt4cg.org/dashboard/#pr-1740
54. https://qt4cg.org/dashboard/#pr-1735
55. https://qt4cg.org/dashboard/#pr-1791
56. https://qt4cg.org/dashboard/#pr-1766
57. https://qt4cg.org/dashboard/#pr-1763
58. https://github.com/qt4cg/qtspecs/issues/322
59. https://github.com/qt4cg/qtspecs/issues/323
60. https://github.com/qt4cg/qtspecs/issues/366
61. https://github.com/qt4cg/qtspecs/issues/451
62. https://github.com/qt4cg/qtspecs/issues/714
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 18 February 2025 17:48:37 UTC