- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 24 Sep 2024 17:45:36 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m28qvh9f0v.fsf@saxonica.com>
Hi folks,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2024/09-24.html
QT4 CG Meeting 091 Minutes 2024-09-24
[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/7]
* [8]1. Administrivia
+ [9]1.1. Roll call [11/12]
+ [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 [2/7]
+ [15]1.6. Review of open pull requests and issues
o [16]1.6.1. Blocked
o [17]1.6.2. Merge without discussion
* [18]2. Technical agenda
+ [19]2.1. PR #1429: Align type tests
+ [20]2.2. PR #1430: 1427 Add element-number function
+ [21]2.3. PR #1433: 1422 fn:hash: Revision
+ [22]2.4. PR #1435: 1421 fn:unix-time: Revisions
+ [23]2.5. PR #1436: 1323 Function parameters names: $href ->
$uri
+ [24]2.6. PR #1437: 1325 Variadic System Functions limited to
`fn:concat`
+ [25]2.7. PR #1439: 1235 Function Identity: Treating function
items with identical bodies
+ [26]2.8. PR #1453: Fix typo in load-xquery-module example
* [27]3. Any other business
* [28]4. Adjourned
Draft Minutes
Summary of new and continuing actions [0/7]
* [ ] QT4CG-080-07: NW to update the build instructions in the README
* [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-088-01: NW to consider how best to add a dedication to
MSM.
* [ ] QT4CG-088-04: [Someone] needs to update the processing model
diagram needs vis-a-vis the static typing feature
* [ ] QT4CG-089-01: CG to draft a PR that attempts to resolve the
operators described in #755 to a smaller number of orthogonal
choices.
* [ ] QT4CG-091-01: MK to make sure there's an editorial note about
parameter renaming.
1. Administrivia
1.1. Roll call [11/12]
* [X] David J Birnbaum (DB)
* [X] Reece Dunn (RD)
* [ ] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:05-]
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [29]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-2024-09-24.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2024-09-24.png
Figure 2: Open issues by specification
issues-by-type-2024-09-24.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [30]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
This next meeting is planned for 1 October. Any regrets?
None heard.
1.5. Review of open action items [2/7]
(Items marked [X] are believed to have been closed via email before
this agenda was posted.)
* [ ] QT4CG-080-07: NW to update the build instructions in the README
* [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-088-01: NW to consider how best to add a dedication to
MSM.
* [X] QT4CG-088-03: MK to add an example of duplicate
function-annotations being returned.
* [ ] QT4CG-088-04: [Someone] needs to update the processing model
diagram needs vis-a-vis the static typing feature
* [ ] QT4CG-089-01: CG to draft a PR that attempts to resolve the
operators described in #755 to a smaller number of orthogonal
choices.
* [X] QT4CG-090-01: MK to add an example of fn:element-number that
does multi-part numbering
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 [31]#1296: 982 Rewrite of scan-left and scan-right
* PR [32]#1283: 77b Update expressions
* PR [33]#1062: 150bis revised proposal for fn:ranks
* PR [34]#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 [35]#1447: 1446 Rephrase conformance rule on xs:dateTime limits
* PR [36]#1444: Implement improvement to bibligraphy entry for IEEE
802.3
* PR [37]#1438: 1322 fn:collation-available (editorial)
* PR [38]#1434: 1373 XQFO: Editorial
Proposal: merge without discussion.
Accepted.
2. Technical agenda
2.1. PR #1429: Align type tests
See PR [39]#1429
* JLO attempts to present the draft, but the diff is out-of-date
JLO will rebase and we'll look next week.
2.2. PR #1430: 1427 Add element-number function
See PR [40]#1430.
* MK shows us the changes he made in response to comments last week.
* CG: Last example is pretty helpful. This is a less-common challenge
in XQuery.
* DN: What does `recursive hierarchy' mean?
* MK: Sections nested in sections in sections.
* NW: That's not an uncommon way of describing nested structures.
That's what DocBook says about the section element, for example.
* WP asks about the self() expression.
* MK: That's new.
Proposal: accept this PR.
Accepted.
2.3. PR #1433: 1422 fn:hash: Revision
See PR [41]#1433.
* CG introduces the PR.
* CG: I promoted the algorithm to an explicit parameter.
+ ... And I fixed one erroneous example.
* JWL: So you wouldn't have options if you didn't want to set the
algorithm.
Some discussion of promoting the algorithm. NW thinks its a good idea.
* DN: I think this is a good change. In other functions where there's
an options parameter with only one key, we could make this change.
Proposal: accept this PR.
Accepted.
2.4. PR #1435: 1421 fn:unix-time: Revisions
See PR [42]#1435.
* CG introduces the PR.
* CG: Renamed it from fn:unix-time to fn:unix-dateTime. The other
change is that we only allow non-negative integers.
* MK: Why did we limit it to non-negative integers?
* CG: The POSIX standard only talks about 64 bit (unsigned) integers.
Proposal: accept this PR.
Accepted.
2.5. PR #1436: 1323 Function parameters names: $href -> $uri
See PR [43]#1436.
* CG introduces the PR.
* CG: This is about making the href/uri parameter names more
consistent.
+ ... It seemed ambiguous to me, there's no explanation for the
different names.
* NW: I prefered $href for some, but I'm not going to fuss.
* MK: I'm concerned that in popular parlance we speak of "relative
URIs" when the technical term is "relative reference" which isn't a
URI.
* DN: I feel strongly that we should make this uniform, but in the
already existing versions we have parameters with these names.
* CG: It's never mattered before because we couldn't address
parameters by name, but now you can.
+ ... We renamed a bunch of parameters, so now we have a mixture
of href and uri.
* DN: But that could be confusing because users may have read earlier
versions of the specification.
+ ... Perhaps we need to have a short editorial note about the
fact that the parameters have been renamed.
* JLO: I'd like to stick with $href.
* CG: What about fn:collection. It uses $uri that was one of the
questions.
* JLO: I think $href would be fine for fn:collection.
* MK: Collations in principle can be relative references, but it's
strongly discouraged.
+ ... I'm not sure anyone uses them that way.
+ ... There are certainly places where we use URIs as names:
collections, modules, namespaces.
+ ... There are some cases where things might be names or
collections.
+ ... We're trying to decide which ones are supposed to be names
and which are supposed to be locations.
Some discussion of relative vs. absolute URIs and where they can be
used. Namespace URIs are never made absolute, but some others are.
* WP: If we say $uri then it's a URI and if it's just a reference, it
can be a $href.
* RD: I wonder if, based one of the comments in the discussion, with
using names like $uri and $href we're making parameters names based
on the role we expect them to play. Perhaps using names like $value
would be better. So we aren't saying $int for a name.
* CG: One of my proposal was to use $source or $input instead.
* DN: If we seem to not be able to agree on the exact name, maybe a
compromise solution would be to use a neutral name like
$source-reference. And we can say in some note that we're using a
unified name.
* RD: I think $input or $source are reasonable names. But I don't
really have a preference.
+ ... For me, a name like $source-reference is too verbose. I
quite like something more concise.
Straw poll: $source or $input? $source gets 7 votes, $input gets none.
* MK: Let's take this back to email.
ACTION: MK to make sure there's an editorial note about parameter
renaming.
2.6. PR #1437: 1325 Variadic System Functions limited to `fn:concat`
See PR [44]#1437.
* CG introduces the PR.
* CG: At the moment, fn:concat, fn:codepoints-to-string and
fn:distinct-unordered-nodes are variadic.
+ ... I wanted to find a simple answer to the question: why are
those variadic?
+ ... But what rule would we follow?
+ ... If there's no rule, maybe we should only use it for
fn:concat where it's needed.
+ ... Then we could come back to the question if we came up with
a simple rule.
+ ... It might be that having an $options parameter on
fn:codepoints-to-string and fn:distinct-unordered-nodes would
be better.
* MK: It's a valid point. I sort of feel like we introduced variadicy
because fn:concat stands out like a sore thumb. Having introduced
it, I thought we could use it to make some functions more useful.
+ ... But it does inhibit extensibilty on those functions in the
future.
+ ... I don't know what the right answer is.
* JWL: I think it's more trouble than its worth. I don't think anyone
would be annoyed if we just left it.
* JLO: The arguments that CG just brought up are really useful. I
just want to make sure I understand.
+ ... Is it still the case that in XQuery 4 will allow users to
create new variadic functions?
* MK: Yes.
* DN: I think that the change proposed by CG results in more exact
definitions. But on the other side, if we have to list two or three
different overloads, this will consume a very big space. I am in
favor of a compromise, leave them variadic but add a note that you
can't have more than two values. That seems more concise to me.
Chair tries a straw poll. In favor: 4, opposed: 0. So not real
consensus here.
Some discussion of DN's compromise proposal that we limit the
variadicity to only a maximum number of arguments.
* CG: I can't see why we should limit to a specific number.
* RD: The comment was about adding more arguments to
codepoints-to-values. If you limited it, you could imagine adding
more extensible parameters in the future.
* NW: That didn't help me.
* CG: We could remove varadicity from these two functions and then
come back later to decide which ones should.
* WP: I have to say, as a user, variadicity is a problem. I'd like to
think of fn:concat as an outlier.
* RD: Various other vendor functions, in BaseX and MarkLogic for
example, are declared as variadic. The motivation that I had for
specifying varadicity was that it wasn't defined in the
specification. fn:concat was just magic.
Take it back to email.
2.7. PR #1439: 1235 Function Identity: Treating function items with identical
bodies
See PR [45]#1439.
* CG introduces the PR.
* CG: The current status quo:
# Function Result
1 deep-equal(<a/>, <a/>) true()
2 let $f := fn { <a/> } return deep-equal($f, $f) true()
3 deep-equal(fn { 1 }, fn { 1 }) true() or false()
4 deep-equal(fn { <a/> }, fn { <a/> }) false()
* CG: As you can see there's inconsistency here.
+ ... MK proposed some small changes to a few paragraphs.
+ ... These changes allow the last example to return either
true() or false().
CG shows the relevant part 4.5.2.7 Function Identity
* DN: I want to remark that the fact that bodies of two functions are
identical doesn't mean that the functions are the same. Both the
body and the signature have to be the same.
* JLO: I just wanted to say that the way it's written, only the
optimizer can decide. That will definitely take dynamic scope into
account. I think DN's concern is addressed.
* MK: I think this text explains the way I've always understood the
intent.
+ ... I think this is an editorial improvement.
* DN: No, what JLO said doesn't address my concerns. It leaves the
impression that we have function identity when the bodies are
identical which is not true. We can easily add the signature to the
definition.
* CG: I read all the rules and I don't think the changes I'm making
are in those areas.
Proposal: accept this PR.
Accepted.
2.8. PR #1453: Fix typo in load-xquery-module example
See PR [46]#1453.
Proposal: accept this PR.
Accepted.
3. Any other business
* JWL describes some of his recent work with grammars.
* JWL: I've been producing iXML grammars for the current state. I've
got to a point where I've generated both the XQuery and XPath
grammars and I've run them over the whole test set. Getting about
50 failures, mostly whitespace and embedded "-".s
+ ... I have a mechanism for generating a grammar from the
current state.
+ ... I'll publish this to the whole group.
JWL demonstrates the XPath 4.0 grammar parsing some expressions. It can
provide the full parse or a reduced parse.
* JWL: This let's you experiment with minor changes in the grammar to
see if it might introduce ambiguities.
JWL demonstrates the XQuery grammar as well.
* JWL: This work is available now at
[47]https://johnlumley.github.io/jwiXML.xhtml
+ ... I'll put the grammars themselves on my GitHub page.
+ ... I'll try to keep up with significant grammar changes.
* RD: Is it possible to integrate this into the build process?
* JWL: Maybe, but some parts of it need to go through the browser.
* MK: In the older specs, fragments of XPath and XQuery code where
tagged and there were tests. But we haven't maintained that.
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/2024/09-24.html#minutes
7. https://qt4cg.org/meeting/minutes/2024/09-24.html#new-actions
8. https://qt4cg.org/meeting/minutes/2024/09-24.html#administrivia
9. https://qt4cg.org/meeting/minutes/2024/09-24.html#roll-call
10. https://qt4cg.org/meeting/minutes/2024/09-24.html#agenda
11. https://qt4cg.org/meeting/minutes/2024/09-24.html#so-far
12. https://qt4cg.org/meeting/minutes/2024/09-24.html#approve-minutes
13. https://qt4cg.org/meeting/minutes/2024/09-24.html#next-meeting
14. https://qt4cg.org/meeting/minutes/2024/09-24.html#open-actions
15. https://qt4cg.org/meeting/minutes/2024/09-24.html#open-pull-requests
16. https://qt4cg.org/meeting/minutes/2024/09-24.html#blocked
17. https://qt4cg.org/meeting/minutes/2024/09-24.html#merge-without-discussion
18. https://qt4cg.org/meeting/minutes/2024/09-24.html#technical-agenda
19. https://qt4cg.org/meeting/minutes/2024/09-24.html#pr-1429
20. https://qt4cg.org/meeting/minutes/2024/09-24.html#pr-1430
21. https://qt4cg.org/meeting/minutes/2024/09-24.html#pr-1433
22. https://qt4cg.org/meeting/minutes/2024/09-24.html#pr-1435
23. https://qt4cg.org/meeting/minutes/2024/09-24.html#pr-1436
24. https://qt4cg.org/meeting/minutes/2024/09-24.html#pr-1437
25. https://qt4cg.org/meeting/minutes/2024/09-24.html#pr-1439
26. https://qt4cg.org/meeting/minutes/2024/09-24.html#pr-1453
27. https://qt4cg.org/meeting/minutes/2024/09-24.html#any-other-business
28. https://qt4cg.org/meeting/minutes/2024/09-24.html#adjourned
29. https://qt4cg.org/meeting/agenda/2024/09-24.html
30. https://qt4cg.org/meeting/minutes/2024/09-17.html
31. https://qt4cg.org/dashboard/#pr-1296
32. https://qt4cg.org/dashboard/#pr-1283
33. https://qt4cg.org/dashboard/#pr-1062
34. https://qt4cg.org/dashboard/#pr-529
35. https://qt4cg.org/dashboard/#pr-1447
36. https://qt4cg.org/dashboard/#pr-1444
37. https://qt4cg.org/dashboard/#pr-1438
38. https://qt4cg.org/dashboard/#pr-1434
39. https://qt4cg.org/dashboard/#pr-1429
40. https://qt4cg.org/dashboard/#pr-1430
41. https://qt4cg.org/dashboard/#pr-1433
42. https://qt4cg.org/dashboard/#pr-1435
43. https://qt4cg.org/dashboard/#pr-1436
44. https://qt4cg.org/dashboard/#pr-1437
45. https://qt4cg.org/dashboard/#pr-1439
46. https://qt4cg.org/dashboard/#pr-1453
47. https://johnlumley.github.io/jwiXML.xhtml
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 24 September 2024 16:45:49 UTC