- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 24 Oct 2023 18:08:23 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2a5s8kkwg.fsf@saxonica.com>
Hello,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2023/10-24.html
QT4 CG Meeting 051 Minutes 2023-10-24
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/8]
* [3]1. Administrivia
+ [4]1.1. TODO Roll call [9/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 [5/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. Proposed for V4.0
* [17]2. Technical Agenda
+ [18]2.1. Issue 129: Context item -> Context value?
+ [19]2.2. Issue 238: Support Invisible XML
+ [20]2.3. PR #635: 451: Schema compatibility
+ [21]2.4. PR #734: 517: fn:chain
* [22]3. Any other business?
* [23]4. Adjourned
[24]Agenda index / [25]QT4CG.org / [26]Dashboard / [27]GH Issues /
[28]GH Pull Requests
Draft Minutes
Summary of new and continuing actions [0/8]
* [ ] QT4CG-046-01: MK to continue the work on #129 for the other
specs (we accepted #703)
* [ ] QT4CG-050-02: MP to attempt to summarize this discussion and
identify specific issues
* [ ] QT4CG-051-01: NW to attempt to craft a new issue for the
remaining items in #129
* [ ] QT4CG-051-02: NW to attempt to draft a proposal for
fn:invisible-xml
* [ ] QT4CG-051-03: MK to check that in our view schema components
don't indirectly reference the schema root
* [ ] QT4CG-051-04: DN to make the point that in simple, static
cases, the arrow operators may be better.
* [ ] QT4CG-051-05: DN to correct the typo in item 3 "could be
sequence" => "could
* [ ] QT4CG-051-06: MK to help DN with the markup in fn:chain
examples.
1. Administrivia
1.1. TODO Roll call [9/11]
* [X] Reece Dunn (RD)
* [ ] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [:10-]
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [ ] Ed Porter (EP)
* [X] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [29]the agenda.
Accepted.
1.2.1. Status so far...
issues-open-2023-10-24.png
Figure 1: "Burn down" chart on open issues
issues-by-spec-2023-10-24.png
Figure 2: Open issues by specification
issues-by-type-2023-10-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
ATTENTION: Europe and the United Kingdom switch from daylight saving
time to standard time on Sunday, October 29, 2023. The meeting on
Tuesday, 31 October 2023, will occur at a time one hour later in The
United States.
The next meeting [31]is scheduled for Tuesday, 31 October 2023.
No regrets heard.
1.5. Review of open action items [5/7]
* [ ] QT4CG-046-01: MK to continue the work on #129 for the other
specs (we accepted #703)
* [X] QT4CG-046-04: CG to flesh out changes related to annotations in
other parts of the specs
* [X] QT4CG-046-05: NW to updated parse-uri to use decode-from-uri
(issue #566)
* [X] QT4CG-048-02: MK to clean up the proposal for adding @as to
xsl:sequence and elsewhere
+ MK proposes to close as unclear
* [ ] QT4CG-050-02: MP to attempt to summarize this discussion and
identify specific issues
* [X] QT4CG-050-01: MK to revise #749 to retain only the editorial
parts.
* [X] QT4CG-050-03: MK to make the proposed editorial improvements to
PR #659
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 [32]#538: 480: Attempt to allow xs:string to be 'promoted to'
xs:anyURI
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 [33]#766: 765 Update version references etc to 4.0 status
* PR [34]#763: 686: XQFO diagnostic function documentation
* PR [35]#762: 758: XQFO minor edits 3
* PR [36]#749: 653: Add string literals E".." and L".." to control
entity expansion
* PR [37]#659: 647: schema location hints
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 [38]#383: fn:deep-equal: Order of child elements
(unordered-elements)
Proposal: Close without action.
Accepted.
1.6.4. XSLT focused
The following PRs appear to be candidates for a future XSLT-focussed
meeting.
* PR [39]#470: 369: add fixed-prefixes attribute in XSLT
* PR [40]#412: 409, QT4CG-027-01: xsl:next-match
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 [41]#742: xsl:function-library: keep, drop, or refine?
* Issue [42]#169: Handling of duplicate keys in xsl:map
* Issue [43]#168: XSLT Extension Instructions invoking Named
Templates
1.6.5. Substantive PRs
The following substantive PRs were open when this agenda was prepared.
* PR [44]#761: 554/754 Simplify the new transitive-closure function
* PR [45]#753: 65: Allow xmlns="xxx" to NOT change the default
namespace for NameTests
* PR [46]#737: 295: Boost the capability of recursive record types
* PR [47]#736: 730: Clarify (and correct) rules for maps as instances
of function types
* PR [48]#734: 517: fn:chain
* PR [49]#719: 413: Spec for CSV-related functions
* PR [50]#635: 451: Schema compatibility
* PR [51]#529: 528: revision of json(), and renaming to
elements-to-maps()
1.6.6. Proposed for V4.0
The following issues are labled "proposed for V4.0".
* Issue [52]#716: Generators in XPath
* Issue [53]#479: fn:deep-equal: Input order
* Issue [54]#340: fn:format-number: Specifying decimal format
* Issue [55]#260: array:index-of
* Issue [56]#238: Support Invisible XML
* Issue [57]#130: New super/union type xs:binary?
* Issue [58]#129: Context item -> Context value?
* Issue [59]#31: Extend FLWOR expressions to maps
2. Technical Agenda
2.1. Issue 129: Context item -> Context value?
See issue [60]#129: does this need to remain open? Can we create
actions for the unresolved edits instead?
ACTION QT4CG-051-01: NW to attempt to craft a new issue for the
remaining items in #129
2.2. Issue 238: Support Invisible XML
See issue [61]#238: time boxed discussion to see if the group wants to
do this.
ACTION QT4CG-051-02: NW to attempt to draft a proposal for
fn:invisible-xml
2.3. PR #635: 451: Schema compatibility
See PR [62]#635.
MK introduces the issue.
* MK: We say very little about what happens if you import multiple
schemas.
+ ... MK reviews what the various specs say, or don't say.
+ ... This PR defines a compatibility relationship between two
schemas
+ ... It then specifies that schemas must be compatible where
they intersect.
* MK walks through the Data Model changes
+ ... The most basic comaptibilty condition is that they don't
have different components with the same name.
+ Cases where things can be different (but still compatible):
o Subsitution group membership
o Different extensions for the same base type
o Lax wildcards
+ ... When you validate with one schema and then pass the
document to another module, there are some gaurantees, but
there are also things that can vary.
+ ... The rest of the changes are about how these rules are
applied.
* RD: Do we want to bring in some other definitions from XML Schema
for completeness. There's a discussion on the XML.com Slack by Adam
Retter about the definition of the base type which is defined in
XML Schema but not used here.
* MK: Is that directly relevant to this topic, or is it something
wider?
* RD: It's not specific to the schema consistency changes but it's
part of the process of bringing in schemas.
* MK: I think we should have a separate issue for that.
Some further discussion of the type derivation rules and the discussion
that took place on the XML.com Slack.
* MSM: My recollection is that there were two schools of thought
within the Schema WG and consequently perhaps in the specification
about what it meant for one component to point to another. One
school of thought was knowing the base type name. The other school
of thought was that what you had was transclusion; you had to
dereference that pointer so if you had two schemas where the base
types were slightly different, they were different even though they
had the same name. Connected with this there was a mechanism that
allowed one to construct a link of references to the schema
components. This meant adding any item to a schema changed all the
items in the schema.
+ ... What I'm hearing you say is that we expect most people to
take the identity of names view.
* MK: I don't think it makes a difference whether you take the
reference as being a name or a pointer to a component. If the names
are the same, then the components have to be the same by recursive
application of the rule.
+ ... The point about a chain of references back up to the root
of the tree is more concerning. If that's the case, then this
theory fails. I guess I'd need to search exhaustively to see
if there exists such a property.
* MSM: That sounds to me as if there is some non-zero chance that
there's a problem.
* MSM: The second question is, if I do have two incompatible schemas,
and I want to use one to validate and expression and then feed it
into a stylesheet where a different schema is used. I imagine I'm
going to want to say at this point that the processor is going to
have to revalidate. Is that feasible?
* MK: I've raised a separate issue about multiple schemas where I'm
starting to think about being able to import two schemas, give them
names, and then say which one you want to validate against. That's
not part of this proposal.
+ ... If you want to convert between incompatible schemas, you
can't do that within a single module or stylesheet. Resolving
that is another step.
Proosal: Merge this PR.
Accepted.
ACTION QT4CG-051-03: MK to check that in our view schema components
don't indirectly reference the schema root
2.4. PR #734: 517: fn:chain
See [63]#734.
* DN walks us through the function
* DN: One of the features of the fn:chain function is that it adapts
the results of the previous function to the arity of the next
function.
+ ... DN describes the examples
* JL: If we curry this against the first argument, then we have the
composition of a set of functions.
+ ... We have the arrow operators that allow us to string things
together that can handle a number of these static cases.
+ ... The difficult bit is going to be modeling what it means
when the arity varies across the sequence of functions.
* DN: I didn't hear a question, but thank you for mentioning the
chaining operators. This is useful to know the difference between
the arrow operators and fn:chain.
+ ... In the arrow operators, we have only expressions, but here
we have functions with names. The fact that the arity can
change makes the fn:chain function more powerful.
+ ... Others have asked about this more complicated case with
changing arities. Nothing requires users to use the more
complicated case, so I don't think that's a point of concern.
* JL: We have two forms of arrow operators now. We have examples
where you can go back and forth between those examples. You can use
functions and expressions. The thing that what's much more
complicated here is that the list of functions can very variable.
* MSM: Can we clarify briefly the interaction of this wit variable
arity functions? I guess if I have a variable arity function that
can accept 3, 4, or 5 arguments then I really have three functions.
* DN: Yes, and there are examples that demonstrate these things.
* MK: Function items don't have variable arity; function definitions
can have variable arity from which you can derive funtion items
with specific arities.
* MSM: In answering JL's comment, DN said these are always named
functions. But if I'm handing fn:chain a sequence of functions, I
can hand it anonymous functions, can't I?
* DN: Yes, but that would be defeating part of the purpose of this
function which is to provide a meaningful set of functions to be
applied.
A proposal to accept the PR is made, more discussion follows.
* CG: Can we limit this to arity one functions? It could be hard to
understand how this works if the semantics of the function varies
depending on the arguments.
* DN: The real power here is to make it possible to do more
complicated things, but we aren't requiring users to use functions
with arities greater than one. This is an extension of the idea of
chaining.
* CG: In this case, it would be useful to show some examples that
require functions that have arities greater than one.
* DN: Yes, we could have many more examples.
* JL: I would say that in the notes for this function, I think it
might be useful to say that in simple, static cases, it might be
better to use the chaining operators.
ACTION QT4CG-051-04: DN to make the point that in simple, static cases,
the arrow operators may be better.
* MSM: Editorially, in item 3 in the list, the fact that the sequence
has "N" items is not parenthetical.
ACTION QT4CG-051-05: DN to correct the typo in item 3 "could be
sequence" => "could be sequences".
ACTION QT4CG-051-06: MK to help DN with the markup in fn:chain
examples.
Proposal: Accept this PR.
Accepted.
3. Any other business?
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2023/10-24.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/10-24.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/10-24.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/10-24.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/10-24.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/10-24.html#so-far
7. https://qt4cg.org/meeting/minutes/2023/10-24.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2023/10-24.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2023/10-24.html#open-actions
10. https://qt4cg.org/meeting/minutes/2023/10-24.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2023/10-24.html#blocked
12. https://qt4cg.org/meeting/minutes/2023/10-24.html#merge-without-discussion
13. https://qt4cg.org/meeting/minutes/2023/10-24.html#close-without-action
14. https://qt4cg.org/meeting/minutes/2023/10-24.html#xslt-focused
15. https://qt4cg.org/meeting/minutes/2023/10-24.html#substantive
16. https://qt4cg.org/meeting/minutes/2023/10-24.html#proposed-40
17. https://qt4cg.org/meeting/minutes/2023/10-24.html#technical-agenda
18. https://qt4cg.org/meeting/minutes/2023/10-24.html#h-C2A69248-3E52-4051-A730-215B90AFF39E
19. https://qt4cg.org/meeting/minutes/2023/10-24.html#h-A9F70A82-FE82-442A-B9C1-2027CB9628D8
20. https://qt4cg.org/meeting/minutes/2023/10-24.html#schema-compatibility
21. https://qt4cg.org/meeting/minutes/2023/10-24.html#chain
22. https://qt4cg.org/meeting/minutes/2023/10-24.html#any-other-business
23. https://qt4cg.org/meeting/minutes/2023/10-24.html#adjourned
24. https://qt4cg.org/meeting/minutes/
25. https://qt4cg.org/
26. https://qt4cg.org/dashboard
27. https://github.com/qt4cg/qtspecs/issues
28. https://github.com/qt4cg/qtspecs/pulls
29. https://qt4cg.org/meeting/agenda/2023/10-24.html
30. https://qt4cg.org/meeting/minutes/2023/10-17.html
31. https://qt4cg.org/meeting/agenda/2023/10-31.html
32. https://qt4cg.org/dashboard/#pr-538
33. https://qt4cg.org/dashboard/#pr-766
34. https://qt4cg.org/dashboard/#pr-763
35. https://qt4cg.org/dashboard/#pr-762
36. https://qt4cg.org/dashboard/#pr-749
37. https://qt4cg.org/dashboard/#pr-659
38. https://github.com/qt4cg/qtspecs/issues/383
39. https://qt4cg.org/dashboard/#pr-470
40. https://qt4cg.org/dashboard/#pr-412
41. https://github.com/qt4cg/qtspecs/issues/742
42. https://github.com/qt4cg/qtspecs/issues/169
43. https://github.com/qt4cg/qtspecs/issues/168
44. https://qt4cg.org/dashboard/#pr-761
45. https://qt4cg.org/dashboard/#pr-753
46. https://qt4cg.org/dashboard/#pr-737
47. https://qt4cg.org/dashboard/#pr-736
48. https://qt4cg.org/dashboard/#pr-734
49. https://qt4cg.org/dashboard/#pr-719
50. https://qt4cg.org/dashboard/#pr-635
51. https://qt4cg.org/dashboard/#pr-529
52. https://github.com/qt4cg/qtspecs/issues/716
53. https://github.com/qt4cg/qtspecs/issues/479
54. https://github.com/qt4cg/qtspecs/issues/340
55. https://github.com/qt4cg/qtspecs/issues/260
56. https://github.com/qt4cg/qtspecs/issues/238
57. https://github.com/qt4cg/qtspecs/issues/130
58. https://github.com/qt4cg/qtspecs/issues/129
59. https://github.com/qt4cg/qtspecs/issues/31
60. https://github.com/qt4cg/qtspecs/issues/129
61. https://github.com/qt4cg/qtspecs/issues/238
62. https://qt4cg.org/dashboard/#pr-635
63. https://qt4cg.org/dashboard/#pr-734
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 24 October 2023 17:09:15 UTC