Re: QT4CG meeting 086 draft agenda, 16 July 2024 from Norm Tovey-Walsh on 2024-07-16 (public-xslt-40@w3.org from July 2024)

From: Norm Tovey-Walsh <norm@saxonica.com>
Date: Tue, 16 Jul 2024 17:23:30 +0100
To: public-xslt-40@w3.org
Message-ID: <m2ed7ts3ul.fsf@saxonica.com>

Hello,

Here are the minutes for today’s meeting:

https://qt4cg.org/meeting/minutes/2024/07-16.html

Reminder: we meet next week, then we take a summer recess until 3 September.

QT4 CG Meeting 086 Minutes 2024-07-16

Table of Contents

* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/3]
* [3]1. Administrivia
+ [4]1.1. Roll call [11/12]
+ [5]1.2. Accept the agenda
o [6]1.2.1. Status so far...
+ [7]1.3. Approve minutes of the previous meeting
+ [8]1.4. Next meeting
+ [9]1.5. Review of open action items [0/3]
+ [10]1.6. Review of open pull requests and issues
o [11]1.6.1. Blocked
o [12]1.6.2. Close without action
* [13]2. Technical Agenda
+ [14]2.1. Community, communication, and consensus
+ [15]2.2. Plan to clean up the state of PRs
+ [16]2.3. PR #1263: 1224 Add xsl:accumulator-rule/@priority
attribute
+ [17]2.4. PR #1244: 1244 566-partial Rewrite parse-uri
* [18]3. Any other business
* [19]4. Adjourned

[20]Meeting index / [21]QT4CG.org / [22]Dashboard / [23]GH Issues /
[24]GH Pull Requests

Draft Minutes

Summary of new and continuing actions [0/3]

* [ ] QT4CG-080-05: NW to add absolute property to the parse-uri
output
* [ ] QT4CG-080-07: NW to update the build instructions in the README
* [ ] QT4CG-082-02: DN to work with MK to come to agreement on the
fn:ranks proposal

1. Administrivia

1.1. Roll call [11/12]

* [X] Reece Dunn (RD)
* [X] Sasha Firsov (SF)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [ ] Juri Leino (JLO)
* [X] John Lumley (JWL)
* [X] Dimitre Novatchev (DN)
* [X] Wendell Piez (WP)
* [X] Ed Porter (EP)
* [X] C. M. Sperberg-McQueen (MSM)
* [X] Norm Tovey-Walsh (NW). Scribe. Chair.

1.2. Accept the agenda

MK observes that the selection of technical items is a mixed bag. Some
are not ready for discussion. Maybe we could talk about how to improve
that?

Proposal: Accept [25]the agenda amended to include discussion of the
state of PRs.

Accepted.

1.2.1. Status so far...

issues-open-2024-07-16.png

Figure 1: "Burn down" chart on open issues

issues-by-spec-2024-07-16.png

Figure 2: Open issues by specification

issues-by-type-2024-07-16.png

Figure 3: Open issues by type

1.3. Approve minutes of the previous meeting

Proposal: Accept [26]the minutes of the previous meeting.

Accepted.

1.4. Next meeting

This next meeting is planned for 23 July.

MSM gives possible regrets.

1.5. Review of open action items [0/3]

1.6. Review of open pull requests and issues

1.6.1. Blocked

The following PRs are open but have merge conflicts or comments which
suggest they aren't ready for action.
* PR [27]#1231: 1193 Parsing Functions: Empty input
* PR [28]#1227: 150 PR resubmission for fn ranks
* PR [29]#1062: 150bis - revised proposal for fn:ranks
* PR [30]#529: 528 fn:elements-to-maps

1.6.2. Close without action

It has been proposed that the following issues be closed without
action. If you think discussion is necessary, please say so.
* Issue [31]#1272: Add xsl:value-of/@as attribute

Proposal: close without further action

Approved.

2. Technical Agenda

2.1. Community, communication, and consensus

Can we make our process less...fractious?
* NW: I said my piece in [32]the agenda. Mike's follow-up points
[33]in the issue were on point as well, I think. Mostly, we're
talking about design decisions and while the design might have
influence one way or the other, rarely can the argument be made, I
think, that one design is doomed to failure.
* MK: People do get passionate about decisions; we strive for
perfection and we have different ideas about what that is. Often,
focused on one particular aspect of design. These are engineering
trade-offs; we should try to be objective about what the benefits
and disadvantages of the proposals.
+ Don Chamberlain and Mary Fernandez were very good about
managing these sorts of things. They would write up a position
paper that was very clear about the options without taking
sides. That often clarified the engineering trade-offs. Even
if you end up tossing a coin, everyone has acknowledged the
choices.
* CG: Thanks for putting this on the agenda. What do you think of the
current way. Sometimes there's no discussion, sometimes there's a
lot of discussion. What I observed is that in the beginning I felt
like we were much more focused. In the last few months, it feels
like things have been blocked by secondary items. I appreciate MK's
comments about other projects.
* DN: I want to thank CG for adding this to the agenda. I want to
thank MK for pointing out that we should be guided primarily by the
facts. I agree that we have communication issues. And our
communication will be reflected in the final project.
+ I think there are bigger communication problems:

DN shares a screen with some XQuery definitions
* DN: There's a simple call to fold left with the position argument.
This gives the wrong answer. Without the position argument, we get
the right answer (55).
+ ... Our specification of defaults that has been in the spec
for several months is wrong. And no one has noticed. We have
problems in communication and approval of PRs.
+ ... For fold-right, we get 35 but we should have got the same
result.
+ ... For PR 1296, we have an example that doesn't even compile!
+ ... If I change it so it compiles, fold-left produces the
right result but fold-right has some mysterious issue.
+ ... The mapBuild function from the specification also does not
compile!
+ ... This shows much deeper and more serious issues in our
communication.
* DN: I think we need to review how we accept pull requests.
* DN: I also wanted to show you two more functions, the versions of
C# that do not have position arguments.
* CG: I'd like to point out that I didn't raise this issue
exclusively because of the scan functions. It's a general
observation over the past few months that we've had trouble making
progress. Whenever a few people think something is a good idea, we
should have respect for that. Everyone can have different
experiences and ideas, but I wanted to talk about the principle
that we should avoid offensive terms.
* DN: I think in many cases when we have consensus, we end up with
results that don't work. I would not be surprised if very
significant parts of our "formal" specification will have similar
results.
* RD: A couple of points. 1. I don't have enough time to look at all
of the issues and all of the discussions. The discussion may be in
a domain area where I'm not an expert. I only tend to contribute
when I have specific insights. 2. On the grammar and syntax errors
with fold-left and fold-right, I wonder if we could run a parser
over the specs. We should be able to automate validation of the
fragments. With things like the $key variable being mistyped, I
think it might be useful to extract the functions where we've got
something that should be implementations and test them. We're
relying on having multiple implementors implementing the spec and
providing feedback and comments. It's impossible to get a perfect,
error-free spec. That's just the nature of writing. What tooling
and infrastructure can we put in place?
* MK: We've changed the subject somewhat from the process of gaining
agreement on the design that we want to the process of publishing a
quality specification free of embarrassing errors. In some ways I'm
more comfortable with the second topic!
+ ... We've put a lot of investment into technology for solving
some of those issues that we aren't fully exploiting. We do
have the ability to test all the examples, for examples.
+ ... Testing alternative implementations is something we should
definitely try to do. Some of the test suites for particular
functions test both the "real" implementation and the
specification implementation.
+ ... We should try to formalize that. The whole markup of
Functions & Operators should support marking up a function
clearly enough to automate testing it.
+ ... There's also technology in the markup system for marking
up fragments of XPath and testing that they compile.
+ ... I think that's a separate matter from the process we try
to use to reach consensus.
* DN: Totally agree with MK. It's good that we're talking about
communication problems, but if we're only talking it's not good.
The actions could be to establish some rules that would decrease
some issues.
+ ... I'd like to suggest that this formal semantics should be
executable as much as possible. We should be able to
cut-and-paste the formal specifications into their favorite
implementations.
+ ... We should not allow a formal specification to be replaced
by an informal one.
* RD: It would also be useful to have validation for XSLT as well.
Those examples can have errors too. I don't think it would be
useful to require all functions to have an executable
implementation. First, because that can be difficult to read, and
second, it can be harder to implement when you're dealing with
internals and domain-specific things like Unicode.
* DN: For me, a specification is not executable if the code contain
calls to other newly proposed XPath 4.0 functions that are not
implemented. It's a circular reference or chain that should be
broken.
* MSM: Thank you for the discussion. I think MK was right that we've
drifted from the question of communication style and interaction to
questions of quality assurance. That's understandable in a way.
It's when we see things going wrong that we're most apt to become
agitated and push the boundaries of normal rules of communication.
I think we've had some suggestions for improved Q&A. I would like
to make some suggestions for improved communication:
+ ... There are rules that apply here. You may or may not
remember but when you joined the group you agreed to abide by
the W3C code of conduct.
+ ... There are a lot of things in the code that aren't
relative, but cognizance of difference is essential. We all
come from different tehcnical, social and cultural
backgrounds. That means we inevitably have different
expectations. Things that are minor in some cultures may be
almost unbearably aggressive in others. That means that those
from cultures on the aggressive end of the spectrum have to be
sensitive and those from the other end have to try to be
understanding.
+ ... The second requirement is respect. Everyone here is a
volunteer giving their time. Everyone is obligated to be here.
To the extent that we all want this spec to go forward, we owe
each other a debt of gratitude for being here. If things
aren't going as we would like, if PRs aren't getting the
review we would like, that's because we aren't as many as we
might like. But turning meeteings of the group into unpleasant
confrontations isn't a way to encourage people to be here.
+ ... Be conscious that you may need to convey respect as well
as critical information. Of course, it's precisely when we're
most passionate about something that it's easiest to loose
track. And if we weren't passionate, we wouldn't be here. Some
confrontation is probably unavoidable but I would like to
lower the temperature sometimes.
+ ... Maybe we should just suspend discussion when it gets too
heated. That's something that NW and I can do as co-chairs.

2.2. Plan to clean up the state of PRs

* MK: There are various things on the list this week, that I don't
think that we're ready to debate. Perhaps we aren't tagging things
appropriately. There are things like JSON to XML conversion that
have been dormant a long while.
+ ... There are other things that perhaps ought to be
back-burnered.
* NW: I think it's also appropriate to close PRs that won't be ready
for discussion for some time.

This discussion petered out without really leading anywhere. Alas.

MK proposes that we can get through 1263 in 15 minutes.

2.3. PR #1263: 1224 Add xsl:accumulator-rule/@priority attribute

See PR [34]#1263

MK walks us through the substance of the change.
* NW: I'm happy to see that there's no attempt to mix manual and
automatic priorities.
* JK: I'm in favor of this proposal, it'll help me a lot.
* MSM: Several people have said that we aren't mixing and explict and
implicit priorities. Hasn't XSLT already done that; shouldn't we be
trying to do the same thing as XSLT?
* MK: One reason is that if we now introduced default priorities
based on the syntax of the match pattern based on the syntax of the
match patterns, we'd immediately be incompatible with 3.0.
+ That was done probably because we thought there would only be
a few.

Some discussion of whether automatic XSLT priorities are "a good thing"
in the first place.
* MK: The compatibility problem seems insurmountable.
* WP: If we can't make the priorities the same, then can we flag that
up?
* MK: We could add an attribute to do that, but that seems like
layering complexity.
* NW: Doesn't the current design achieve that: if one has a priority
then they all must?

Further discussion of that design choice.
* JWL: No two priorities can be the same, so the set of accumulator
rules are strictly ordered. So in one sense you don't need the
priority attirbute, you just have to put them in the right order.
* MK: That's the 3.0 design.
* JWL: So this just makes it so you don't have to switch them around.
* RD: Does this effect included accumulator rules?
* MK: You can't currently spread an accumulator definition across
multiple modules.
* MSM: I'd like a week to sleep on it.
* JWL: Same for me.
* DN: All similar design issues could be replaced by having a single
map of accumulators with match patterns as the keys. This will be
more compact and people will not argue about order and other
things. I've noticed this in several places. Things that are
declared as a sequence can be a single map.
* CG: I hope that one minute is enough to look at 1244.

2.4. PR #1244: 1244 566-partial Rewrite parse-uri

* CG: I've reviewed this and I think we should merge it and then work
on implementations and tests.
* NW: Okay. I've been holding off on this one waiting until we could
collaborate on that, but if you think it's ready to merge, that's
fine by me!

Proposal: merge this PR.

Accepted.

3. Any other business

None heard.

4. Adjourned

References

1. https://qt4cg.org/meeting/minutes/2024/07-16.html#minutes
2. https://qt4cg.org/meeting/minutes/2024/07-16.html#new-actions
3. https://qt4cg.org/meeting/minutes/2024/07-16.html#administrivia
4. https://qt4cg.org/meeting/minutes/2024/07-16.html#roll-call
5. https://qt4cg.org/meeting/minutes/2024/07-16.html#agenda
6. https://qt4cg.org/meeting/minutes/2024/07-16.html#so-far
7. https://qt4cg.org/meeting/minutes/2024/07-16.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2024/07-16.html#next-meeting
9. https://qt4cg.org/meeting/minutes/2024/07-16.html#open-actions
10. https://qt4cg.org/meeting/minutes/2024/07-16.html#open-pull-requests
11. https://qt4cg.org/meeting/minutes/2024/07-16.html#blocked
12. https://qt4cg.org/meeting/minutes/2024/07-16.html#close-without-action
13. https://qt4cg.org/meeting/minutes/2024/07-16.html#technical-agenda
14. https://qt4cg.org/meeting/minutes/2024/07-16.html#communication
15. https://qt4cg.org/meeting/minutes/2024/07-16.html#h-06AAA90B-E108-43AC-B0D4-26C8057329B1
16. https://qt4cg.org/meeting/minutes/2024/07-16.html#pr-1263
17. https://qt4cg.org/meeting/minutes/2024/07-16.html#pr-1244
18. https://qt4cg.org/meeting/minutes/2024/07-16.html#any-other-business
19. https://qt4cg.org/meeting/minutes/2024/07-16.html#adjourned
20. https://qt4cg.org/meeting/minutes/
21. https://qt4cg.org/
22. https://qt4cg.org/dashboard
23. https://github.com/qt4cg/qtspecs/issues
24. https://github.com/qt4cg/qtspecs/pulls
25. https://qt4cg.org/meeting/agenda/2024/07-16.html
26. https://qt4cg.org/meeting/minutes/2024/07-09.html
27. https://qt4cg.org/dashboard/#pr-1231
28. https://qt4cg.org/dashboard/#pr-1227
29. https://qt4cg.org/dashboard/#pr-1062
30. https://qt4cg.org/dashboard/#pr-529
31. https://github.com/qt4cg/qtspecs/issues/1272
32. https://qt4cg.org/meeting/agenda/2024/07-16.html#communication
33. https://github.com/qt4cg/qtspecs/pull/1296#issuecomment-2228896220
34. https://qt4cg.org/dashboard/#pr-1263

Be seeing you,
norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 16 July 2024 16:23:39 UTC