- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Tue, 6 May 2025 10:01:55 -0700
- To: Norm Tovey-Walsh <norm@saxonica.com>
- Cc: public-xslt-40@w3.org
- Message-ID: <CAK4KnZfagJA0d9cf8U=BrVtuz6XFgS5R+CcuO5OEFkGrU-m69g@mail.gmail.com>
At today's QT4 meeting the proposer of PR #1975: 1240 Allow operand of
dynamic function call to be a sequence, intentionally concealed (didn't
mention) the fact that it endorses something that is commonly accepted as a
programming antipattern - the swallowing and not reporting of errors.
From now on, if a method or function is invoked off the empty sequence (not
off a map), there will be no error issued at all and the result of the
function call will be the empty sequence.
The fact that this creates a backwards-compatibility issue (in Xpath 3.1 an
error must be raised) is not the worst thing. The worst thing is that from
now on, anyone wishing to write XPath code invoking methods off maps, will
not receive any errors when something as drastic as trying to invoke a
function off what is supposed to be a map, but happens to be the empty
sequence - this person would be left even without one bit of information
what has happened. Thus, spend 2-3 additional days to find a bug that
otherwise would be obvious. Antipattern, indeed.
This is a big issue for creating and maintaining XPath-based code, but the
presenter never even mentioned it.
Just a fresh example... I wonder how many times similar concealments
happened in the past, hence what bag of snakes our specifications might
turn out to be.
Once again, I want to have a written record that I have never supported
this and I voted against this.
As for the people that intentionally conceal from us crucial information
when proposing their PRs - well, let everybody knows that this "works" in
the QT4 group.
On Tue, May 6, 2025 at 9:38 AM Norm Tovey-Walsh <norm@saxonica.com> wrote:
> Hi folks,
>
> Here are the draft minutes from today’s meeting:
>
> https://qt4cg.org/meeting/minutes/2025/05-06.html
>
> QT4 CG Meeting 120 Minutes 2025-05-06
>
> [1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
> Pull Requests
>
> Table of Contents
>
> * [6]Draft Minutes
> * [7]Summary of new and continuing actions [0/6]
> * [8]1. Administrivia
> + [9]1.1. Roll call [7/12]
> + [10]1.2. Accept the agenda
> o [11]1.2.1. Status so far...
> + [12]1.3. Approve minutes of the previous meeting
> + [13]1.4. Next meeting
> + [14]1.5. Review of open action items [5/10]
> + [15]1.6. Review of open pull requests and issues
> o [16]1.6.1. Blocked
> o [17]1.6.2. Merge without discussion
> o [18]1.6.3. Substantive PRs
> * [19]2. Technical agenda
> + [20]2.1. Review of pull requests
> + [21]2.2. PR #1883/1894: fn:chain and fn:compose
> + [22]2.3. PR #1976: 1661 Introduce QName literals
> + [23]2.4. PR #1975: 1240 Allow operand of dynamic function call
> to be a sequence
> * [24]3. Any other business
> * [25]4. Adjourned
>
> Draft Minutes
>
> Summary of new and continuing actions [0/6]
>
> * [ ] QT4CG-082-02: DN to work with NW to come to agreement on the
> fn:ranks proposal
> * [ ] QT4CG-107-05: JLO and DN to consider a proposal for system
> defined records.
> * [ ] QT4CG-112-01: JLO to propose a concrete example that uses "."
> in a ~%method~s.
> * [ ] QT4CG-116-01: Add a specific error code for unsupported options
> on doc and doc-available
> * [ ] QT4CG-118-01: MK to make an incorrect type raise an error in
> #1906
> * [ ] QT4CG-119-02: MK to add a note about how schema composition is
> done for multiple options
>
> 1. Administrivia
>
> 1.1. Roll call [7/12]
>
> Regrets: JWL, JLO
> * [X] David J Birnbaum (DB)
> * [ ] Reece Dunn (RD)
> * [X] Christian Gr¸n (CG)
> * [X] Joel Kalvesmaki (JK)
> * [X] Michael Kay (MK)
> * [ ] Juri Leino (JLO)
> * [ ] John Lumley (JWL)
> * [X] Dimitre Novatchev (DN)
> * [X] Wendell Piez (WP)
> * [ ] Ed Porter (EP)
> * [ ] Bethan Tovey-Walsh (BTW)
> * [X] Norm Tovey-Walsh (NW) Scribe. Chair.
>
> 1.2. Accept the agenda
>
> Proposal: Accept [26]the agenda.
>
> Accepted.
>
> 1.2.1. Status so far...
>
> These charts have been adjusted so they reflect the preceding six
> months of work.
>
> issues-open-2025-05-06.png
>
> Figure 1: "Burn down" chart on open issues
>
> issues-by-spec-2025-05-06.png
>
> Figure 2: Open issues by specification
>
> issues-by-type-2025-05-06.png
>
> Figure 3: Open issues by type
>
> 1.3. Approve minutes of the previous meeting
>
> Proposal: Accept [27]the minutes of the previous meeting, as amended.
>
> Accepted.
>
> 1.4. Next meeting
>
> The next meeting is scheduled for 13 May 2025.
>
> Unlikely to achieve quorem for a face-to-face meeting colocated with
> MarkupUK.
>
> Norm is at risk.
>
> 1.5. Review of open action items [5/10]
>
> (Items marked [X] are believed to have been closed via email before
> this agenda was posted.)
> * [ ] QT4CG-082-02: DN to work with NW to come to agreement on the
> fn:ranks proposal
> * [ ] QT4CG-107-05: JLO and DN to consider a proposal for system
> defined records.
> * [ ] QT4CG-112-01: JLO to propose a concrete example that uses "."
> in a ~%method~s.
> * [ ] QT4CG-116-01: Add a specific error code for unsupported options
> on doc and doc-available
> * [ ] QT4CG-118-01: MK to make an incorrect type raise an error in
> #1906
> * [X] QT4CG-119-01: NW will add a bit of prose about * and then merge
> the PR 1961
> * [ ] QT4CG-119-02: MK to add a note about how schema composition is
> done for multiple options
>
> 1.6. Review of open pull requests and issues
>
> This section summarizes all of the issues and pull requests that need
> to be resolved before we can finish. See [28]Technical Agenda below for
> the focus of this meeting.
>
> 1.6.1. Blocked
>
> The following PRs are open but have merge conflicts or comments which
> suggest they aren't ready for action.
> * PR [29]#1942: 37 Support sequence, array, and map destructuring
> declarations
> * PR [30]#1283: 77b Update expressions
> * PR [31]#1062: 150bis revised proposal for fn:ranks
>
> 1.6.2. Merge without discussion
>
> The following PRs are editorial, small, or otherwise appeared to be
> uncontroversial when the agenda was prepared. The chairs propose that
> these can be merged without discussion. If you think discussion is
> necessary, please say so.
> * PR [32]#1974: 1973 Cross-reference from type analysis to definition
> of disjointedness
> * PR [33]#1971: 1951 Clarifications on serialization parameters
> * PR [34]#1969: 1952 Change option name xsi-schema-location
> * PR [35]#1968: 1967 r/binary-resource/unparsed-binary/
> * PR [36]#1964: 1957 xsl output allows mixed content
> * PR [37]#1963: 1958 Fix simple typo in map:build
>
> Proposal: accept these PRs without discussion.
>
> Accepted.
>
> 1.6.3. Substantive PRs
>
> The following substantive PRs were open when this agenda was prepared.
> * PR [38]#1977: 1889 Tidy up handling of HTML serialization version,
> default to HTML5
> * PR [39]#1976: 1661 Introduce QName literals
> * PR [40]#1975: 1240 Allow operand of dynamic function call to be a
> sequence
> * PR [41]#1971: 1951 Clarifications on serialization parameters
> * PR [42]#1964: 1957 xsl output allows mixed content
> * PR [43]#1959: 1953 (part) XSLT Worked example using methods to
> implement atomic sets
> * PR [44]#1894: Additional examples to fn:chain - in a new branch
> * PR [45]#1888: 366 xsl:package-location
> * PR [46]#1883: 882 Replace fn:chain by fn:compose
>
> 2. Technical agenda
>
> 2.1. Review of pull requests
>
> 2.2. PR #1883/1894: fn:chain and fn:compose
>
> Related PRs:
> * PR [47]#1883: 882 Replace fn:chain by fn:compose
> * PR [48]#1894: Additional examples to fn:chain - in a new branch
>
> We need to come to some resolution on this issue. Recall that in last
> week's straw poll, there were only two options that got any votes at
> all: fn:compose (only) got 6 votes, both got 3 votes.
>
> I'm going to time box this discussion to 10 minutes. If, after that
> time, there is still a substantial majority in favor of fn:compose
> only, I'm going to ask the minority to accept that the consensus does
> not favor keeping fn:chain as well.
> * JK: After looking a little bit closer, I'm not convinced we need
> either. I would vote to drop both.
> + ... We should be wrapping things up; if there's a new
> function, there should be higher bar.
> * DN: Last week, we discussed several claims that I have shown to be
> incorrect.
> + ... The chain function is easier to use than apply.
> + ... I asked JLO to give me an example of where fn:chain
> doesn't behave as expected, but he didn't provide one.
> + ... You can't use arrow notation for consumers that have more
> than one argument without more plumbing.
> + ... The fn:chain function is like checking your luggage all
> the way through to your destination.
> * DN: Replacing one function of with another that has less
> functionality is not an improvement.
> + ... The fn:compose function has less functionality so it's not
> a suitable substitution.
> * DN: There are errors in the formal definition of fn:compose, so I'd
> have to vote against it.
> * MK: I think fn:compose is a much simpler function. It's an
> improvement because it's simpler and easier to understand. It
> doesn't try to be polymorphic depending on the arguments.
> + ... I know there are some editorial nits in the specification;
> I'll fix those if the PR is accepted.
> * WP: I'm on the fence. I've heard different claims that I find hard
> to reconcile. JK made a case for abstaining altogether. Should we
> have time to think about that.
> * MK: They aren't primitives; these functions have formal
> equivalents. You can write them yourself. You have to be fairly
> expert to do that, but you can.
> * WP: One thing that we lack is compelling examples of why your
> average user, not your deep user, would want to use these
> functions.
> + ... Maybe we should just show the deep user how to do that.
> * DN: Function fn:chain was specifically produced as a response to
> some very ugly examples of long lambda expressions containing a
> variety of two and three character operators that were very hard to
> understand.
> + ... I proposed fn:chain because it simplifies these cases.
> * MK: Equally, the fn:compose function was motivated by a specific
> use case; supplying not matches to a function that expected a
> callback.
> * DN: Both functions are complimentary.
>
> NW asks if there are concrete actions we could take that would help us
> resolve this next week?
> * JK: I don't feel like the question I asked in the PR has been
> answered, and for every example that I've seen, I think there are
> two or three other ways to do it.
> + ... Every example should say something that other examples
> haven't.
>
> No proposals to undertake actions where forthcoming.
>
> Straw poll:
> Option Votes
> fn:compose (only) 3
> fn:chain (only) 0
> both 1
> neither 2
> * WP: Examples would be helpful.
> * NW: Perhaps, but no one voluntered to do that.
>
> We reached no conclusion this week, the chair declares enough time has
> been spent on this issue for this week.
>
> 2.3. PR #1976: 1661 Introduce QName literals
>
> See PR [49]#1976
>
> MK introduces the proposal without screen sharing.
> * MK: We have a lot of functions that accept QNames as arguments, or
> maps that have them as keys or values.
> + ... Constructing a QName is verbose.
> + ... There are two proposals for resolving that:
> o ... CG proposed promoting strings to QNames; but it only
> works for strings in no namespace.
> o ... I've got a different proposal for the case where the
> QName is statically known.
> + ... My preference is QName literals and I proposed a syntax
> for it.
> + ... It only works if you know the names statically, but it
> considerably simplfies things in those cases.
> + ... I think the groups reluctance to add new syntax is
> healthy, but I think this is worther.
> * CG: As MK said, I have some other suggestions. But I would
> definitely vote for MK's proposal. I think it's a clear improvement
> and my proposals aren't as general enough. I like the # syntax more
> than the other one.
> + ... What I'd like is to allow curly braces to directly add the
> URI without a prefix. In XQuery, the namespace context is
> effected by context.
> * MK: That's allowed; hash followed by an EQName.
> * JK: I don't know that I fully undertand the implications without a
> little bit of screen sharing. Can you explain?
>
> MK switches to screen sharing.
> * MK walks through the changes to XPath...
> * JK: I've run into enough places where I've been forced to use
> xs:QName(). I think this is a great improvement; I worry that it
> might be overused.
> * MK: Yes, I think there's some risk that it will get used in
> function names and element names and in places where it's not
> appropriate.
>
> Some discussion of possible ambiguities. None are apparent.
>
> Proposal: accept this PR.
>
> Accepted.
>
> 2.4. PR #1975: 1240 Allow operand of dynamic function call to be a sequence
>
> See PR [50]#1975
>
> MK introduces the PR.
> * MK: This is about dynamic function calls in XPath.
> + ... We no longer insist that the left hand side of a function
> call be a single item.
> + ... we apply sequence concatentation to the results.
> + ... The example is illustrative: (MK walks through the example
> in 4.5.3.)
> + ... The idea is to make method application work much more like
> looking up fields and the "/" in an XML document.
> * DN: MK missed something important, if a method is invoked on an
> empty sequence it shouldn't raise an error. It should just return
> an empty sequence.
> + ... This is an antipattern.
> + ... This would be a very foolish thing to do, but an error
> must be raised if someone attempts to invoke a method on an
> empty sequence.
> * MK: The antipattern is operations on nulls, but we don't have a
> null. We have an empty sequence and it's entirely reasonable to
> call methods on an empty sequence.
> * DN: Empty sequence is the closest thing we have to null.
> * MK: This is the way the language has worked since XPath 1.0; it's
> like XML. A book can have 0 or more authors; an XPath expression
> can return 0 or more authors; asking for the names of the authors
> will succeed even if there are no authors.
> + ... XPath has always worked that way; this use case is
> actually the outlier.
> * CG: I completely agree with MK that it's the very philosophy of
> XPath to be able to handle empty sequences and just go on. It's
> true of path expressions, simple lookup, etc.
> + ... This is one exception where we do something differently
> and I think it would be completely justified to align the
> behavior.
>
> CG shows an example from the PR.
> let $map := { 'giovanni': { 'city': 'roma' }, 'sara': { 'city': 'napoli' }
> }
> return (
> (: A :) $map?andrea?city
> (: B :) $map('andrea')('city')
> )
>
> * CG: (A) works, but (B) raises an error. That's inconsistent.
> + ... Particularly for data access, I think there's no reason to
> enforce a different behavior.
> * JK: I think it's a nice convenience to be able to have multiples.
> We can discuss errors separately.
> * MK: There's a second PR from CG on the static type checking of
> lookup expressions.
>
> Proposal: Accept the PR.
>
> DN objects.
>
> The PR is accepted over DN's objection.
>
> 3. Any other business
>
> None heard.
>
> 4. Adjourned
>
> References
>
> 1. https://qt4cg.org/meeting/minutes/
> 2. https://qt4cg.org/
> 3. https://qt4cg.org/dashboard
> 4. https://github.com/qt4cg/qtspecs/issues
> 5. https://github.com/qt4cg/qtspecs/pulls
> 6. https://qt4cg.org/meeting/minutes/2025/05-06.html#minutes
> 7. https://qt4cg.org/meeting/minutes/2025/05-06.html#new-actions
> 8. https://qt4cg.org/meeting/minutes/2025/05-06.html#administrivia
> 9. https://qt4cg.org/meeting/minutes/2025/05-06.html#roll-call
> 10. https://qt4cg.org/meeting/minutes/2025/05-06.html#agenda
> 11. https://qt4cg.org/meeting/minutes/2025/05-06.html#so-far
> 12. https://qt4cg.org/meeting/minutes/2025/05-06.html#approve-minutes
> 13. https://qt4cg.org/meeting/minutes/2025/05-06.html#next-meeting
> 14. https://qt4cg.org/meeting/minutes/2025/05-06.html#open-actions
> 15. https://qt4cg.org/meeting/minutes/2025/05-06.html#open-pull-requests
> 16. https://qt4cg.org/meeting/minutes/2025/05-06.html#blocked
> 17.
> https://qt4cg.org/meeting/minutes/2025/05-06.html#merge-without-discussion
> 18. https://qt4cg.org/meeting/minutes/2025/05-06.html#substantive
> 19. https://qt4cg.org/meeting/minutes/2025/05-06.html#technical-agenda
> 20. https://qt4cg.org/meeting/minutes/2025/05-06.html#technical-prs
> 21.
> https://qt4cg.org/meeting/minutes/2025/05-06.html#h-92337C4E-B551-4176-894D-E6A787B9E12D
> 22. https://qt4cg.org/meeting/minutes/2025/05-06.html#pr-1976
> 23. https://qt4cg.org/meeting/minutes/2025/05-06.html#pr-1975
> 24. https://qt4cg.org/meeting/minutes/2025/05-06.html#any-other-business
> 25. https://qt4cg.org/meeting/minutes/2025/05-06.html#adjourned
> 26. https://qt4cg.org/meeting/agenda/2025/05-06.html
> 27. https://qt4cg.org/meeting/minutes/2025/04-29.html
> 28. https://qt4cg.org/meeting/minutes/2025/05-06.html#technical-agenda
> 29. https://qt4cg.org/dashboard/#pr-1942
> 30. https://qt4cg.org/dashboard/#pr-1283
> 31. https://qt4cg.org/dashboard/#pr-1062
> 32. https://qt4cg.org/dashboard/#pr-1974
> 33. https://qt4cg.org/dashboard/#pr-1971
> 34. https://qt4cg.org/dashboard/#pr-1969
> 35. https://qt4cg.org/dashboard/#pr-1968
> 36. https://qt4cg.org/dashboard/#pr-1964
> 37. https://qt4cg.org/dashboard/#pr-1963
> 38. https://qt4cg.org/dashboard/#pr-1977
> 39. https://qt4cg.org/dashboard/#pr-1976
> 40. https://qt4cg.org/dashboard/#pr-1975
> 41. https://qt4cg.org/dashboard/#pr-1971
> 42. https://qt4cg.org/dashboard/#pr-1964
> 43. https://qt4cg.org/dashboard/#pr-1959
> 44. https://qt4cg.org/dashboard/#pr-1894
> 45. https://qt4cg.org/dashboard/#pr-1888
> 46. https://qt4cg.org/dashboard/#pr-1883
> 47. https://qt4cg.org/dashboard/#pr-1883
> 48. https://qt4cg.org/dashboard/#pr-1894
> 49. https://qt4cg.org/dashboard/#pr-1976
> 50. https://qt4cg.org/dashboard/#pr-1975
>
> Be seeing you,
> norm
>
> --
> Norm Tovey-Walsh
> Saxonica
>
>
Received on Tuesday, 6 May 2025 17:02:14 UTC