- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Tue, 16 Jul 2024 09:57:33 -0700
- To: Norm Tovey-Walsh <norm@saxonica.com>, public-xslt-40@w3.org
- Message-ID: <CAK4KnZfBov+VRVhMjTeBtEa2sDG90_sU+Ou-hE-0fmHAYyOFyw@mail.gmail.com>
And also this:
" * DN: I also wanted to show you two more functions, the versions of
C# that do not have position arguments. "
Was actually:
" * DN: I also wanted to show you two more functions: *All()* and *Any()*,
whose versions in the Microsoft
C# Enumerable class do not have any overload having a position
argument. "
Hope this could also be corrected?
Thanks,
Dimitre
On Tue, Jul 16, 2024 at 9:40 AM Dimitre Novatchev <dnovatchev@gmail.com>
wrote:
> Hi Norm,
>
> What I was showing was not " a screen with some XQuery definitions" - in
> fact it was a screen with the F&O 4.0 Spec. fold-left formal definitions
> and subsequent calls to the functions as officially defined in the Spec.
> These official "formal definitions" were copied from the Spec. and pasted
> into the screen.
>
> Therefore, can I kindly ask for the following correction in the minutes:
>
> Replace "DN shares a screen with some XQuery definitions" with "DN shares
> a screen with the F&O 4.0 Spec. fold-left formal definitions and subsequent
> calls to the functions as officially defined in the Spec."
>
> Thanks,
> Dimitre
>
> On Tue, Jul 16, 2024 at 9:23 AM Norm Tovey-Walsh <norm@saxonica.com>
> wrote:
>
>> 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]
>>
>> * [ ] 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.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:57:50 UTC