- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 05 Mar 2024 17:28:30 +0000
- To: "public-xslt-40@w3.org" <public-xslt-40@w3.org>
- Message-ID: <m2zfvca8pc.fsf@saxonica.com>
Hello,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2024/03-05.html
QT4 CG Meeting 068 Minutes 2024-03-05
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/4]
* [3]1. Administrivia
+ [4]1.1. Roll call [11/13]
+ [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 [8/12]
+ [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. Close without action
* [14]2. Technical Agenda
+ [15]2.1. Review of blocked PRs
+ [16]2.2. PR #1053: 1047 Default predicate for some#1 and
every#1
+ [17]2.3. PR #1049: 340-partial fn:format-number: Specifying
decimal format
+ [18]2.4. PR #1027: 150 fn:ranks
+ [19]2.5. PR #832: 77 Add map:deep-update and array:deep-update
* [20]3. Any other business
* [21]4. Adjourned
[22]Meeting index / [23]QT4CG.org / [24]Dashboard / [25]GH Issues /
[26]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [0/4]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [ ] QT4CG-063-04: NW to try to add test review to the editorial
meeting.
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [ ] QT4CG-064-08: NW to open an issue to try to resolve $search to
$target consistently.
1. Administrivia
1.1. Roll call [11/13]
Regrets DN.
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF) [-:30]
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JLY)
* [ ] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [ ] Adam Retter (AR) [:10-]
* [X] C. M. Sperberg-McQueen (MSM) [:10-]
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [27]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2024-03-05.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-03-05.png
Figure 2: Open issues by specification
issues-by-type-2024-03-05.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [28]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [29]is scheduled for Tuesday, 12 March 2024.
Any regrets for the next meeting?
Beware that the US switches to daylight saving time before the next
meeting.
1.5. Review of open action items [8/12]
* [ ] QT4CG-052-02: NW to consider how to schedule an "editor's
meeting"
* [X] QT4CG-056-04: MK to write a proposal for adding a select
attribute to xsl:text
+ This action can be tracked with issue #323
* [X] QT4CG-058-02: MK to consider providing more advice about the
pitfalls of mixing decimal and double when sorting
+ Discharged by raising issue #986
* [X] QT4CG-063-01: MK to revise #956 especially with respect to the
options parameter
+ PR is still marked "revise", this action is no longer
necessary
* [X] QT4CG-063-02: JK to consider whether the roman numeral example
is appropriate for the spec.
+ On consideration, no it probably wouldn't be helpful
* [ ] QT4CG-063-04: NW to try to add test review to the editorial
meeting.
* [X] QT4CG-063-05: MK to revise PR #953 to take account of CG's
comments
+ Work ongoing, but this action has been overtaken by events
* [ ] QT4CG-063-06: MK to consider refactoring the declare item type
syntax to something like declare record
* [ ] QT4CG-064-08: NW to open an issue to try to resolve $search to
$target consistently.
* [X] QT4CG-066-01: MK to add a note that the grammar rules for
regular expressions apply after comments are removed
* [X] QT4CG-067-01: NW to ask the XML Prague organizers for hosting
* [X] QT4CG-067-02: MK to revert the changes to the test suite for
EBV (PR 1003)
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 [30]#956: 850-partial Editorial improvements to parse-html()
* PR [31]#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 [32]#1051: 1043 Clarification of CSV edge cases
* PR [33]#1046: 1038 take-while predicate no longer uses EBV
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 [34]#1017: Change csv-to-xml() to produce an XHTML table
* Issue [35]#825: array:members-at
* Issue [36]#413: New function: parse-csv()
2. Technical Agenda
2.1. Review of blocked PRs
What's the status on these?
* PR [37]#956: 850-partial Editorial improvements to parse-html()
* PR [38]#529: 528 fn:elements-to-maps
MK reports: They're both mine; I'm aware of them. I've been working on
more interesting things. I will get back to them.
2.2. PR #1053: 1047 Default predicate for some#1 and every#1
See PR [39]#1053
MK reviews the PR.
* MK: Because of function coercion, fn:identity gets coerced and that
made some of the prose incorrect. CG's suggestion of using
boolean#1 fixes that.
Proposal: accept this PR.
Accepted.
2.3. PR #1049: 340-partial fn:format-number: Specifying decimal format
See PR [40]#1049
CG reviews the PR starting with the original issue.
* CG: The fn:format-number function works well for English numbers,
but you have to add a decimal format to the prolog for German
numbers.
+ ... The intent is to make this simpler. The first step is the
ability to include the decimal format inside the function (as
a map).
+ ... The next step is to allow a user to specify the language.
* CG reviews the spec changes.
* CG: Is an implementation allowed to provide predefined decimal
formats for languages?
+ ... Java already makes this easy.
* JLY: If that map contains an arbitrary value that isn't meaningful,
is that an error?
* CG: It should be. The same rules should apply that apply to the
prolog.
* JK: I think this is a good improvement. Did you consider
introducing an options map so that we can just add more things
later?
* CG: No, but we could.
* JK: I remember think that there was something I wanted to add.
* MK: Related to that is the question of whether the option
conventions apply: atomization, etc.
* JLO: Would it make sense for the name-format to be specified here,
or should we reference some other spec normatively. So, for
example, de means the same thing across implementations.
* CG: It's an interesting question. But I think the existing rules
are only recommendations.
* MK: Yes. Generally in XQuery, the static context is implementation
defined. But do we prescribe what "format=de" means?
+ ... I think we can't because there are so many languages.
* RD: I was going to suggest referencing the [41]Unicode Common
Locale Data Repository (CLDR) that has recommendations for all of
the languages in Unicode and some variants.
+ ... That's where libraries like Java and ICU get their data
from.
+ ... We can say that implementations should use the common
locale registry.
+ ... We could go further and say that "-" corresponds to the
character with the "minus" property in CLDR.
* JLO: That was my idea too.
* MK: Traditionally the default for minus has been hyphen, but it's
probably better to use the Unicode "minus" character. That's a
technical decision.
* RD: Using the CLDR, it's all standardized in libraries.
* MK: But it's not good at decisions like that which are at least
partly typographic.
* CG: You can still override all of the choices.
* JLY: What happens when you try round-tripping one of these?
* MK: In general it fails.
* CG: You need to extend parse integer.
* NW: I found $format-name and $format confusing.
* MK: I tripped over the same thing in the paragraphs.
* NW: CG's original question was, can you define "de" to mean
something specific.
* MK: Yes, I think you can. At least in XQuery, probably not in XSLT.
Proposal: accept this PR.
Accepted. (CG to merge after one editorial change.)
2.4. PR #1027: 150 fn:ranks
See PR [42]#1027
Defer until DN is available.
2.5. PR #832: 77 Add map:deep-update and array:deep-update
See PR [43]#832
MK introduces the discussion.
* MK: I think this is now a fairly complete and viable spec; but I
don't really expect it to be accepted without discussion of
alternatives.
+ ... It's XQuery only which is one of the things we might like
to discuss.
+ ... We start in 4.14.5 Update Expressions. I've replaced HoF
with custom syntax.
+ ... The only reason we have map or array there is to
disambiguate the grammar.
MK walks through the prose of the spec.
* MK: It turns out that the syntax is fairly intuitive but the
underlying semantics are horrendous!
+ ... You have to make a small pipeline if you're making
multiple updates; does that need more semantics to make it
easier?
MK walks through the rather hairy semantics.
* MK: There's an open question about whether the new values still has
the labels; it probably shouldn't.
* RD: In previous version of XQuery, there was the update facility
extension module. That was separate from the core specification.
That defines things like insert/delete/replace/rename, etc. on
nodes. My question is, is this syntax the remit of that
specification, or if we're adding this into the core, does that
mean it would make sense to incorporate modification on nodes as
well.
* MK: All good questions. The first thing to point out is that XQuery
Update has an enormous amount of machinery in place to make sure
the updates can't be seen while they're in progress, except for the
copy-modify expression.
+ ... If anything, this is similar to the copy-modify expression
but it doesn't use anything like the pending update lists.
+ ... It doesn't have the problems of node identity or
functional purity.
+ ... What is certainly true is that you could do something
similar to this for nodes as well. But it's harder because of
node identity; you pretty much have to copy the whole subtree
when you change a node.
+ ... Not having identity makes it harder to specify; it uses
the labeling feature to assign transient ids.
+ ... But, yes, it could be extended.
* RD: What's the overlap and syntax confusion going to be like?
* MK: Another thing to consider is that it's operating on a much
simpler data model.
* JLY: The verification step is to check that you're inside the map
or array that you're dealing with. It strikes me that you can
determine that statically.
* MK: Yes. But not always. And it's easy to do by mistake. I decided
rather than trying to restrict the syntax of the expression, it was
better to validate the result.
* CG: Thank you. It's a comprehensive proposal. I haven't checked the
semantics but we do use XQuery Update in most of our complicated
projects. We have noticed that there are sequences of updates. We
should definitely try to find a syntax that allows you to do more
than one operation gracefully.
+ ... I made one proposal for a possible syntax. We could also
think about using the same syntax as XQuery Update. I think it
would be fairly complex to define XQuery Update again for the
core specification.
* MK: There's all the complexity of validation and namespaces; it's
operating in a much more complicated world.
* CG: It would be nice to find a unified syntax.
* JLO: For me, that syntax is very close to what I see in code that
updates or modifies XML. But this is a different thing.
+ ... So why don't we have an insert here?
* MK: That really is entirely a question of trying to eat the
elephant in bite sized chunks. Produce something that's useful but
minimal first. If we can make the semantics work, we can grow from
there.
* RD: Building on this discussion, i wonder if it makes sense to keep
the XQuery Update syntax but then for the core XQuery
specification, don't worry about the update lists or any of those
things.
+ ... And then only limit it to maps and arrays. We know we can
do those without that complex machinery.
* MK: I was reluctant to use the copy-modify verb because people need
to realize this doesn't involve a wholesale copy. Conceptually it's
a copy but there's no identity so that's trivial.
* RD: With things like the replace, delete, insert rename syntax in
XQuery Update. Ideally, we would have the same general syntax but
instead of saying node or nodes, you'd say map or array. The update
facility syntax would then define the extensions for nodes.
+ ... The advantage of that is that we won't have yet another
syntax for doing the same sort of thing.
* MK: I'll look at whether the syntax can be aligned; but I'm
reluctant to take on something too large and complicated.
* RD: BaseX has an update syntax similar to this.
* CG: Yes.
* RD: I wonder if we could align or standardize along those lines.
+ ... The replace expression is standalone so you could maybe
leverage that.
* CG: MK, could you please open the pull request for #832.
+ ... I [44]made a suggestion for how to attempt to unify the
syntax.
+ ... Being able to bind intermediate results to variables can
be helpful.
3. Any other business
* NW: Should I make the highlighting colors a little different?
Some general agreement that it might be nice.
* JLO: The [45]update extension in eXist DB seems to be very similar.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2024/03-05.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/03-05.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/03-05.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/03-05.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/03-05.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/03-05.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/03-05.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/03-05.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/03-05.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/03-05.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/03-05.html#blocked
12. https://qt4cg.org/meeting/minutes/2024/03-05.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2024/03-05.html#close-without-action
14. https://qt4cg.org/meeting/minutes/2024/03-05.html#technical-agenda
15. https://qt4cg.org/meeting/minutes/2024/03-05.html#blocked-prs
16. https://qt4cg.org/meeting/minutes/2024/03-05.html#pr-1053
17. https://qt4cg.org/meeting/minutes/2024/03-05.html#pr-1049
18. https://qt4cg.org/meeting/minutes/2024/03-05.html#pr-1027
19. https://qt4cg.org/meeting/minutes/2024/03-05.html#pr-832
20. https://qt4cg.org/meeting/minutes/2024/03-05.html#any-other-business
21. https://qt4cg.org/meeting/minutes/2024/03-05.html#adjourned
22. https://qt4cg.org/meeting/minutes/
23. https://qt4cg.org/
24. https://qt4cg.org/dashboard
25. https://github.com/qt4cg/qtspecs/issues
26. https://github.com/qt4cg/qtspecs/pulls
27. https://qt4cg.org/meeting/agenda/2024/03-05.html
28. https://qt4cg.org/meeting/minutes/2024/02-27.html
29. https://qt4cg.org/meeting/agenda/2024/03-12.html
30. https://qt4cg.org/dashboard/#pr-956
31. https://qt4cg.org/dashboard/#pr-529
32. https://qt4cg.org/dashboard/#pr-1051
33. https://qt4cg.org/dashboard/#pr-1046
34. https://github.com/qt4cg/qtspecs/issues/1017
35. https://github.com/qt4cg/qtspecs/issues/825
36. https://github.com/qt4cg/qtspecs/issues/413
37. https://qt4cg.org/dashboard/#pr-956
38. https://qt4cg.org/dashboard/#pr-529
39. https://qt4cg.org/dashboard/#pr-1053
40. https://qt4cg.org/dashboard/#pr-1049
41. https://cldr.unicode.org/translation/number-currency-formats/number-and-currency-patterns
42. https://qt4cg.org/dashboard/#pr-1027
43. https://qt4cg.org/dashboard/#pr-832
44. https://github.com/qt4cg/qtspecs/pull/832#issuecomment-1977135759
45. https://exist-db.org/exist/apps/doc/update_ext
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 5 March 2024 17:29:27 UTC