- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 13 Dec 2022 17:41:27 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m24jtz6vzz.fsf@saxonica.com>
Hello,
I’ve posted the draft minutes:
https://qt4cg.org/meeting/minutes/2022/12-13
QT4 CG Meeting 015 Minutes 2022-12-13
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/7]
* [3]1. Administrivia
+ [4]1.1. Roll call [7/14]
+ [5]1.2. Accept the agenda
+ [6]1.3. Next meeting
+ [7]1.4. Approve minutes of the previous meeting
+ [8]1.5. Review of open action items [3/4]
* [9]2. Technical Agenda
+ [10]2.1. Issue 281
+ [11]2.2. Review pull request #258: add array:index-where
(issue #114)
+ [12]2.3. Review pull request #259: parse-html (issue #74)
+ [13]2.4. Review pull request #261: fn:char (issue #121)
+ [14]2.5. Review pull request #268: type diagrams (issue #265)
+ [15]2.6. Review pull request #279: Rewrite XSLT ß10.3.4
(function overriding) for clarity
+ [16]2.7. Review pull request #284: Grammar for if-then w/o
else
+ [17]2.8. Issue #170, XPath "otherwise" operator
+ [18]2.9. Issue #114, array:index-where
+ [19]2.10. Issue #107, allow self::(a|b|c)
* [20]3. Any other business
* [21]4. 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-014-01: MK to propose new try-get functions for arrays,
maps, and (maybe) sequences
* [ ] QT4CG-015-01: MK to change the name of the argument to
array:index-where from $input to $array
* [ ] QT4CG-015-02: NW to improve the width of the diagrams, perhaps
multiple views
* [ ] QT4CG-015-03: NW to make sure the direction of the arrow is in
the legend
* [ ] QT4CG-015-04: NW to investigate of a dynamic presentation is
practical
* [ ] QT4CG-015-05: MK to raise a PR to resolve issue #107,
self::(a|b|c)
1. Administrivia
1.1. Roll call [7/14]
Regrets: BTW, CG, RD, and EP.
* [ ] Anthony (Tony) Bufort (AB)
* [ ] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [ ] 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)
* [ ] Liam Quin (LQ)
* [ ] Adam Retter
* [X] C. M. Sperberg-McQueen (MSM)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.
Welcome Sasha Firsov. A brief round of introductions.
* SF: I'm trying to be an open source contributor and web developer.
Doing architectural work, trying to put some work on W3C in order
to make decorated web applications a thing. When multiple
applications from different vendors meet on the same page, there
are technologies we need. Transformation is an essential part of
that. I'm hoping to make a bridge between HTML DOM and XSLT
communities.
* NW: Works for Saxonica. Been doing XML since there was XML. I
worked on the XProc specification.
* JL: Spent seven years working for Saxonica. Wrote the XSLT compiler
and XPath 3 compiler.
* MSM: Got interested in declarative markup in the late 1980s. Worked
on XML. Worked for W3C for a decade. Spent time on various working
groups.
* MK: I haven't been in the game as long as NW and MSM, only about 20
years. I've beeen developing Saxon all that time and became editor
of the XSLT spec on version 2.0.
* DN: I have been active in the XML space for maybe 20 years. Maybe
I'm most well known for the FXSL library for XSLT 1.0 then 2.0. Did
some presentations at conferences. I represented Microsoft on the
XSLT WG, but for the last 10 years I've been actively pushing for
pure XPath programming. You can see more about me by looking at the
proposals I've submitted.
1.2. Accept the agenda
Proposal: Accept [22]the agenda.
* NW: We'll skip the parse-html PR in RD's absence.
* DN: Two meetings ago, I was tasked with an action item, to clarify
the way function arguments are evaluated when a function returns a
function. I'd like to talk about issue #281.
Accepted with those amendments.
1.3. Next meeting
The next meeting [23]is scheduled for Tuesday, 20 December.
No regrets heard.
Reminder, the CG Will not meet on 27 December or 3 January.
1.4. Approve minutes of the previous meeting
Proposal: Accept [24]the minutes of the previous meeting.
Accepted.
1.5. Review of open action items [3/4]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
+ Continued
* [ ] QT4CG-014-01: MK to propose new try-get functions for arrays,
maps, and (maybe) sequences
+ Continued
* [X] QT4CG-014-02: MK to draft a spec for array:exists() and
array:empty() functions
* [X] QT4CG-014-03: MK to update PR #250 with the new names
2. Technical Agenda
2.1. Issue 281
* DN: Consider [25]this comment on the issue: if, in $f($x)($y), is
it possible for $y to be evaluated before $f($x)? If $f($x) returns
a constant function, is it still possible for $y to be evaulated?
What do the current rules say?
* MK: I'm reading section 4.4.2.1, evaluating dynamic function calls.
Step 1 is to evaluate the base expression, $f($x) to get a
function, then we ask if the arity matches the number in the
argument list. It doesn't so we raise a type error. Step 2 says
that we evaluate the arguments. I think in a numbered list we
assume the items are performed in the order of the list.
* DN: There were new rules for coertion which were proposed.
According to those rules, a type error would not be raised.
* MK: There's no coercion here because we're not binding the result
to a variable or function argument.
* DN: But this is the result of the function, and coercion rules
apply there too. So we're expecting a 1 argument function and we
get a 0 argument function. That would be wrapped in a function.
* MK: That would be true if they were applied, but I don't think they
are.
* MSM: You're (DN) saying that $f($x) is supposed to be a one
argument function, then we'll coerce it to be one. But we can't
know that here, so we won't coerce it. Do we have a declaration for
$f that it is a one argument function that returns a one argument
function?
* DN: My understanding is, the way the expression is written, it
expects the evaulation of $f to return a one argument function. My
understanding is that if it returns a constant function, we
shouldn't throw an arity expression. Maybe we should add a rule
that there is no arity exception. This is explicitly writing a
partial function evaluation.
* SF: It's about integrity of the language. There are a few different
things. If $f returns another function or "none", we could make the
evaluation of $y conditional on that invocation. Consider
JavaScript's "?.". Do you want $x and $y both to be evaluated?
That's a question for the programmer. If you do want to evaluate
both, you would create a function that will accept arguments $x and
$y, then invoke $f inside that. Quite often folks in software
development, use the arguments just to assure that it's evaluated.
In JavaScript, you can use a comma separator which means everything
will be evaluated.
* DN: If you could add your comment to this thread, that might be
easier to understand. I just wanted to pose the question, I think
the right answer is that $y shouldn't be evaluated until the result
of $f is returned.
* NW: I thought Mike's prose was clear about the order, but it's
unclear about the arity.
* MSM: Do we do lists in order?
* MK: It's certainly true that if the first raises an error, you
don't do the second.
* MSM: Unless otherwise specified, shouldn't an implementation be
allowed to evaluate $y greedily?
* MK: We don't have that level of formality in the specifications.
* DN: I think this particular example should be in the specification.
* NW: Let's take this up again next week. Several folks who commented
on the thread aren't here today.
* JL: I've been looking at 4.4.4, the function coercion rules, is DN
suggesting that the type of the left hand thing is determined by
the existence of the argument. Because it has a single arity, he's
implying that the function coercion rules apply, and I can't see
that.
* DN: I've asked several times, if the coercion rules apply only to
the function or to the return value. I've been consistently told
that it applies to the return.
* MK: But they only apply where there's a declared required type. In
this case, there's an implicit requirement (like a + operator
implicitly requires a number), but there isn't an explicit type.
* DN: Then my proposal is to think about changing the rules, because
I think this is only logical. Why should we make any kind of
exclusion from the rules here?
* MK: It's a tenable situation, we could apply that rule here.
* MSM: If we declare $f as an arity one function that returns an
arity one function, then presumably the coercion rules do apply.
* DN: This seems like casting in C#.
Some further discussion of how the new corecion rules apply before
breaking off until next week.
2.2. Review pull request #258: add array:index-where (issue #114)
See [26]pull request #258
Mike leads us through the change.
* MK: There was a comment that $input should be named $array.
ACTION QT4CG-015-01: MK to change the name of the argument to
array:index-where from $input to $array
Proposal: accept this PR with the name change.
Accepted.
2.3. Review pull request #259: parse-html (issue #74)
See [27]pull request #259
Skipped this week.
2.4. Review pull request #261: fn:char (issue #121)
See [28]pull request #261
Skipped this week.
2.5. Review pull request #268: type diagrams (issue #265)
See [29]pull request #268
Norm introduces the diagrams.
* MK: It would be nice if they were scaled to fit.
* NW: Yes, but then they'd illegible.
* SF: There are other techniques that could be used to make them fit.
* NW: Yes, but these are generated, so manual positioning isn't a
practical option.
* DN: How about rotating the wide one 90 degrees?
* NW: Maybe. But only if we rotate the text too, otherwise the first
row is too wide.
* MSM: Two suggestions and a question. For the first figure, make the
lgend verical. The secondl ooks promising to me, I think you might
be able to get what you need by specifying three ranks. My question
is, what is the meaning of the directional arrow? I wonder if
people will find it more intiutive if the arrow meant
is-the-parent-of/basetype-of and went the other way.
* NW: I did it that way because thaty's the way they were in 3.1.
Some discussion of UML conventions.
* MSM: I think arrows going the other way would be a little more
intuitive, but the meaning of the directional arrow should be in
the legend.
* MK: UML does them that way, whether you like it or not
* MSM: Okay.
* JK: Maybe just do an XML tree for the really wide diagram?
Proposal: these diagrams are an improvement, accept this PR
Accepted
ACTION QT4CG-015-02: NW to improve the width of the diagrams, perhaps
multiple views ACTION QT4CG-015-03: NW to make sure the direction of
the arrow is in the legend
* DN: There are a number of JavaScript controls that provide
expanding and collapsing.
ACTION QT4CG-015-04: NW to investigate of a dynamic presentation is
practical
2.6. Review pull request #279: Rewrite XSLT ß10.3.4 (function overriding) for
clarity
See [30]pull request #279
* MK: This is just an attempt to clarify the presentation; there
aren't any tehcnical changes.
+ ... We've taken a section that bundled together three things
about overriding and made them separate.
+ ... There are rules about package import precedence, extension
functions, and then override in a used package.
Proosal: Accept this PR.
Accepted.
2.7. Review pull request #284: Grammar for if-then w/o else
See [31]pull request #284
Skipped this week.
2.8. Issue #170, XPath "otherwise" operator
MK [32]proposes that [33]this issue may be ready to be decided.
* MK: Does anyone remember why we postponed this issue? There's no
explicit action waiting to be done.
No, we don't. NW to make sure it's higher on the agenda next week.
2.9. Issue #114, array:index-where
MK [34]proposes that [35]this issue may be ready to be decided
Resolved by the earlier PR.
2.10. Issue #107, allow self::(a|b|c)
MK [36]proposes that [37]this issue may be ready to be decided.
* MK: Is this worth doing? I don't want to spend the time on the PR
unless there's general agreement that it's a good idea.
* MSM: How much violence does this do to the grammar?
* MK: Not much, it just allows a union.
* MSM: As long as we can be sure it isn't ambiguious.
ACTION QT4CG-015-05: MK to raise a PR to resolve issue #107,
self::(a|b|c)
3. Any other business
None heard.
4. Adjourned
References
1. https://qt4cg.org/meeting/minutes/2022/12-13#minutes
2. https://qt4cg.org/meeting/minutes/2022/12-13#new-actions
3. https://qt4cg.org/meeting/minutes/2022/12-13#administrivia
4. https://qt4cg.org/meeting/minutes/2022/12-13#roll-call
5. https://qt4cg.org/meeting/minutes/2022/12-13#agenda
6. https://qt4cg.org/meeting/minutes/2022/12-13#next-meeting
7. https://qt4cg.org/meeting/minutes/2022/12-13#approve-minutes
8. https://qt4cg.org/meeting/minutes/2022/12-13#open-actions
9. https://qt4cg.org/meeting/minutes/2022/12-13#technical-agenda
10. https://qt4cg.org/meeting/minutes/2022/12-13#issue-281
11. https://qt4cg.org/meeting/minutes/2022/12-13#pr-array-index-where
12. https://qt4cg.org/meeting/minutes/2022/12-13#pr-parse-html
13. https://qt4cg.org/meeting/minutes/2022/12-13#pr-fn-char
14. https://qt4cg.org/meeting/minutes/2022/12-13#pr-type-diagrams
15. https://qt4cg.org/meeting/minutes/2022/12-13#pr-xslt-function-override
16. https://qt4cg.org/meeting/minutes/2022/12-13#pr-grammar-if-then-else
17. https://qt4cg.org/meeting/minutes/2022/12-13#issue-170
18. https://qt4cg.org/meeting/minutes/2022/12-13#issue-114
19. https://qt4cg.org/meeting/minutes/2022/12-13#issue-107
20. https://qt4cg.org/meeting/minutes/2022/12-13#any-other-business
21. https://qt4cg.org/meeting/minutes/2022/12-13#adjourned
22. https://qt4cg.org/meeting/agenda/2022/12-13.html
23. https://qt4cg.org/meeting/agenda/2022/12-20.html
24. https://qt4cg.org/meeting/minutes/2022/12-06.html
25. https://github.com/qt4cg/qtspecs/issues/281#issuecomment-1336491005
26. https://qt4cg.org/dashboard/#pr-258
27. https://qt4cg.org/dashboard/#pr-259
28. https://qt4cg.org/dashboard/#pr-261
29. https://qt4cg.org/dashboard/#pr-268
30. https://qt4cg.org/dashboard/#pr-279
31. https://qt4cg.org/dashboard/#pr-284
32. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0017.html
33. https://github.com/qt4cg/qtspecs/issues/170
34. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0017.html
35. https://github.com/qt4cg/qtspecs/issues/114
36. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0017.html
37. https://github.com/qt4cg/qtspecs/issues/107
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 13 December 2022 17:42:43 UTC