- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 25 Jun 2024 17:29:29 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2o77pugt2.fsf@saxonica.com>
Hello,
Here are today’s minutes:
https://qt4cg.org/meeting/minutes/2024/06-25.html
QT4 CG Meeting 083 Minutes 2024-06-25
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [1/6]
* [3]1. Administrivia
+ [4]1.1. Roll call [11/12]
+ [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 [15/18]
+ [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. Substantive PRs
* [14]2. Technical Agenda
+ [15]2.1. PR #1296: 982 Rewrite of scan-left and scan-right
+ [16]2.2. PR #1295: 1096 Redefine array:index-of to use
deep-equal for comparisons
+ [17]2.3. PR #1294: 46 Add xsl:item and xsl:sequence/@as
+ [18]2.4. PR #1290: Fix keyword tests to treat "fn" =
"function"
+ [19]2.5. PR #1288: 1287 Define parse-xml error conditions
+ [20]2.6. PR #1286: Updated list of incompatibilities in F+O
+ [21]2.7. PR #1282: Revise fn:invisible-xml
+ [22]2.8. PR #1262: 1160 Add collation-available() function
* [23]3. Any other business
* [24]4. Adjourned
[25]Meeting index / [26]QT4CG.org / [27]Dashboard / [28]GH Issues /
[29]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [1/6]
* [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
* [ ] QT4CG-080-05: NW to add absolute property to the parse-uri
output
* [ ] QT4CG-080-07: NW to update the build instructions in the README
* [X] QT4CG-082-01: JLO to raise an issue about what to do when
validation is requested but not possible.
+ Overtaken by [30]#1288
* [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-083-01 MK to revise fn:collation-available to address
multiple usages
1. Administrivia
1.1. Roll call [11/12]
CG gives regrets.
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF) [x:10-]
* [ ] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JLY)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [X] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [31]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2024-06-25.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-06-25.png
Figure 2: Open issues by specification
issues-by-type-2024-06-25.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [32]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
This next meeting is planned for 2 July.
1.5. Review of open action items [15/18]
* [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
* [ ] QT4CG-080-05: NW to add absolute property to the parse-uri
output
* [ ] QT4CG-080-07: NW to update the build instructions in the README
* [ ] QT4CG-082-01: JLO to raise an issue about what to do when
validation is requested but not possible.
* [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal
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 [33]#1297: Minor correction to fn:scan-right - typo
* PR [34]#1231: 1193 Parsing Functions: Empty input
* PR [35]#1227: 150 PR resubmission for fn ranks
* PR [36]#1062: 150bis - revised proposal for fn:ranks
* PR [37]#832: 77 Lookup returning path selection
* PR [38]#529: 528 fn:elements-to-maps
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]#1292: Fix issue 1291 (rounding)
* PR [40]#1255: 1253 whitespace in xsl:switch
Proposal: Merge without discussion.
Accepted.
1.6.3. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [41]#1296: 982 Rewrite of scan-left and scan-right
* PR [42]#1295: 1096 Redefine array:index-of to use deep-equal for
comparisons
* PR [43]#1294: 46 Add xsl:item and xsl:sequence/@as
* PR [44]#1293: 1289 Delete XQuery Appendix J
* PR [45]#1290: Fix keyword tests to treat "fn" = "function"
* PR [46]#1288: 1287 Define parse-xml error conditions
* PR [47]#1286: Updated list of incompatibilities in F+O
* PR [48]#1283: 77b: Update expressions
* PR [49]#1282: Revise fn:invisible-xml
* PR [50]#1266: 1158 Add array mapping operator
* PR [51]#1265: 1161 Further revision of document-uri constraints
* PR [52]#1263: 1224 Add xsl:accumulator-rule/@priority attribute
* PR [53]#1262: 1160 Add collation-available() function
* PR [54]#1255: 1253 whitespace in xsl:switch
* PR [55]#1254: 729 Add rules for use of xsi:schemaLocation during
validation
* PR [56]#1244: 566-partial Rewrite parse-uri
* PR [57]#1228: - Adding the BLAKE3 hashing algorithm to fn:hash
* PR [58]#1209: 1183 Add transient mode and the transient{}
expression
* PR [59]#1185: 1179 array:values, map:values -> array:get, map:get
2. Technical Agenda
2.1. PR #1296: 982 Rewrite of scan-left and scan-right
* PR [60]#1296: 982 Rewrite of scan-left and scan-right
* MK: DN and I went separate ways, but let's look at the current
proposal which I revised in light of DN comments. MK: The
substantive part of the issue is that the two functions were
inconsistent with other functions wrt the position parameter.
+ ... I tried to add one, and in the process, discovered that
fold-left and fold-right were specified incorrectly.
+ ... So I took the other approach and removed the position
argument from all of them.
MK discovers that the PR doesn't contain the latest version. We'll
leave it for a week.
* DN: I applaud the decision to remove the position parameter.
2.2. PR #1295: 1096 Redefine array:index-of to use deep-equal for comparisons
* PR [61]#1295: 1096 Redefine array:index-of to use deep-equal for
comparisons
* MK: This is an issue that I raised. The original topic was that
array:index-of as an accident of the way it was specified atomized
one argument but not another. That gave some unexpected behaviors.
+ ... That lead to a long discussion. There was a strong desire
to have something parallel to sequence indexing.
+ ... The proposal I've come up with is that we define
array:index-of using fn:deep-equal.
+ ... I'd support deleting the function entirely, but at least
this is simple and consistent.
* DN: I'm pleased to see that collation is the last parameter.
Probably a sequence of collations is necessary. If the member of
the array contains strings in different collations, then you'll
need different collations for the comparisons.
* MK: That sounds pretty radical. I think if you want that degree of
sophistication, you have to do it by hand.
* DN: One collation isn't sufficient if you have a sequence of
strings in different collations.
Some discussion of whether or not this is a problem that needs to be
solved.
* MSM: On the topic of collations of properties of strings; that was
not only proposed for 2.0, it was also proposed for XSD. The I18N
group objected strenuously. I didn't find the arguments especially
persuasive, but the W3C did. It's clear that many people with
experience in internationalization would object to that. I think we
shouldn't go there.
Proposal: Accept this PR.
Accepted.
2.3. PR #1294: 46 Add xsl:item and xsl:sequence/@as
* PR [62]#1294: 46 Add xsl:item and xsl:sequence/@as
* MK: This takes a number of issues raise separately and attempts to
address them all.
+ ... The xsl:item is designed to avoid the xsl:sequence when
you know the item is going to be a singleton.
+ ... Adding an as attribute lets you use stronger type checking
and more self-documenting code.
+ ... The xsl:item instruction must return a single item, not a
sequence or empty sequence.
* DN: I thought XSLT 3.0 was already too large. Now I'm seeing
something that I don't think needs to be done. An item is a kind of
sequence. Why do we need a separate instruction? There may be
alternatives, we could add an attribute to xsl:sequence for
example.
+ ... I think XSLT has become an ocean of different things and
they aren't totally exclusive. I get lost trying to determine
which things I should use and when. Are we going to eventually
get xsl:* everything in the dictionary?
* MSM: Relating to cardinality, if the difference between item and
sequence is that item has fixed cardinality, then thinking about
systems I have used, and the decision about the empty sequence, I
would like to be able to specify empty-or-a-singleton and
singleton. I think the as attribute on xsl:sequence would let me do
that.
* MK: Yes.
* MSM: FWIW, I think I'm neutral on whether adding xsl:item is useful
enough to justify it.
* JLY: Similar thoughts to MSM. You have a problem that if it might
be empty, I have to use xsl:sequence. If I know it's exactly one, I
can use xsl:item. If I know there might be more than one, I have to
use xsl:sequence again. And you can do it all with xsl:sequence
using as.
* MK: Where this is coming from is that people find it more natural
to write xsl:value-of which has exactly the wrong semantics.
* JLY: Yes. Maybe getting rid of xsl:value-of would be nice.
* RD: In terms of cardinality, there are four choices. Could we do
this with a required attribute.
* MK: Yes, I thought the same thing, you could add optional=true.
* RD: It would make sense required by default and sequence optional
by default. That's probably what most people would want. Does that
solve the problem?
* MK: I don't think you need anything on sequence because you can use
as. You could allow ? on an as attribute on xsl:item.
* JK: The motivation for as seems to be that anything with a select
should have an as. What problem are we solving?
* MK: I must admit, adding as to xsl:sequence which defines the
result of the expression. At the moment we only have as on places
where you're defining an API. This does open the way a little bit
for demanding an as attribute in many more places.
* RD: How about anywhere there's a select?
* MK: Well, xsl:attribute and xsl:processing-instruction have a
select attribute and it would be overkill there.
+ ... An as attribute changes the behavior.
* MSM: Since I find that the only reason for me not to use as
whenever I think about it is to delay errors until production! I
can easily imagine wanting an as attribute on xsl:attribute if I
want to specify something about the attribute type.
+ ... The same is true of specifying the target of a processing
instruction.
+ ... The extent to which this might change the behavior could
be worrisome. I do find something appealing that says if it
has a select you can have an as. It's a little bit like making
a particular form of assertion cheap and easy to express.
+ ... If we decide to allow xsl:item to be optional, I really
hate the idea of having an optional or required attribute. I'd
much rather have it be a ? in the as.
* WP: What I'm hearing is that the problem is xsl:value-of which also
has select. On balance, I think this addresses a very narrow
concern with some users. I know plenty of people who like
xsl:sequence and select because of the flexibility.
* JLY: If you put as on an xsl:item type, then it will be the on as
attribute that has different semantics. You can't put a + or * in
those places.
* NW: We're not coming to consensus here.
* MK: I could split it. Or we could drop it.
* MSM: I had the impression that adding as on select had positive to
neutral reactions and much of the complication was xsl:item.
Straw poll: separate the proposals or drop the whole thing?
Separate proposals: 7. Drop: 1. Abstaining: 1.
MK will revise PR as he thinks most appropriate.
2.4. PR #1290: Fix keyword tests to treat "fn" = "function"
* PR [63]#1290: Fix keyword tests to treat "fn" = "function"
Stylesheet only fix. Not discussed. MK: merge it!
2.5. PR #1288: 1287 Define parse-xml error conditions
* PR [64]#1288: 1287 Define parse-xml error conditions
* MK introduces the proposed error conditions for parsing XML.
* JLO: That completes my action! Thank you. I like the dynamic error
for DTD validation, but I'm wondering why FODC0007 is the same for
either DTD or XSD validation.
Some support for having two different error codes.
* DN: What is the meaning of FODC0008? Is it a GUID or something?
* MK: No, the form of the error identifiers was introduced by Andrew
Eisenberg and kept with the IBM tradition of 8 character names.
Some discussion of the semantics of the names.
Proposal: Accept this PR with the amendment that there should be two
different error codes for DTD and Schema validation errors.
MK to merge after updating.
2.6. PR #1286: Updated list of incompatibilities in F+O
* PR [65]#1286: Updated list of incompatibilities in F+O
* MK: We changed the rules on the options parameter. If you use a
parameter that isn't recognized. That's a backwards
incompatibility. I added that to the appendix.
Proposal: accept this PR.
Accepted.
2.7. PR #1282: Revise fn:invisible-xml
* PR [66]#1282: Revise fn:invisible-xml
* NW explains the changes.
Proposal: Accept this PR.
Accepted.
2.8. PR #1262: 1160 Add collation-available() function
* PR [67]#1262: 1160 Add collation-available() function
* MK: This changes the semantics of fn:collation. It now generates
the string but the error is raised by fn:collation-available()
+ ... The only interesting thing about fn:collation-available()
is the usage parameter. There are three different reasons why
you might want a collation and which collations might be
available for each reason differs.
* JLO: I like this. I like the usage parameter. My question is why
can't I do a collation available for all of them? Suppose I want to
use all three? Also: where you are using fn:collation-available()
which usage is there?
* MK: No fn:collation() just builds the string. This function asks if
it's usable.
+ ... I guess we could allow a sequence of enums.
* DN: We need something like union for the different usages. My
observation was that we probably could just have a single function,
fn:collation() and have it return an empty sequence if no such
collation is available.
* MK: The fn:collation function can only be used to build UCA
collations, but this function can be applied to any collation.
Some discussion of the UCA vs. vendor defined collations.
* JLY: Originally, collation would form the collation and error if it
coudln't. So the assumption now is that if you run it without
checking the collection, the error will occur downstream.
ACTION: QT4CG-083-01 MK to revise fn:collation-available to address
multiple usages
* DN: Even if we have usage specified, it doesn't prevent the user
from using it in another usage. That's probably not something we
can address statically. That raises questions about the usability
of the usage parameter.
* MK: This function doesn't stop any existing code from working, it
gives the user the ability to avoid the error.
3. Any other business
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/06-25.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/06-25.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/06-25.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/06-25.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/06-25.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/06-25.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/06-25.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/06-25.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/06-25.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/06-25.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/06-25.html#blocked
12. https://qt4cg.org/meeting/minutes/2024/06-25.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2024/06-25.html#substantive
14. https://qt4cg.org/meeting/minutes/2024/06-25.html#technical-agenda
15. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1296
16. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1295
17. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1294
18. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1290
19. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1288
20. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1286
21. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1282
22. https://qt4cg.org/meeting/minutes/2024/06-25.html#pr-1262
23. https://qt4cg.org/meeting/minutes/2024/06-25.html#any-other-business
24. https://qt4cg.org/meeting/minutes/2024/06-25.html#adjourned
25. https://qt4cg.org/meeting/minutes/
26. https://qt4cg.org/
27. https://qt4cg.org/dashboard
28. https://github.com/qt4cg/qtspecs/issues
29. https://github.com/qt4cg/qtspecs/pulls
30. https://qt4cg.org/dashboard/#pr-1288
31. https://qt4cg.org/meeting/agenda/2024/06-25.html
32. https://qt4cg.org/meeting/minutes/2024/06-18.html
33. https://qt4cg.org/dashboard/#pr-1297
34. https://qt4cg.org/dashboard/#pr-1231
35. https://qt4cg.org/dashboard/#pr-1227
36. https://qt4cg.org/dashboard/#pr-1062
37. https://qt4cg.org/dashboard/#pr-832
38. https://qt4cg.org/dashboard/#pr-529
39. https://qt4cg.org/dashboard/#pr-1292
40. https://qt4cg.org/dashboard/#pr-1255
41. https://qt4cg.org/dashboard/#pr-1296
42. https://qt4cg.org/dashboard/#pr-1295
43. https://qt4cg.org/dashboard/#pr-1294
44. https://qt4cg.org/dashboard/#pr-1293
45. https://qt4cg.org/dashboard/#pr-1290
46. https://qt4cg.org/dashboard/#pr-1288
47. https://qt4cg.org/dashboard/#pr-1286
48. https://qt4cg.org/dashboard/#pr-1283
49. https://qt4cg.org/dashboard/#pr-1282
50. https://qt4cg.org/dashboard/#pr-1266
51. https://qt4cg.org/dashboard/#pr-1265
52. https://qt4cg.org/dashboard/#pr-1263
53. https://qt4cg.org/dashboard/#pr-1262
54. https://qt4cg.org/dashboard/#pr-1255
55. https://qt4cg.org/dashboard/#pr-1254
56. https://qt4cg.org/dashboard/#pr-1244
57. https://qt4cg.org/dashboard/#pr-1228
58. https://qt4cg.org/dashboard/#pr-1209
59. https://qt4cg.org/dashboard/#pr-1185
60. https://qt4cg.org/dashboard/#pr-1296
61. https://qt4cg.org/dashboard/#pr-1295
62. https://qt4cg.org/dashboard/#pr-1294
63. https://qt4cg.org/dashboard/#pr-1290
64. https://qt4cg.org/dashboard/#pr-1288
65. https://qt4cg.org/dashboard/#pr-1286
66. https://qt4cg.org/dashboard/#pr-1282
67. https://qt4cg.org/dashboard/#pr-1262
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 25 June 2024 16:29:37 UTC