- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 17 Jan 2023 17:10:52 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2k01lxez9.fsf@saxonica.com>
Hi folks,
The draft minutes are online:
https://qt4cg.org/meeting/minutes/2023/01-17.html
QT4 CG Meeting 018 Minutes 2023-01-17
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/17]
* [3]1. Administrivia
+ [4]1.1. Roll call [9/14]
+ [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 [5/17]
* [9]2. Technical Agenda
+ [10]2.1. Review pull request #284: Grammar for if-then w/o
else
+ [11]2.2. Review pull request #304
+ [12]2.3. Review pull request #290 (function type hierarchy)
+ [13]2.4. Review pull request #286: allow child::(a|b|c)
+ [14]2.5. Issue #299 (formerly #281)
* [15]3. Any other business
Draft Minutes
Summary of new and continuing actions [0/17]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-015-02: NW to improve the width of the diagrams, perhaps
multiple views
* [ ] QT4CG-015-04: NW to investigate of a dynamic presentation is
practical
* [ ] QT4CG-016-02: NW to add an ed-note indicating when it was
approved.
* [ ] QT4CG-016-03: RD to add a note clarifying "known character
encoding"
* [ ] QT4CG-016-04: RD to add a note clarifying the "*"/"*"
html/version combination
* [ ] QT4CG-016-05: RD to add a "todo" noting the dependency on
keyword arguments
* [ ] QT4CG-016-06: RD to reword the introduction to mapping to
clarify who's doing the mapping
* [ ] QT4CG-016-07: NW to make an issue about the problems of
document-uri uniqueness
* [ ] QT4CG-016-08: RD to clarify how namespace comparisons are
performed.
* [ ] QT4CG-016-09: RD to add a note stating that the local name
should always be lowercase
* [ ] QT4CG-016-10: RD to consider how to clarify parsed entity
parsing.
* [ ] QT4CG-018-01: MK to make a PR that removes ternary expressions.
* [ ] QT4CG-018-02: MK to review "In this notation, function-name, in
bold face..." in 1.5.
* [ ] QT4CG-018-03: MK to address the issues raised in the commeont
on PR 304
* [ ] QT4CG-018-04: MK to consider the editorial suggestion on "a
predicate is not part of a step"
1. Administrivia
1.1. Roll call [9/14]
Regrets: BTW
* [ ] Anthony (Tony) Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [ ] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] 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.
1.2. Accept the agenda
Proposal: Accept [16]the agenda.
Accepted.
1.3. Approve minutes of the previous meeting
Proposal: Accept [17]the minutes of the previous meeting.
Accepted.
1.4. Next meeting
The next meeting [18]is scheduled for Tuesday, 24 January 2023.
No regrets heard.
1.5. Review of open action items [5/17]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-015-02: NW to improve the width of the diagrams, perhaps
multiple views
* [X] QT4CG-015-03: NW to make sure the direction of the arrow is in
the legend See PR #308
* [ ] QT4CG-015-04: NW to investigate of a dynamic presentation is
practical
* [ ] QT4CG-016-02: NW to add an ed-note indicating when it was
approved.
* [ ] QT4CG-016-03: RD to add a note clarifying "known character
encoding"
* [ ] QT4CG-016-04: RD to add a note clarifying the "*"/"*"
html/version combination
* [ ] QT4CG-016-05: RD to add a "todo" noting the dependency on
keyword arguments
* [ ] QT4CG-016-06: RD to reword the introduction to mapping to
clarify who's doing the mapping
* [ ] QT4CG-016-07: NW to make an issue about the problems of
document-uri uniqueness
* [ ] QT4CG-016-08: RD to clarify how namespace comparisons are
performed.
* [ ] QT4CG-016-09: RD to add a note stating that the local name
should always be lowercase
* [ ] QT4CG-016-10: RD to consider how to clarify parsed entity
parsing.
* [X] QT4CG-017-01: MK to clarify the characters numbers in points 1
and 2 of fn:char
* [X] QT4CG-017-02: MK to change the order of points to 3, 4, 1, 2 in
fn:char
* [X] QT4CG-017-03: SF to follow up on whether or not the browser has
all the Unicode and emoji names.
+ [19]https://lists.w3.org/Archives/Public/public-xslt-40/2023Ja
n/0016.html
* [X] QT4CG-017-04: MK to revise PR #284 to include an optional else
`else'
2. Technical Agenda
2.1. Review pull request #284: Grammar for if-then w/o else
See [20]pull request #284. Some discussion [21]last week.
* MK thinks he had a clear action last week; has updated PR #284
* MK reviews #284
+ ... MK reviews 4.15, Conditional Expressions
* MSM: I persuaded myself this wasn't ambiguous because of the
braces, but I'm worried about an if within an else that isn't
braced.
* RD: Do you mean a braced if with a regular if inside it?
Some attempt to construct an example on the fly...
At this point, some of the discussion is about examples presented in
the chat window. The scribe does his best...
* MSM adds to chat:
if (condition) { then-clause } else { else-clause }
but in the case that the else-clause is a conditional, then
if (condition) { then-clause } if (c2) { then-2 } else {
else-clause }
* DN: If we substitute ExprSingle with another IfExpr and another
unbraced action, then we'll have else ambiguity.
* RD observes there's a typo in the example
* MSM: Else ambiguity an only arise if you have conditions in the
then clause. Let's consider:
if (condition) { then-clause } else if (c2) { then-2 } else {
else-clause }
if (condition) { then-clause } else { if (c2) { then-2 } else {
else-clause } }
* MSM: What I was expecting to see required, but is only allowed, is
that you can put the else clause in a braces.
* MSM: I was concerned about the first case but I think it's
unambiguous.
* MK: The special case of the intermede else-if clauses are only
allowed a "then" branch, they aren't allowed their own "else"
branches.
* RD: One way to view this is that it's kind of similar to switch and
type-switch statements.
* MSM: I believe it is in fact unambigous.
* MK: It requires a single token lookahead but it's unambiguous.
* RD: Another thing with respect to grammar ambiguity: this pattern
is common in a lot of languages like C/C++/Java/C#/JavaScript/etc.
* MSM: Yes, but if you transcribe the grammar for C into clean
grammar formalism, you will find that they're full of ambiguities!
They're expecting manually written parsers. There are a lot of ad
hoc rules and my life is not completely filled with regret that we
didn't hold the line on ad hoc rules better.
* RD: There are BNF grammars for C.
* MSM: Yes, and if you put them through a grammar analysis tool, you
will find huge amounts of ambiguity. At least I did!
Some questions about the ambiguity of "C" arise. MSM agrees to dig up
his notes.
The group seems satisfied that this is not ambiguous.
Proposal: Accept this PR.
Accepted.
* MK: What is the sentiment of the group about the ternary
conditional?
* CG: Now that we have two alternatives for if/then, I could skip
ternary expressions.
Some voices of agreement.
ACTION QT4CG-018-01: MK to make a PR that removes ternary expressions.
2.2. Review pull request #304
See [22]pull request #304. This is Mike's PR #292 redrafted by Norm.
Mike writes:
I regret that this has turned into a bit of an omnibus PR. The main
changes are:
* Fix validity issues with the function catalog and its schema (Issue
291)
* Convert all functions to use a single signature with optional
parameters (Issue 70)
* Extend the function catalog to handle record definitions (Issue
257)
* Fix the (trivial) bug with properties of fn:path (Issue 288)
* Add introductory text concerning the handling of operators (Issue
35)
MK reviews PR #304.
* MK: The primary aim was to change the function signatures.
+ ... For example, fn:string-join has one signature instead of
two.
+ ... There may need to be more ammendments to the prose if we
find mentions of particular signatures.
* MK: I went on to address the title of the document in section 1.1
Operators.
* DN: Are all the functions from 3.1 that have more than one overload
convert to this new format?
* MK: The vast majority are, but there are one or two that you can't.
For example, the single-argument form of fn:tokenize doesn't have
an equivalent form with default arguments.
* DN: If this is only partially done, we probably need an issue to
review it.
* NW: The other thing you mentioned was fn:path
* MK: That's a simple typo I fixed.
* JL: Are all the operators functionable now?
* MK: All the first-order operators are.
* MSM: In section 1.5 Function signatures and descriptions, strictly
speaking it's the local name of the function. The name of the
function is "fn:"-function name.
* MK: In that paragraph, it should say fn:function-name
Some discussion of whether it would be better to use fn:function-name
or to refer to the function-name as the local name.
ACTION QT4CG-018-02: MK to review "In this notation, function-name, in
bold face..." in 1.5.
* MK: I raised some errata in the PR entry, but I propose to fix them
after the merge.
ACTION QT4CG-018-03: MK to address the issues raised in the commeont on
PR 304
* RD: I think I raise an issue for the "**" in the signature of
fn:all-different, issue #62
Proposal: accept this PR
Accepted.
2.3. Review pull request #290 (function type hierarchy)
See [23]pull request #290. This PR seems to be against an earlier draft
so the diff markup is a bit odd. I believe the only intended change is
the [24]paragraph in 2.9.1 Functions.
* NW tries to explain his remark about 2.9.1
* MK: This change corrects the incorrect statement that there's a
hierarchy of function types. The rules for subtyping functions mean
that the graph of subtypes of functions isn't a heirarchy. It's
acyclic but not hierarchic.
Proposal: accept this PR
Accepted.
2.4. Review pull request #286: allow child::(a|b|c)
See [25]pull request #286.
* MK reviews the PR
+ ... This primarily effects XPath but also impacts XSLT.
+ ... In 4.6.2.2 MK reviews the production changes
+ ... The only other complication is where that fits into the
grammar.
+ ... There's a change in 4.6.3 about reverse axes
* JL: Is the union required to be flat in the grammar? I can't
bracket inside the brackets?
* MK: Yes, that was a deliberate simplification.
* MSM: I found the explanation, "the predicate is not part of a step"
a bit opaque. Would it be clearer to say that the predicate applies
to the result of a union. That will remind some readers that unions
sort into document order.
ACTION QT4CG-018-04: MK to consider the editorial suggestion on "a
predicate is not part of a step"
* RD: Thinking about grammatical ambiguities, in addition to applying
to forward and backwards steps it also applies to abbreviated
steps.
* MK: Yes.
+ ... Moves to 4.6.5 to show that you can't have a union node
test all on it's own.
* MK: In XSLT...
+ ... It's all about how patterns and precedence interact with
these changes.
+ ... The default precedence is extended to cover this new case.
* MSM: Since the union node tests need to be flat, unlike a union
expression, the union node test will always produce patterns with
the same priority, no?
* MK: No, because...
* JL: Yes, because...
Some discussion ensues.
* MK: No, it can be a NameTest and a NameTest can have a wild card.
* MSM: Right. Thank you.
Proposal: accept this PR
Accepted.
2.5. Issue #299 (formerly #281)
We had [26]some discussion of [27]#281 previously, but no resolution.
Awaiting more feedback from the CG in the issue.
* NW: Did you get more feedback?
* DN: Yes, there was a thread about additional guards. That got
several informal approvals.
+ ... We made progress in formalizing what lazy means.
+ ... We can have lazy() as a function with a single argument.
+ ... It's body is another function with zero arguments and its
body is the expression.
+ ... If we a variable of type expression, then the result must
not be inlined.
+ ... Still waiting for some feedback from RD about laziness on
a compound structure.
+ ... RD proposed wildcard notation which means we don't need
other parts of the object.
* DN: I suggest we leave this open and give other people a chance to
review.
3. Any other business
References
1. https://qt4cg.org/meeting/minutes/2023/01-17#minutes
2. https://qt4cg.org/meeting/minutes/2023/01-17#new-actions
3. https://qt4cg.org/meeting/minutes/2023/01-17#administrivia
4. https://qt4cg.org/meeting/minutes/2023/01-17#roll-call
5. https://qt4cg.org/meeting/minutes/2023/01-17#agenda
6. https://qt4cg.org/meeting/minutes/2023/01-17#approve-minutes
7. https://qt4cg.org/meeting/minutes/2023/01-17#next-meeting
8. https://qt4cg.org/meeting/minutes/2023/01-17#open-actions
9. https://qt4cg.org/meeting/minutes/2023/01-17#technical-agenda
10. https://qt4cg.org/meeting/minutes/2023/01-17#pr-grammar-if-then-else
11. https://qt4cg.org/meeting/minutes/2023/01-17#h-6142CC30-B435-4A23-8FEB-C7C5DAA040DD
12. https://qt4cg.org/meeting/minutes/2023/01-17#h-E5807567-F254-497C-80BE-B6F7458D3FA7
13. https://qt4cg.org/meeting/minutes/2023/01-17#h-4A6AF901-EAAE-4483-929B-3C72C53E1685
14. https://qt4cg.org/meeting/minutes/2023/01-17#h-EF7A6EB3-0BDC-4E8E-A805-8461FD43964C
15. https://qt4cg.org/meeting/minutes/2023/01-17#any-other-business
16. https://qt4cg.org/meeting/agenda/2023/01-17.html
17. https://qt4cg.org/meeting/minutes/2023/01-10.html
18. https://qt4cg.org/meeting/agenda/2023/01-24.html
19. https://lists.w3.org/Archives/Public/public-xslt-40/2023Jan/0016.html
20. https://qt4cg.org/dashboard/#pr-284
21. https://qt4cg.org/meeting/minutes/2023/01-10.html
22. https://qt4cg.org/dashboard/#pr-304
23. https://qt4cg.org/dashboard/#pr-290
24. https://qt4cg.org/pr/290/xpath-datamodel-40/autodiff.html#function-items
25. https://qt4cg.org/dashboard/#pr-286
26. https://qt4cg.org/meeting/minutes/2022/12-13.html#issue-281
27. https://github.com/qt4cg/qtspecs/issues/281
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 17 January 2023 17:12:29 UTC