- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 12 Sep 2023 17:50:38 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2a5tr1gj9.fsf@saxonica.com>
Draft minutes for meeting 045:
https://qt4cg.org/meeting/minutes/2023/09-12.html
QT4 CG Meeting 045 Minutes 2023-09-12
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [1/10]
* [3]1. Administrivia
+ [4]1.1. Roll call [8/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 [1/7]
+ [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
o [14]1.6.4. XSLT focused
o [15]1.6.5. Substantive PRs
o [16]1.6.6. Requires confirmation
o [17]1.6.7. Proposed for V4.0
* [18]2. Technical Agenda
+ [19]2.1. PRs
o [20]2.1.1. PR #659: 647: schema location hints
o [21]2.1.2. PR #673: HTML namespace changes
+ [22]2.2. Issues
o [23]2.2.1. Issue #129: Context item -> Context value?
* [24]3. Any other business?
* [25]4. Adjourned
[26]Agenda index / [27]QT4CG.org / [28]Dashboard / [29]GH Issues /
[30]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [1/10]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-026-01: MK to write a summary paper that outlines the
decisions we need to make on "value sequences"
+ This is related to PR #368: Issue 129 - Context item
generalized to context value and subsequent discussion.
* [ ] QT4CG-029-07: NW to open the next discussion of #397 with a
demo from DN See PR [31]#449
* [ ] QT4CG-039-01: NW to schedule discussion of issue [32]#52, Allow
record(*) based RecordTests
* [ ] QT4CG-042-02: NW to make the query into a simple map with
repeated values.
* [ ] QT4CG-042-03: NW to consider revisions to query parses.
* [ ] QT4CG-045-01: MK to redraft PR #659 to reflect "search path"
semantics.
* [ ] QT4CG-045-02: RD to address comments on HTML namespaces in
another PR
* [ ] QT4CG-045-03: MK to write a PR for context values (issue #129)
1. Administrivia
1.1. Roll call [8/11]
Regrets: JL, SF.
* [X] Reece Dunn (RD)
* [ ] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:05-]
* [X] Michael Kay (MK)
* [ ] John Lumley (JL)
* [ ] Dimitre Novatchev (DN)
* [X] Ed Porter (EP)
* [X] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
* [X] Wendell Piez
1.2. Accept the agenda
Proposal: Accept [33]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2023-09-12.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2023-09-12.png
Figure 2: Open issues by specification
issues-by-type-2023-09-12.png
Figure 3: Open issues by type
1.3. Approve minutes of the previous meeting
Proposal: Accept [34]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [35]is scheduled for Tuesday, 19 September 2023.
Regrets: None heard.
Proposal: the meeting of 26 September will focus on XSLT issues.
Accepted.
1.5. Review of open action items [1/7]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-026-01: MK to write a summary paper that outlines the
decisions we need to make on "value sequences"
+ This is related to PR #368: Issue 129 - Context item
generalized to context value and subsequent discussion.
* [ ] QT4CG-029-07: NW to open the next discussion of #397 with a
demo from DN See PR [36]#449
* [ ] QT4CG-039-01: NW to schedule discussion of issue [37]#52, Allow
record(*) based RecordTests
* [X] QT4CG-042-01: NW to use sequences instead of arrays in
parse-uri output.
* [ ] QT4CG-042-02: NW to make the query into a simple map with
repeated values.
* [ ] QT4CG-042-03: NW to consider revisions to query parses.
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 [38]#635: 451: Schema compatibility
* PR [39]#538: Attempt to allow xs:string to be 'promoted to'
xs:anyURI
* PR [40]#529: 528: revision of json(), and renaming to xdm-to-json()
* PR [41]#470: 369 add fixed-prefixes attribute in XSLT
* PR [42]#412: 409, QT4CG-027-01: xsl:next-match
* PR [43]#368: 129: Context item generalized to context value
1.6.2. Merge without discussion
The following PRs were discussed [44]last week and identified as "merge
next week" if there have been no comments to the contrary.
* PR [45]#631: 600: fn:decode-from-uri
* PR [46]#623: 93: sort descending
* PR [47]#599: 90: Simplified stylesheets with no xsl:version
Accepted.
The following editorial or otherwise minor PRs were open when this
agenda was prepared. The chairs propose that these can be merged
without discussion. If you think discussion is necessary, please say
so.
* PR [48]#682: 637: allow true() and false() as function annotation
values
* PR [49]#681: 665: Fix typos in fn:items-XX functions
* PR [50]#679: 669 - fix typo "appearing appearing"
* PR [51]#678: 671 switch sans operand
* PR [52]#672: XFO minor edits, chap. 1
Accepted.
1.6.3. Close without action
It has been proposed that the following issues be [53]closed without
action. If you think discussion is necessary, please say so.
* Issue [54]#160: Support named arguments on dynamic function calls
* MK: I couldn't figure out how to make this work, so let's just
abandon it.
+ ... It's not undesirable, but there's a technical problem when
you pass a function as an argument. When you want to call it
from a function it's been passed to, you don't know it's
argument names.
+ ... Various mechanisms proposed to alleviate that problem are
all hideously complicated.
* NW: Yeah, with regrets.
Accepted.
1.6.4. XSLT focused
The following PRs appear to be candidates for a future XSLT-focussed
meeting.
* PR [55]#674: 663: Describe how calls to xsl:original with keywords
work
* PR [56]#650: 649: fix an xsl:fallback problem
(And also [57]#470 and [58]#412 from the "blocked" list above.)
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 [59]#571: XSLT: xsl:for-each-group/@break-when
* Issue [60]#233: Declare the result type of a mode, via @as
* Issue [61]#172: Record Tests Feature
* Issue [62]#169: Handling of duplicate keys in xsl:map Enhancement
* Issue [63]#168: XSLT Extension Instructions invoking Named
Templates
1.6.5. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [64]#691: 688 Semantics of local union types, enumeration types,
etc
* PR [65]#690: 687 Clarify constructor functions for user-defined
types
* PR [66]#680: 668 define case insensitive collation normatively
* PR [67]#673: HTML namespace changes
* PR [68]#659: 647: schema location hints
1.6.6. Requires confirmation
These issues identify changes that have been made to the specifications
but which have not been established by the community group as the
status quo.
* Issue [69]#372: Separate default namespace for elements from the
default namespace for types
* Issue [70]#283: Enumeration types
1.6.7. Proposed for V4.0
The following issues are labled "proposed for V4.0".
* Issue [71]#479: fn:deep-equal: Input order
* Issue [72]#359: fn:void: Absorb result of evaluated argument
* Issue [73]#340: fn:format-number: Specifying decimal format
* Issue [74]#260: array:index-of
* Issue [75]#238: Support Invisible XML
* Issue [76]#130: New super/union type xs:binary?
* Issue [77]#129: Context item -> Context value?
* Issue [78]#36: Allow support for user-defined annotations.
2. Technical Agenda
2.1. PRs
Try to resolve as many of these PRs as we can, leaving 20 minutes to
discuss issues.
2.1.1. PR #659: 647: schema location hints
* MK: This is XQuery. XQuery allows an import schema to have more
than one location hint. I don't know why, and it doesn't say what
the multiple hints should mean, but we can try to describe the
semantics.
+ MK describes the proposed semantics for multiple hints, giving
a preferred strategy that hopefully will lead to a convergence
of behavior.
* NW: Is this what processors do now?
* MK: There aren't that many schema aware processors.
* RD: I was wondering whether it makes sense to do this for module
imports as well.
* MK: We did add something about that in 3.1. This is doing the same
for schema imports.
* MSM: I'm not convinced that these are the right semantics. Having
some hint is better than having none. Thinking back to the early
days of XSD and XQuery, I think that some of the database people
were motivated by the idea of a search path. I suspect that's what
this was for.
+ ... There are certainly cases where multiple schema documents
are used to make a schema, but in that case I think it's more
common to have a single schema document that includes them.
* MK: I can see the sense of that.
* NW: A search path is what I would have guessed if you'd asked me to
reply without investigating.
* RD: I'm looking through github using search and I can only see
single schema imports.
Proposal: rework this PR so that the meaning of multiple hints is that
the first one that's dereferencable is used.
* MSM: Do we want the first one you can dereference or the first one
from which you can successfully construct a schema?
Dereferencing is easier to describe. Fall over if you find something
you can't use.
* RD: Would it make sense to try to resolve them all and give a
warning if multiple are found?
* MSM: No, because one of the useful scenarios for a search path is
to select from different packages.
ACTION QT4CG-045-01: MK to redraft PR #659 to reflect "search path"
semantics.
2.1.2. PR #673: HTML namespace changes
RD walks us through the PR.
* RD: Added a note about the fact that there are two algorithms
defined in the HTML specification.
+ ... And added a note about namespace nodes in the HTML DOM
being ignored.
+ ... MK suggests this should be normative.
+ ... The implementation part should be a note but the actual
description should be normative.
+ ... Also included notes about implementation defined behavior
if shadow DOM nodes are passed in by APIs.
+ ... Removed all of the section about namespace nodes; simply
say it's an empty sequence per MK's suggestion. We
synthetically construct namespace nodes as needed.
* MK: You could have a high-level note that says the namepaces are
the minimum needed to satisfy the constraints in the Data Model.
* RD: Removed the section about dealing with attribute namespace
nodes, dealt with elsewhere.
+ ... Expanded the discussion of node-name to deal with colons
and other characters that would make the name not a valid
NCName.
* NW: I think that should be normative then.
* RD: If I remember correctly, the HTML one is only an example.
+ ... Similar, corresponding changes in related sections.
* NW: It sounded like there were a couple of different kinds of
changes you wanted to make. Some quite editorial, like moving
things out of notes, others more substantial. Do you want to do the
editorial ones and get this merged before moving on, or would you
like to do it all at once?
* RD: It would probably make sense to merge this.
Proposal: merge this PR and address the corrections in another
Accepted.
ACTION QT4CG-045-02: RD to address comments on HTML namespaces in
another PR
2.2. Issues
CG offered to update us on issue #129.
2.2.1. Issue #129: Context item -> Context value?
CG reviews issue #129.
* CG: The idea is to extend the context item to context value.
+ ... Context item can be referenced with a "."
+ ... The context item is singular, but variables can contain
sequences
+ ... It would be straightforward to allow the context to hold
sequences.
+ CG walks through some examples in the issue.
+ ... Could add a "declare context value" declaration to
describe the value.
+ ... It's especially interesting when the context value is
bound externally.
+ ... For example, you could bind the value to a collection and
then XPath can be used to address items from the collection.
* RD: That's also similar to what MarkLogic does. As I understand,
the way MarkLogic handles the example in the external binding
section is that it has a different definition of the double slash
expression that isn't attached to any other step.
+ ... When it's the root step it expands to something like
fn:collection instead of the normal root document.
* CG: There's been some discussion about whether the semantics should
be similar for single items or sequences.
* CG: New in QT4.0 are "focus functions". It works fine for single
items and it could be extended to sequences.
+ ... Arrow expressions also work the way you would expect.
+ ... One idea was to use ~ instead of . when using sequences.
+ ... The other challenge is if the semantics should really be
identical, or should binding sequences to paths have different
semantics.
* NW: Thank you.
* MK: The PR I did a long time ago is probably now out of date. I
think the devil here is in the detail and we wouldn't understand
them until we try to draft the technical changes.
+ ... In fact my conclusion from writing that PR is that it
wasn't as big a problem as I thought.
+ ... I adopted the approach of using "." for a single item and
"~" for the more general case.
+ ... That's partly because I was concerned about type checking
and optimization because we always know that "." is a
singleton and we can optimize for that.
+ ... XSLT uses the context item much more than Query, so it's
possibly quite a bit more complex. It probably needs to remain
a singleton in many of those cases even if it would be nice if
it could be a sequence.
+ ... I think it's feasible. It's disruptive but can probably
done without backwards incompatibilities. It'll just leave
some odd rules in the spec reflecting its history. This really
helps with arrays.
* MSM: I think I have two questions. Is there anything that currently
sets the context item where people are going to think it would make
more sense if it set a sequence. Or is the only way I'm going to
get a sequence is by declaring a context value?
* CG: I think right now declaring a context value is the only way. I
opened another issue where I discussed some different constructs
where you could explicitly bind a value.
* MK: Another use case I introduced was a notation for predicates on
arrays.
* MSM: I suppose, if we had had this from the beginning, the
definition of "/" would have been different. The other question was
about "~". If I'm understanding the suggestion correctly, if as a
user I want to simplify my life the rule I expect to follow would
be always "~" where you're used to using ".". And now sometimes it
can be a sequence. Then I guess the optimization opportunities go
away. But will users who do that run into problems?
* MK: In many ways there's less confusion if we use a single symbol.
And we lose the ability to use the ~ for things like in for each
group.
+ ... I think the optimization question is, do we still know
whether "." is a singleton? I think the main XSLT case there
is in where we're in a template rule and I think we would make
sure it was always a singleton.
* RD: I was wondering if there's a case where just using "." would
cause an ambiguity. In the example where you're passing "." to a
count function, but if you were passing it to something that only
accepted a singleton item, would this functionality cause an
ambiguity or errors?
* MK: I don't think so.
* CG: We've been doing this for 10 years and we've never encountered
any ambiguities.
Consensus is that we want to do this, yes?
Agreed.
ACTION QT4CG-045-03: MK to write a PR for context values (issue #129)
3. Any other business?
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2023/09-12.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/09-12.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/09-12.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/09-12.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/09-12.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/09-12.html#so-far
7. https://qt4cg.org/meeting/minutes/2023/09-12.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2023/09-12.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2023/09-12.html#open-actions
10. https://qt4cg.org/meeting/minutes/2023/09-12.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2023/09-12.html#blocked
12. https://qt4cg.org/meeting/minutes/2023/09-12.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2023/09-12.html#close-without-action
14. https://qt4cg.org/meeting/minutes/2023/09-12.html#xslt-focused
15. https://qt4cg.org/meeting/minutes/2023/09-12.html#substantive
16. https://qt4cg.org/meeting/minutes/2023/09-12.html#h-D87FC813-5BD6-4F9C-9013-91E47CC6DC92
17. https://qt4cg.org/meeting/minutes/2023/09-12.html#h-365344C1-99A5-4161-B5F0-27C1CE8F9922
18. https://qt4cg.org/meeting/minutes/2023/09-12.html#technical-agenda
19. https://qt4cg.org/meeting/minutes/2023/09-12.html#h-2EA8CA5F-DAA1-46CE-97C5-FEA7ACC0ACF3
20. https://qt4cg.org/meeting/minutes/2023/09-12.html#h-574D19F6-F003-4431-AAD5-7B2017039300
21. https://qt4cg.org/meeting/minutes/2023/09-12.html#h-4CFD14DD-17A1-4E18-9D2B-98D8EFDA9813
22. https://qt4cg.org/meeting/minutes/2023/09-12.html#h-F60492E6-D0D3-4325-B640-B1201EB30024
23. https://qt4cg.org/meeting/minutes/2023/09-12.html#h-D8A3B62B-C816-4F24-A3F5-26A39109E0FC
24. https://qt4cg.org/meeting/minutes/2023/09-12.html#any-other-business
25. https://qt4cg.org/meeting/minutes/2023/09-12.html#adjourned
26. https://qt4cg.org/meeting/minutes/
27. https://qt4cg.org/
28. https://qt4cg.org/dashboard
29. https://github.com/qt4cg/qtspecs/issues
30. https://github.com/qt4cg/qtspecs/pulls
31. https://qt4cg.org/dashboard/#pr-449
32. https://github.com/qt4cg/qtspecs/issues/52
33. https://qt4cg.org/meeting/agenda/2023/09-12.html
34. https://qt4cg.org/meeting/minutes/2023/09-05.html
35. https://qt4cg.org/meeting/agenda/2023/09-19.html
36. https://qt4cg.org/dashboard/#pr-449
37. https://github.com/qt4cg/qtspecs/issues/52
38. https://github.com/qt4cg/qtspecs/pull/635
39. https://github.com/qt4cg/qtspecs/pull/538
40. https://github.com/qt4cg/qtspecs/pull/529
41. https://github.com/qt4cg/qtspecs/pull/470
42. https://github.com/qt4cg/qtspecs/pull/412
43. https://github.com/qt4cg/qtspecs/pull/368
44. https://qt4cg.org/meeting/minutes/2023/09-05.html#open-prs
45. https://github.com/qt4cg/qtspecs/pull/631
46. https://github.com/qt4cg/qtspecs/pull/623
47. https://qt4cg.org/dashboard/#pr-599
48. https://github.com/qt4cg/qtspecs/pull/682
49. https://github.com/qt4cg/qtspecs/pull/681
50. https://github.com/qt4cg/qtspecs/pull/679
51. https://github.com/qt4cg/qtspecs/pull/678
52. https://github.com/qt4cg/qtspecs/pull/672
53. https://github.com/qt4cg/qtspecs/labels/Propose%20Closing%20with%20No%20Action
54. https://github.com/qt4cg/qtspecs/issues/160
55. https://github.com/qt4cg/qtspecs/pull/674
56. https://github.com/qt4cg/qtspecs/pull/650
57. https://github.com/qt4cg/qtspecs/pull/470
58. https://github.com/qt4cg/qtspecs/pull/412
59. https://github.com/qt4cg/qtspecs/issues/571
60. https://github.com/qt4cg/qtspecs/issues/233
61. https://github.com/qt4cg/qtspecs/issues/172
62. https://github.com/qt4cg/qtspecs/issues/169
63. https://github.com/qt4cg/qtspecs/issues/168
64. https://qt4cg.org/dashboard/#pr-691
65. https://qt4cg.org/dashboard/#pr-690
66. https://qt4cg.org/dashboard/#pr-680
67. https://qt4cg.org/dashboard/#pr-673
68. https://qt4cg.org/dashboard/#pr-659
69. https://github.com/qt4cg/qtspecs/issues/372
70. https://github.com/qt4cg/qtspecs/issues/283
71. https://github.com/qt4cg/qtspecs/issues/479
72. https://github.com/qt4cg/qtspecs/issues/359
73. https://github.com/qt4cg/qtspecs/issues/340
74. https://github.com/qt4cg/qtspecs/issues/260
75. https://github.com/qt4cg/qtspecs/issues/238
76. https://github.com/qt4cg/qtspecs/issues/130
77. https://github.com/qt4cg/qtspecs/issues/129
78. https://github.com/qt4cg/qtspecs/issues/36
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 12 September 2023 16:51:34 UTC