- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Thu, 30 Mar 2023 16:48:58 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2zg7ui6h6.fsf@Hackmatack-eth.fritz.box>
Hello,
Here are the draft minutes from Tuesday. Apologies for the delay.
https://qt4cg.org/meeting/agenda/2023/03-28.html
QT4 CG Meeting 028 Minutes 2023-03-28
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/7]
* [3]1. Administrivia
+ [4]1.1. Roll call [8/12]
+ [5]1.2. Accept the agenda
+ [6]1.3. Approve minutes of the previous meeting
+ [7]1.4. Next meeting
+ [8]1.5. Review of open action items [1/7]
* [9]2. Technical Agenda
+ [10]2.1. PR #408: Fix issue #398 (clash with constructor
functions)
+ [11]2.2. PR #406: Revise xsl:array instruction and examples
+ [12]2.3. PR #404: Rework changes from action-qt4cg-019-01 to
resolve persistent conflicts.
+ [13]2.4. PR #375: Context for default parameter values
+ [14]2.5. PR #396: Deep-equal, no failure when comparing
functions
+ [15]2.6. PR #368: Issue 129 - Context item generalized to
context value
* [16]3. Adjourned
Draft Minutes
Summary of new and continuing actions [0/7]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-016-08: RD to clarify how namespace comparisons are
performed.
* [ ] QT4CG-023-01: NW to review the stylesheets for functions across
XPath and XSLT
* [ ] QT4CG-025-03: MK to revise and expand technical detail in PR
#375
* [ ] QT4CG-026-01: MK to write a summary paper that outlines the
decisions we need to make on "value sequences"
* [ ] QT4CG-027-01: MK to update the text for next-match wrt type()
matching
* [ ] QT4CG-028-01: MK to summarize the options available wrt deep
equal and errors
1. Administrivia
1.1. Roll call [8/12]
Regrets: EP
* [ ] Anthony (Tony) Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF) [0:15-]
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [0:25-]
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [ ] Ed Porter (EP)
* [ ] C. M. Sperberg-McQueen (MSM)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [17]the agenda.
Accepted.
* MK: Maybe put issues on the list, not just PRs.
Perhaps the composite language for path language for next week? Issue
350?
* JL: Keep track of how many issues and PRs are open/closed.
* DN: Maybe also mix them, so that we don't discuss all the proposals
from the same person.
1.3. Approve minutes of the previous meeting
Proposal: Accept [18]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [19]is scheduled for Tuesday, 4 April 2023.
No regrets heard.
1.5. Review of open action items [1/7]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-016-08: RD to clarify how namespace comparisons are
performed.
* [ ] QT4CG-023-01: NW to review the stylesheets for functions across
XPath and XSLT
* [ ] QT4CG-025-03: MK to revise and expand technical detail in PR
#375
* [X] QT4CG-025-04: RD to remove the note in 15.5.15 of functions and
operators.
* [ ] QT4CG-026-01: MK to write a summary paper that outlines the
decisions we need to make on "value sequences"
* [ ] QT4CG-027-01: MK to update the text for next-match wrt type()
matching
2. Technical Agenda
2.1. PR #408: Fix issue #398 (clash with constructor functions)
See PR [20]pull request #408
* MK: Makes explciit that you can't have two fucntion siwht the sam
ename
* RD: Do we need to handle special handling for XSD 1.1.
+ ... You could have the case where you're declaring a name that
clashes with 1.1
* MK: The XML Schema namespace is reserved anyway.
* DN: Maybe we could have predefined namespaces where users cannot
declare their own functions.
* MK: That would be backwards incompatible; we already allow you to
use the same namespace for types and functions.
* DN: Maybe we could define a convention for this.
* MK: We do have reserved namespaces; this is question of whether
users can use the same namespace for types and functions.
Some discussion of the scope of this error. This is about user defined
types and functions, not system ones.
* CG: Will it be possible to use keyword argument syntax with type
constructor functions?
+ ... Can you use the keyword argument syntax?
* MK: We already have the rule that you can't have two functions with
the same name and arity, this proposal is just clarifying that
case.
Some discussion of keyword argument syntax. The name of the argument to
constructor functions is defined to be value.
* DN: What namespace are the constructor functions in?
* MK: They're in the namespace of the types.
Some further discussion of the practicality of reserving namespaces to
prevent users from defining types or functions.
Proposal: Accept the PR
Accepted.
2.2. PR #406: Revise xsl:array instruction and examples
See PR [21]pull request #406
* MK: The spec includes a draft for an xsl:array instruction in XSLT.
The complication is that with xsl:array you want to be able to
define any array including ones where you can have empty sequences
or other sequences, and this isn't very compatible with sequence
constructors.
MK reviews xsl:array, section 22.1 of the XSLT spec.
* MK: The use attribute lets you do construction and deconstruction
in a way similar to the array functions. This seems like a much
more suitable way to construct arrays in XSLT.
* JK: In the map case, we have xsl:map-entry, why doesn't
xsl:array-entry work?
* MK: You could do that, but you'd lose the ability to build arrays
using any kind of values. This makes the construction conventions a
matter of code style rather than baking them into the language.
* RD: Would it make sense to introduce parity on both sides? Have
xsl:array-entry for arrays and a use attribute on maps?
* MK: The most common use case by far is that the array consists of a
sequence of single items.
Some discussion of how the behavior of the construct shouldn't depend
on its content because you might want to, for example, refactor the
content into an xsl:apply-templates.
* RD: With array:members, you get a sequence of singleton maps.
Further discussion of how xsl:array-member wouldn't actually
encapsulate the result because you can't distinguish them by type.
* DN: Let's say I want to use xsl:array, is there anything I can do
that I can't do in pure XPath?
* MK: In the use cases I've done, I've found it very awkward to mix
the XPath approach with apply templates.
* DN: It would be valuable to post that use case. Couldn't we do this
by making a map with sequential integer keys and then have a cast
instruction of some sort?
* MK: Well, you don't want to have to allocate the numbers by hand.
Consider the first example, you wouldn't want to allocate numbers
for each string. Consider the second example, it answers both of
these questions.
* JK: On the bandwagon about parity with xsl:map and xsl:map-entry.
Can you apply-templates with an array instruction to populate it
with members in other templates?
* MK: It's supposed to make that possible; those were the use cases I
had in mind.
Proposal: Accept the PR
Accepted.
2.3. PR #404: Rework changes from action-qt4cg-019-01 to resolve persistent
conflicts.
See PR [22]pull request #404
* MK: This entirely editorial. It fixes a trivial error in
fn:tokenize and updates the change history.
Proposal: Accept the PR
Accepted.
2.4. PR #375: Context for default parameter values
See PR [23]pull request #375
* MK: I have an open action; we can't progress this right now.
2.5. PR #396: Deep-equal, no failure when comparing functions
See PR [24]pull request #396
Mike describes his attempt to address no failure use cases for
deep-equal.
* MK: If you have two function items that aren't arrays or maps, then
you use the existing rules for determinism. This relies on prose
already in the 3.1 spec.
+ ... One of the preconditions is that the processor is able to
determine that they're the same and that's implementation
defined.
+ ... You can always return false, but the note outlines some of
the cases where it might make sense to return true.
* RD: If I understand correctly, if you have the example that the
processor knows that you're referring to the arity 1 version of
fn:name in both cases, then it must or might return true?
* MK: It's not required. It's quite difficult to codify. Partial
function application and context come into play.
* RD: I'm not suggesting this for the case of partial function
application. That's a special intermediate function. I mean in the
case where you know you have the arity 1 fn:name in both cases.
* MK: Even if it's the identical expression, you have to make sure
that the context is the same. You might have the same variable
reference but the static context is different in one case.
* DN: I really respect the effort here, but all these debates can be
avoided and they show that trying to define these things is hard.
This could be much easier; just assert that all functions (except
maps and arrays) are the same or different (as we did for NaN or
INF). I don't care, I don't think these use cases occur in practice
often enough to worry about.
* MK: Part of the problem is that we use fn:deep-equal in other
contexts. For example, suppose that you use it for sorting or
grouping. Then if it doesn't have clean semantics, for example if
every item is equal to itself, then it isn't appropriate for some
of those cases.
* DN: Then we need a new function fn:error-free-comparitor that has
the semantics we need.
* MK: That's what this is trying to do.
* DN: I would be happier with just a new function.
* MK: Wouldn't that just move the problem to that new function?
Some continued discussion of how this could work.
* SF: When we're talking about function comparison, what is different
in the different use cases? One comaprison of functions is about
casting values. Another case might be trying to decide which
function to call. So those are different use cases. In JS there's
an analogy between "==" and "===".
* MK: We're not using doing this because there's a use case for
comparing functions, but there's a use ase for having a function
that compares anything without failing and has nice properties like
reflexivity and transitivity.
* SF: That's just going to raise the issue later with caching, etc.
* JL: I like this; it's going to be to some extent implementation
dependent. The early things are easy to compare, but later on it
gets harder and you can just return false.
* DN: I think JL and I are in complete agreement.
* JL: I'm not actually sure I am agreeing; this looks pretty good, we
don't need to go any deeper than the first few items on the list.
This doesn't raise errors and it's pretty easy to implement. You
can stop whenever it gets too deep.
* DN: That's what we agree on, we shouldn't go deeper. I think we
don't need to go deeper at all. We need a use case where precise
comparisons really matter. I'm not convinced there are any.
* JL: I thought that NaN was the one thing that isn't equal to
itself.
* MK: In deep equal it is.
* DN: Exactly. Everyone knows that NaN != NaN, but we decided that it
would be equal in deep equal. So we can make the same arbitrary
decision about functions.
Some discussion of what does or doesn't constitute the property of NaN
vs the property of functions.
Some discussion of how we can minimize surprise to users. Not all
languages follow IEEE specifications for comparing things like NaNs and
infinities.
* RD: On the one hand it is arbitrary, but on the other we aren't
just making things up. Saying that two function references that you
know are different are in fact equal goes against a users
expectation.
* DN: But the same is true of NaN!
2.6. PR #368: Issue 129 - Context item generalized to context value
See PR [25]pull request #368
* MK: I have an open action; we can't progress this right now.
3. Adjourned
None heard.
References
1. https://qt4cg.org/meeting/minutes/2023/03-28.html#minutes
2. https://qt4cg.org/meeting/minutes/2023/03-28.html#new-actions
3. https://qt4cg.org/meeting/minutes/2023/03-28.html#administrivia
4. https://qt4cg.org/meeting/minutes/2023/03-28.html#roll-call
5. https://qt4cg.org/meeting/minutes/2023/03-28.html#agenda
6. https://qt4cg.org/meeting/minutes/2023/03-28.html#approve-minutes
7. https://qt4cg.org/meeting/minutes/2023/03-28.html#next-meeting
8. https://qt4cg.org/meeting/minutes/2023/03-28.html#open-actions
9. https://qt4cg.org/meeting/minutes/2023/03-28.html#technical-agenda
10. https://qt4cg.org/meeting/minutes/2023/03-28.html#pr-408
11. https://qt4cg.org/meeting/minutes/2023/03-28.html#pr-406
12. https://qt4cg.org/meeting/minutes/2023/03-28.html#pr-404
13. https://qt4cg.org/meeting/minutes/2023/03-28.html#pr-375
14. https://qt4cg.org/meeting/minutes/2023/03-28.html#pr-396
15. https://qt4cg.org/meeting/minutes/2023/03-28.html#pr-368
16. https://qt4cg.org/meeting/minutes/2023/03-28.html#adjourned
17. https://qt4cg.org/meeting/agenda/2023/03-28.html
18. https://qt4cg.org/meeting/minutes/2023/03-21.html
19. https://qt4cg.org/meeting/agenda/2023/04-04.html
20. https://qt4cg.org/dashboard/#pr-408
21. https://qt4cg.org/dashboard/#pr-406
22. https://qt4cg.org/dashboard/#pr-404
23. https://qt4cg.org/dashboard/#pr-375
24. https://qt4cg.org/dashboard/#pr-396
25. https://qt4cg.org/dashboard/#pr-368
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Thursday, 30 March 2023 15:50:31 UTC