- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 18 Oct 2022 18:01:35 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m21qr5xdrw.fsf@saxonica.com>
The draft minutes are posted at
https://qt4cg.org/meeting/minutes/2022/10-18.html
QT4 CG Meeting 007 Minutes 2022-10-18
Table of Contents
* Draft Minutes
* Summary of new and continuing actions [0/6]
* 1. Administrivia
* 1.1. Roll call [9/13]
* 1.2. Accept the agenda
* 1.3. Next meeting
* 1.4. Approve minutes of the previous meeting
* 1.5. Review of open action items [5/6]
* 2. Technical Agenda
* 2.1. Review pull request #197 (was 166; variadic functions)
* 2.2. Issue #165, keyword arguments, “:=” or “:”
* 2.3. Review pull request #199 (was 177; items before, etc.)
* 2.4. Review pull request #200 (was 185; drop xsl:match
instruction)
* 2.5. Review pull request #202 (was 196; subtyping)
* 2.6. Review pull request #203: Issue 151: map:build
* 2.7. Review pull request #206: Corrections to math:atan2
* 2.8. Issue #170, XPath “otherwise” operator
* 3. Any other business
Draft Minutes
Summary of new and continuing actions [0/6]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-005-03: RD to review the variadic functions proposal in #197
(formerly #166)
* [ ] QT4CG-008-01: MK to implement the resolution of issue #165 (“:=”
and no “$”)
* [ ] QT4CG-008-02: NW to fix or replace #199, it doesn’t reflect the
original correctly
* [ ] QT4CG-008-03: NW to make the GitHub PR link to the diffs
* [ ] QT4CG-008-04: RD to review pull request #202
* [ ] QT4CG-008-05: NW to make an issue for Martin’s proposed ammendment
to map:build
1. Administrivia
1.1. Roll call [9/13]
Regrets: BTW, EP
* [X] Anthony Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Christian Grün (CG)
* [X] Joel Kalvesmaki (JK)
* [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). Chair. Scribe.
1.2. Accept the agenda
Proposal: Accept the agenda.
Accepted.
1.3. Next meeting
The next meeting is scheduled for Tuesday, 25 October. Any regrets?
None heard.
1.4. Approve minutes of the previous meeting
Proposal: Accept the minutes of the previous meeting.
Accepted.
1.5. Review of open action items [5/6]
(Items marked [X] are believed to have been closed via email before this
agenda was posted.)
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* Continued
* [X] QT4CG-005-03: RD to review the variadic functions proposal in #197
(formerly #166)
* [X] QT4CG-006-01: JK to review the variadic functions proposal in #197
* [X] QT4CG-006-02: NW to make the changed files heading to be more
obviously a link.
* Changes commited to the gh-pages branch on 11 October 2022
* [X] QT4CG-006-03: MK to make a separate proposal for supporting the
Unicode operator symbols
* https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0037.html
* https://github.com/qt4cg/qtspecs/issues/204
* [X] QT4CG-006-04: NW to point to the dashboard links from the agendas.
* See this agenda, for example :-)
2. Technical Agenda
2.1. Review pull request #197 (was 166; variadic functions)
* See pull request #197 (you’ll find links to formatted versions of the
specs at https://qt4cg.org/).
* See also the nexus of issues #162, #161, #160, #159, #158, #157, and
#155.
* See the discussion from last week.
Mike summarizes the reviews so far.
* MK: There are difficulties with the presentation, many of which derive
from the 3.1 spec. I haven’t seen any comments related to the
technical questions.
* RD: JK asked about “=” or “:=”.
* MK: Yes, we have a separate issue for that.
* MSM: I would like to pose a question, but it will lead to bike
shedding.
* NW: You have 5 minutes.
* MSM: When I was reading it, I became less and less comfortable with
the term “declared function” because we have to explain several times
that it isn’t a function, it’s a function family.
* MK: Yes, I’m proposing to change that to “function definition.”
* MSM: I thought “function family” might be a possibility.
* MK: I tried that. I think it sounds too much like a set of functions,
which it isn’t really because there’s also additional metadtaa, so I
decided not to use that.
* MSM: If we allow implementations to search multiple namespaces and
resolve conflicts, is it somehow inconsistent?
* MK: It’s unfortuante that tht issue has raised its head here. The
reason is that in my first draft, I proposed changes to function
resolution, partly to make more legitimate what XSLT was doing with
overrides and packages. Some of the chagnes aren’t a substantive part
of the proposal, they’re designed to tidy up text that should never
have been there.
* MSM: But if we allow host langeauges to supply conflict resolution
rules for some kinds of conflicts, forbidding it from resolving arity
conflicts seems odd.
* MK: Yes, there’s a bit of a tension there because XSLT has always has
its own rules. Those have never been reflected in XPath which is why I
tried to generalize the text.
We’ll come back to this again next week.
2.2. Issue #165, keyword arguments, “:=” or “:”
MK proposes that this issue may be ready to be decided.
* MK: The initial issue was what symbol do we use and then it was
widened to the question of whether we should put a $ in front of the
keyword.
* RD: Doesn’t that conflict with scripting extensions?
* MK: We already have conflicts there, so that doesn’t help me.
* DN: I would prefer not to use $ because it is more typing and I have
ides for using $ or $$ for something else in the future.
* RD: If we use $ in the function call, doesn’t that mean that we then
have a parsing ambiguity that breaks the current convention of having
a two symbol look-ahead to resolve conflicts? Having an NCName
followed by a colon would be a keyword parameter whereas $NCname could
be a parameter being passed to a function call or it could be defining
a name parameter.
* MK: I think there are already places where we need two character
look-ahead.
* RD: But what about more than two?
Some discussion about whether “$” “NCName” “:” is two or three symbol
look-ahead.
* CG: I would vote against $, because I think variable references and
declarations would look pretty similar. In NW’s example, there’s a let
keyword in front. One of my proposals was to use a simple string
followed by a colon.
* NW: Is that a third propsal, “:” instead of “:=” or “=”
* CG: Yes.
* MK: I think putting it in quotes has too much of an implication that
you can define the name variably instead of literally.
* RD: If we extend this to support map keys, if we don’t allow strings,
don’t we have the restriction that we can’t reference keys with
spaces? So we’d need to support stings. If we only support strings, we
don’t allow QNames. Whereas parameters can be QNames. We need to
support EQNames and if we extend it to map keys, strings.
* MK: I think there are two questions, := or : and the use of $. I think
the impression I got is that the discussion favored := because it’s
similar to other places where we bind values to parameter names, like
declaring the default in an XQuery function declaration and it reduces
some for ambiguity when you have a QName there.
Proposal: use “:=”
Accepted.
* NW: Do we want to resolve the $ question now?
* MK: It would be nice to resolve it, I think we know everything we need
to know. It’s technically redundant, we’re only doing it because we
use them everywhere else. It draws it out visually. I’m marginally in
favor of including it, but it’s not something I feel immensely
strongly about.
* MSM: I agree
* RD: I’d be against it because it would be a conflict with the
scripting extension syntax.
* DN: From what I hear, I have a feeling the majority is opposed to the
$. I’d like to add one more thing, it’s because $name can very easily
be construed as a reference to a variable and we could even have $x :=
$x.
* AB: I’ll register my agreement with RD not to do it.
Proposal: No “$”
Accepted.
ACTION QT4CG-008-01: MK to implement the resolution of issue #165 (“:=”
and no “$”)
2.3. Review pull request #199 (was 177; items before, etc.)
* See pull request #199
* MSM: My comment on it came just before the meeting.
In the course of attempting to review the item, we discovered that the PR
is malformed.
ACTION QT4CG-008-02: NW to fix or replace #199, it doesn’t reflect the
original correctly
2.4. Review pull request #200 (was 185; drop xsl:match instruction)
* See pull request #200
* MK: I proposed it a while ago. The intent was to find a way to use
pattern smore flexibly, but I haven’t really found a proposal that I’m
comfortable with. I’m not happy, so I prefer to drop it.
Proposal: Accept PR #200, drop xsl:match
Accepted.
2.5. Review pull request #202 (was 196; subtyping)
* See pull request #202
* MK: This is essentially an editorial proosal, though it does fill a
few gaps in the subtyping rules. It’s designed to use a more generous
layout for the rules and a more readable notation. It’s easy to find
the rules you want and the more generous layout offers more room for
examples.
* JL: I have a question on procedure. I’m trying to find out where the
information is.
Some discsion of the difficulty in finding the item. The organization of
the qt4cg.org pages, and the relationship to the GitHub pull request is
not as clear as it could be.
ACTION: QT4CG-008-03: NW to make the GitHub PR link to the diffs
* RD: I’d like to review the proposal.
ACTION: QT4CG-008-04: RD to review pull request #202
2.6. Review pull request #203: Issue 151: map:build
* See pull request #203
MK walks us through the proposal.
* MK: Martin Honnen also raised discussed this in email.
* MK: This was previously described as map:group-by() that was less
powerful.
* They way you do this today is with map:merge() which is
unintuitive and clumsy.
* The modification that Marin has proposed is that you should be
able to compute more than one key for each item in the input
sequence, all of which will be bound to the same value
* That conflicts with the way thtat DN might like to extend it, by
allowing keys to contain multiple atomic values. That would, say,
generate one composite key rather than multiple single keys.
* I’m fairly neutral to Martin’s extension; I’d be happy to accept
it but I don’t care strongly.
* MSM: DN, can you clarify something? I can see the utilty of having the
same item reachable thorugh mutliple keys. I can’t describe a use case
off the top of my head, but Martin’s proposal feels intuitive to me.
When I have a compound key, or something that would in other contexts
be called a compound key, I tend to use nested maps. I haven’t felt
any more unhappy with that than I am with maps generally. I’m
wondering, what do we get from allowing a sequence serve as a key?
* DN: There is a separate issue in which this is discussed quite
throughly (scribe believes it is #119). There, I also have an example
with nested maps and as an alternative. But it feels like it is quite
challenging, even for two nested maps. It would practically be
impossible for even deeper maps
* MSM: Ok, I’ll look at that issue.
NW asks if we could resolve this issue independently of Martin’s
suggestion. Agreement is we could.
ACTION QT4CG-008-05: NW to make an issue for Martin’s proposed ammendment
to map:build
* DN: Because we just provide the input, I undestand that we can
construct the key and the map is a function from the key to the value.
But the way I first read it, was that the value is a function of the
input, not the key. Maybe the prose could be clarified?
* MK: I’ll see if I can construct an example that demonstrates that.
* JL: This gives me a mapping that’s normally an identity and we can do
a replacement in parts of that.
* MSM: I’ve struggled a bit with map:merge, partly because of an
implementation detail, but my recolleciton is that in map merge,
there’s a kewyord for what to do with duplicates and here it’s a
function.
* MK: The five options we provide on map:merge can all be implemented by
very simple funtions. And there are lots of other options that you
might want, that you could also do with functions. Providing a general
function instead of a selection of four would be a useful enhancement.
* MSM: Thank you.
Proposal: Accept pull request #203.
Accepted.
2.7. Review pull request #206: Corrections to math:atan2
* See pull request #206
* RD: I noticed when looking at the way math:atan2 was specified was
that it didn’t match the output that it should. So I in my issue I
outlined the issues and MK has fixed them.
Some discussion of the IEEE spec.
Proposal: Accept pull request #206.
Accepted
2.8. Issue #170, XPath “otherwise” operator
MK proposes that this issue may be ready to be decided.
There’s no PR for this issue because the text is already in the draft.
* MSM: If I’m understanding this correctly, in cases where the left hand
argument returns at most one item, this has the same effect as
($a,$b)[1]. This generalizes that to allowing either operator to
return multiple items.
* MK: Yes. It has two benefits. One is, the existing notation ($a,$b)[1]
is highly obsecure. And the other is that it enables you to let the
left hand operand be a multi-item sequence.
* DN: I think everything is clear, but from my practice as a developer.
I think there could be a confusion. What’s proposed is that if the
left hand side (LHS) is the empty sequence, we choose the right hand
side (RHS). Some peple may think this is applicable if the LHS is the
empty string or false(), can we do something about this?
* JK: In that spirit, I’d like to propose a synonym, fallback which may
avoid the confusion.
* RD: I’d be wary of extending it to things like false() or the empty
string. It could led to confusing behavior like in JavaScript.
* MSM: To put it on the table, we could do two things to address the
concern: one is to revise the proposal in the direction of saying if
the effective boolean value (EBV) of the LHS is false then take the
RHS. The alternative is use a different keyword to avoid the mental
association with booleans.
* RD: If you have something like $x := false() return $x otherwise 2,
then you would expect it to return $x but if we allow EBV, then it
would return false(). What this is solving is the case where you have
the empty sequence!
* DN: From C#, there is a function is-null-or-empty and another other is
is-null-or-whitespace. There’s an operator that does null as well.
* JL: I’d favor keeping the current propsoal because what you’re tryign
to do is make it clear what the current practice of using ($a,$b)[1]
is for!
Time is up. We’ll have to come back to this next week.
3. Any other business
None heard.
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 18 October 2022 17:06:30 UTC