- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 20 May 2025 17:32:39 +0100
- To: public-xslt-40@w3.org
Hello,
Here are the draft minutes from today’s meeting:
https://qt4cg.org/meeting/minutes/2025/05-20.html
QT4 CG Meeting 122 Minutes 2025-05-20
[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
+ [11]1.3. Approve minutes of the previous meeting
+ [12]1.4. Next meeting
+ [13]1.5. Review of open action items [0/7]
+ [14]1.6. Review of open pull requests and issues
o [15]1.6.1. Blocked
o [16]1.6.2. Merge without discussion
* [17]2. Technical agenda
+ [18]2.1. Review of pull requests
+ [19]2.2. PR #2001: 1085 Revert fn:sort to the 3.1 spec;
introduce fn:sort-by
+ [20]2.3. PR #1991: 835 Add built-in named record types to
static context
+ [21]2.4. PR #2008: 2004 Add xsl:xpath instruction
+ [22]2.5. PR #2006: 2005 Add fn:apply-templates function
* [23]3. Any other business
* [24]4. Adjourned
Draft Minutes
Summary of new and continuing actions [0/7]
* [ ] QT4CG-082-02: DN to work with NW to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-112-01: JLO to propose a concrete example that uses "."
in a ~%method~s.
* [ ] QT4CG-116-01: Add a specific error code for unsupported options
on doc and doc-available
* [ ] QT4CG-118-01: MK to make an incorrect type raise an error in
#1906
* [ ] QT4CG-119-02: MK to add a note about how schema composition is
done for multiple options
* [ ] QT4CG-021-01: MK to raise a new issue which may propose a
subset of the QNameLiteral which doesn't permit a namespace.
* [ ] QT4CG-121-02: MK to fix removal of default values in the
options for fn:serialize()
* [ ] QT4CG-122-01: MK to add more tutorial material to xsl:select.
1. Administrivia
1.1. Roll call [11/12]
Regrets: BTW
* [X] David J Birnbaum (DB)
* [X] Reece Dunn (RD)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW) Scribe. Chair.
1.2. Accept the agenda
Proposal: Accept [25]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Thanks again to JWL.
Proposal: Accept [26]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting is scheduled for 27 May 2025.
No regrets heard.
1.5. Review of open action items [0/7]
(Items marked [X] are believed to have been closed via email before
this agenda was posted.)
* [ ] QT4CG-082-02: DN to work with NW to come to agreement on the
fn:ranks proposal
* [ ] QT4CG-112-01: JLO to propose a concrete example that uses "."
in a ~%method~s.
* [ ] QT4CG-116-01: Add a specific error code for unsupported options
on doc and doc-available
* [ ] QT4CG-118-01: MK to make an incorrect type raise an error in
#1906
* [ ] QT4CG-119-02: MK to add a note about how schema composition is
done for multiple options
* [ ] QT4CG-021-01: MK to raise a new issue which may propose a
subset of the QNameLiteral which doesn't permit a namespace.
* [ ] QT4CG-121-02: MK to fix removal of default values in the
options for fn:serialize()
1.6. Review of open pull requests and issues
This section summarizes all of the issues and pull requests that need
to be resolved before we can finish. See [27]Technical Agenda below for
the focus of this meeting.
1.6.1. Blocked
The following PRs are open but have merge conflicts or comments which
suggest they aren't ready for action.
* PR [28]#1883: 882 Replace fn:chain by fn:compose
* PR [29]#1283: 77b Update expressions
* PR [30]#1062: 150bis revised proposal for fn:ranks
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 [31]#1999: 1992 Correct type of constructor function in
schema-type-record
* PR [32]#1998: 1997 Correct nesting of item coercion rules
Proposal: merge without discussion.
Accepted.
* MK: I found a typo in 1999; I fixed it.
2. Technical agenda
2.1. Review of pull requests
2.2. PR #2001: 1085 Revert fn:sort to the 3.1 spec; introduce fn:sort-by
See PR [33]#2001
MK introduces the issue. In supporting multiple sort keys and
descending sort keys left us with four rather complex parameters. Let's
put fn:sort back and start over.
* MK: This makes fn:sort a subset of fn:sort-by and it's defined in
terms of the new fn:sort-by function.
MK explains the signature and semantics of fn:sort-by.
* MK: fn:array-sort and fn:array-sort-by are changed in the
corresponding way.
* JWL: We now have a trend that where we had complex sequence of
arguments, we're now using records. Are there other places where
this is likely to be of benefit?
* MK: Not that immediately come to mind. I have an fn:apply-templates
function on the table that uses it.
* JWL: Does it decrease the ability to pick up errors?
* MK: I'm not sure, the type signature says what can be in the
record.
* DN: I think that this is a good proposal. In the existing fn:sort
function, we had this unpleasant experience that we had to specify
an empty collation.
+ ... But I got the impression that collation is still before
order. It seems to me that collation is the least frequently
encountered argument.
* MK: They're now by name; you can specify them in any order or leave
them out if you want.
Some discussion of the use of names vs. positions.
* RD: Would it make sense to define the record as a named record type
so we could share it between the two functions?
* MK: It's a different record for arrays. But, yes, we have a
separate proposal about named record types.
* JK: I fear that people will not understand, and will be confused
by, fn:sort-by vs fn:sort-with. Do we need both?
* MK: It's a good question. I think there probably are sorts where
defining a comparitor function is easier.
+ ... I wouldn't be a very strong defender of fn:sort-with, but
it can be useful.
* JK: Then fn:sort-with needs a more compelling example.
* CG: I think it would be nice to keep fn:sort-with. There was
agreement then that it can be helpful to have a comparitor
function. With regard to the current proposal, I only have some
minor issues.
Some discussion of a sequence vs. a value.
* CG: The examples are pretty much the same as for fn:sort, it might
be nice to have examples that highlight the features of fn:sort-by.
* MK: I kept the simple examples to encourage people to learn only
one of them.
* DN: I was also a bit confused by fn:sort-by vs fn:sort-with. I
think that the difference between the two functions should be more
clearly stated.
* JWL: JK's point about fn:sort-with; I think I've used it to sort
vectors where it's very useful to have a comparitor function. Cases
where you have big structures that you want to compare bit by bit
are the usual case.
Proposal: accept this PR.
Accepted.
2.3. PR #1991: 835 Add built-in named record types to static context
See PR [34]#1991
* MK: The trigger for this is that we have test cases that don't work
because we generate test cases that say a function is an instance
of its signature and the signatures in the spec use named record
types. But they aren't defined to be part of the static context so
you can't use them.
+ ... This PR adds them to the static context.
* MK: In F&O, the named record types are listed in appendix C.
* MK: I did not attempt to review the names of the types or the
consistency of they're definition. The fact that we have them all
listed in one place makes that easier.
* JLO: We have six built in record types, but what about all the
options. Why aren't they here?
* MK: That's a good question. The function signatures don't have a
strict type for the options. But we could define a record type for
every options parameter.
+ ... But there's work to be done there.
* RD: This is just adding these names; the machinery to do that
already exists through the definition of the static context which
references named record types.
* MK: Yes.
* RD: And the syntax within the XSLT and XQuery specs defines record
types.
+ ... This is equivalent to saying that the static context
includes a declaration.
* MK: Yes.
* DN: JLO and I have an action to systemizing the record types in the
specifications.
+ ... What we plan to do is have an appendix that lists all the
option types in an appendix.
+ ... I think it would be very helpful to have all the options
in the static context.
* MK: Yes, that raises another point. By making these named record
types, you also get a constructor function for them.
+ ... That should have been brought out more strongly.
* NW: I think it'll require some work to come up with good names.
Proposal: accept this PR.
Accepted.
2.4. PR #2008: 2004 Add xsl:xpath instruction
See PR [35]#2008
* MK: This is primarily motivated by the fact that I was looking at
construction of arrays and maps in XSLT. The most convenient way
was to write path expressions. Those became quite long and then you
hit the problem of attribute value normalization and you can only
use one delimiter.
* MK: What this does is allow you to write expressions in an
xsl:xpath instruction.
MK reviews the instruction.
* JWL: Now you get this case where you've got something that's like
sequence but in one case the text inside becomes the sequence, but
in this case the text becomes an expression. I can see this causing
interesting confusion at first.
* DN: What's the difference between xsl:xpath and xsl:evaluate?
* MK: The difference is that xsl:evaluate allows you to construct an
expression from a string.
* DN: Doesn't that mean I can use xsl:evaluate always?
* MK: Not really, xsl:evaluate doesn't have access to the static
context or the variables.
* DN: I'd like to see a comparison of xsl:xpath, xsl:evaluate, and
xsl:transform.
* WP: I'd like to see the comparison expanded. How does this interact
with text value templates?
* MK: The xsl:xpath instruction can't contain text value templates.
* WP: I think it's intriguing that there's a difference between this
and evaluate. So I'd like to see the examples sketched out more.
* MK: Where this is coming from is that XPath is becoming more and
more powerful therefore it's no longer just for writing one liners.
So it's now inconvenient in XML attributes.
* JWL: If you wanted to do a similar thing with xsl:evaluate, you'd
have to put that text in a variable. If you put it directly in a
select, you have to do all the quoting.
* MK: You'd also have to pass $title and $author as parameters.
* MK: You want to do construction this way because it looks like
JSON, which is what users expect of maps and arrays.
* RD: In the current spec, you're not allowing nested XSLT constructs
like xsl:choose or xsl:if, is there a motivation for that?
* MK: It's very hard to do. Evan Lenz once had a proposal for
allowing XPath and XSLT to be mixed. It's very hard to define the
semantics of that.
* RD: I can see in this example that if you wanted to add a subtitle
but its optional, then that becomes fiddlier.
* MK: You can do that with an XPath conditional. What holds you back
is apply templates, which is why there's a separate proposal for
that.
* WP: I think you might consider calling this xsl:xpath-literal. I
think I'm beginning to appreciate the use case. But I'm concerned
about making the use case clearer. The overlap with xsl:evaluate is
an issue.
* JK: xsl:select might be a good name.
* NW: I think xsl:select would be a good name.
* DN: I'm confused. Does this xsl:xpath just define the expression or
does it also evaluate it?
* MK: It evaluates it.
Some discussion of the name.
* DN: I think that select is a little bit overloaded in XSLT. Maybe
find another name.
Some discussion of where it can and can't be used.
* [ ] QT4CG-122-01: MK to add more tutorial material to xsl:select.
Proposal: accept this PR, with xsl:xpath named xsl:select.
Accepted.
2.5. PR #2006: 2005 Add fn:apply-templates function
See PR [36]#2006
* MK: This has similar motivation. It's an XSLT-only function.
MK reviews the PR.
* MK: This gives you the mode as a variable for free. You can also
construct parameter names dynamically. I'm a little uneasy, but
it's a bit like functions becoming dynamic. You can adapt.
+ ... I have said that the mode must be explicitly declared in
the package and it must be public.
+ ... Modes aren't public by default, but if you're going to do
it dynamically you have to.
* JK: What about a call templates function?
* MK: No, because I hate call template.
* WP: This is cool. If you apply templates to "." can you traverse
yourself?
* MK: There's no default, you have to specify it.
* JWL: Does this cause real implementation problems?
* MK: It does mean that parameter names have to be around at run
time, but in practice that's probably true anyway.
+ ... With xsl:call-template you know what template your'e
calling, but you can't do that with apply templates.
Proposal: accept this PR.
Accepted.
3. Any other business
None heard.
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/2025/05-20.html#minutes
7. https://qt4cg.org/meeting/minutes/2025/05-20.html#new-actions
8. https://qt4cg.org/meeting/minutes/2025/05-20.html#administrivia
9. https://qt4cg.org/meeting/minutes/2025/05-20.html#roll-call
10. https://qt4cg.org/meeting/minutes/2025/05-20.html#agenda
11. https://qt4cg.org/meeting/minutes/2025/05-20.html#approve-minutes
12. https://qt4cg.org/meeting/minutes/2025/05-20.html#next-meeting
13. https://qt4cg.org/meeting/minutes/2025/05-20.html#open-actions
14. https://qt4cg.org/meeting/minutes/2025/05-20.html#open-pull-requests
15. https://qt4cg.org/meeting/minutes/2025/05-20.html#blocked
16. https://qt4cg.org/meeting/minutes/2025/05-20.html#merge-without-discussion
17. https://qt4cg.org/meeting/minutes/2025/05-20.html#technical-agenda
18. https://qt4cg.org/meeting/minutes/2025/05-20.html#technical-prs
19. https://qt4cg.org/meeting/minutes/2025/05-20.html#pr-2001
20. https://qt4cg.org/meeting/minutes/2025/05-20.html#pr-1991
21. https://qt4cg.org/meeting/minutes/2025/05-20.html#pr-2008
22. https://qt4cg.org/meeting/minutes/2025/05-20.html#pr-2006
23. https://qt4cg.org/meeting/minutes/2025/05-20.html#any-other-business
24. https://qt4cg.org/meeting/minutes/2025/05-20.html#adjourned
25. https://qt4cg.org/meeting/agenda/2025/05-20.html
26. https://qt4cg.org/meeting/minutes/2025/05-13.html
27. https://qt4cg.org/meeting/minutes/2025/05-20.html#technical-agenda
28. https://qt4cg.org/dashboard/#pr-1883
29. https://qt4cg.org/dashboard/#pr-1283
30. https://qt4cg.org/dashboard/#pr-1062
31. https://qt4cg.org/dashboard/#pr-1999
32. https://qt4cg.org/dashboard/#pr-1998
33. https://qt4cg.org/dashboard/#pr-2001
34. https://qt4cg.org/dashboard/#pr-1991
35. https://qt4cg.org/dashboard/#pr-2008
36. https://qt4cg.org/dashboard/#pr-2006
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 20 May 2025 16:32:47 UTC