- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Thu, 2 Feb 2023 07:16:41 -0800
- To: Christian Grün <cg@basex.org>
- Cc: Norm Tovey-Walsh <norm@saxonica.com>, "public-xslt-40@w3.org" <public-xslt-40@w3.org>
- Message-ID: <CAK4KnZdcxPcBEN4HVYM_VcjeL=6=M4DEz_Kfgsc6L=qCzjUtgg@mail.gmail.com>
Hi Norm,
Thanks for the good minutes.
I have just this to make more precise:
" DN: I seem to recall that in the old version items were compared
with the "=" value so that times with and without timezones
couldn't be compared."
was actually (note the "eq" below.):
" DN: I seem to recall that in the old version items were compared
with the eq value so that times with and without timezones
couldn't be compared."
Hope this can be fixed.
Thanks,
Dimitre
On Thu, Feb 2, 2023 at 2:07 AM Christian Grün <cg@basex.org> wrote:
> Hi Norm,
>
> Thank you.
>
> PR#289 (Proposal to add fallback behaviour to map:get and array:get,
> inspired by #287) could be added to next week’s agenda.
>
> Thanks,
> Christian
>
> ------------------------------
> *Von:* Norm Tovey-Walsh
> *Gesendet:* Dienstag, 31. Januar 2023 18:17
> *Bis:* public-xslt-40@w3.org
> *Betreff:* QT4 CG draft minutes 020, 31 January 2023
>
> Hi folks,
>
> Apologies again for failing to email the agenda. Here are the draft
> minutes from today:
>
> https://qt4cg.org/meeting/minutes/2023/01-31.html
>
> A text copy:
>
> QT4 CG Meeting 020 Minutes 2023-01-31
>
> Table of Contents
>
> * [1]Draft Minutes
> * [2]Summary of new and continuing actions [0/12]
> * [3]1. Administrivia
> + [4]1.1. Roll call [8/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 [6/14]
> * [9]2. Technical Agenda
> + [10]2.1. PR #319: Issue 221: op:same-key becomes
> fn:atomic-equal
> + [11]2.2. PR #320: Issue 98 - add options parameter to
> fn:deep-equal
> + [12]2.3. PR #326: Issue 205: make support for higher-order
> functions mandatory
> + [13]2.4. PR #324: Proposed syntax and semantics for string
> templates
> + [14]2.5. PR #308: Improve the legends in the diagrams
> * [15]3. Any other business
>
> Draft Minutes
>
> Summary of new and continuing actions [0/12]
>
> * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
> diversity in the group
> * [ ] QT4CG-016-02: NW to add an ed-note indicating when it was
> approved.
> * [ ] 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-019-01: MK to fix the type of $pattern in fn:tokenize()
> * [ ] QT4CG-020-01: MK to check if the default for type-variety is
> correct.
> * [ ] QT4CG-020-02: MK to review the description of the equal-strings
> function
> * [ ] QT4CG-020-03: MK to add examples using options.
> * [ ] QT4CG-020-03: MK to add an option to return false instead of
> raising an error
>
> 1. Administrivia
>
> 1.1. Roll call [8/14]
>
> Regrets: BTW, JK, EP.
> * [ ] Anthony (Tony) Bufort (AB)
> * [X] Reece Dunn (RD)
> * [X] Sasha Firsov (SF)
> * [X] Christian Gr¸n (CG)
> * [ ] Joel Kalvesmaki (JK) [:12-]
> * [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). 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.
>
> The agenda and minutes were not sent by email, chair apologizes.
>
> 1.4. Next meeting
>
> The next meeting [18]is scheduled for Tuesday, 7 February 2023.
>
> No regrets heard.
>
> 1.5. Review of open action items [6/14]
>
> * [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
> diversity in the group
> * [X] QT4CG-015-02: NW to improve the width of the diagrams, perhaps
> multiple views
> * [X] 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.
> * [X] QT4CG-016-03: RD to add a note clarifying "known character
> encoding"
> + [19]https://github.com/qt4cg/qtspecs/pull/330
> * [X] QT4CG-016-04: RD to add a note clarifying the "*"/"*"
> html/version combination
> + [20]https://github.com/qt4cg/qtspecs/pull/330
> * [X] QT4CG-016-05: RD to add a "todo" noting the dependency on
> keyword arguments
> + [21]https://github.com/qt4cg/qtspecs/pull/330
> * [ ] 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-019-01: MK to fix the type of $pattern in fn:tokenize()
> * [X] QT4CG-019-02: NW to revisit the width issue in the type
> diagrams
>
> 2. Technical Agenda
>
> 2.1. PR #319: Issue 221: op:same-key becomes fn:atomic-equal
>
> See [22]pull request #319. We already have one approval for this PR.
>
> MK provides a quick summary of the new fn:atomic-equal() function and
> its consequences.
> * DN: If this is the same as op:same-key(); I see some duplication.
> * MK: No, the old function op:same-key() no longer exists.
>
> Proposal: accept this pull request
>
> Accepted.
>
> 2.2. PR #320: Issue 98 - add options parameter to fn:deep-equal
>
> See [23]pull request #320. Mike asks especially for careful review,
> this is not a simple change.
>
> MK proposes to introduce and describe the changes.
> * MK: Add an $options parameter; unfortunately the ~\(collation\)
> parameter can't be merged into it.
> + ... The $options defines how the comparisons are made
> + ... The default values are all aligned with the 3.0 verison of
> the function
>
> ACTION QT4CG-020-01: MK to check if the default for type-variety is
> correct.
> * MK continues
> + ... Options are designed so that if you set it to true, you
> get stricter comparisions. This explains the name of
> whitespace-retained.
> * RD: Should the unordered comparison option apply to map keys as
> well?
> + MK: Map entries are always unordered...
> * MK: Sequences are deep equal if their items are pair-wise
> deep-equal
> * RD: Should we clarify the order in which fn:normalize-unicode and
> fn:normalize-space are applied.
>
> ACTION QT4CG-020-02: MK to review the description of the equal-strings
> function
> * MK: It's much the same as before, except where the options come
> into play.
> + ... The unordered-elements option is a bit subtle if you have
> mixed content or if there are multiple elements with the same
> name.
> * JL: So you're on your own if you have text nodes?
> * MK: No, just don't use it if you have text nodes.
> * CG: Should it sort by node type so that it could work with mixed
> content?
> * MK: Could do, but I thought it wasn't going to be useful for mixed
> content.
> + ... Of course, people do use mixed content in strange ways due
> to changes over time.
> * MK: Type variety is a little more complex because it has to
> describe what's meant by complex content and simple content.
> + ... The logic for how we compare complex and simple content is
> preserved.
>
> ACTION QT4CG-020-03: MK to add examples using options.
> * RD: Would be nice to see examples based on intended usage, like
> around comparing two items in a unit test style.
> * MK: I don't want to go into enormous detail on use cases.
> * DN: We have several functions where one of the parameters is a
> comparison function. In order to use deep-equal we need an option
> to return false instead of raising an error if an error occurs.
> * MK: The only error condition is if there's a function item; we
> simply don't have a way of sensibly comparing function items.
> * DN: Just return false.
> * MK: But that would make a sequence not-equal to itself.
> * DN: We can just spell out that it only equals itself if it contains
> no function items.
> * MK: Where we talk about functions being deterministic, we claim
> processors can sometimes tell.
> * DN: I'm not saying deep-equal should never return an error, just
> that it should be an option.
>
> ACTION QT4CG-020-03: MK to add an option to return false instead of
> raising an error
> * DN: If we don't return errors for the same conditions, we're losing
> some backwards compatibility
>
> Some discussion of whether or not comparison of typed element content
> can raise an error.
> * DN: I seem to recall that in the old version items were compared
> with the "=" value so that times with and without timezones
> couldn't be compared.
> * MK: I'll investigate that.
> * RD: In the context of using this for things like implementing unit
> test assertions, one of the things I found useful for diagnostics
> was having the location where the failure occurred. Should we have
> an option to do that?
> * MK: My plan was to add an fn:differences function that returns the
> differences, rather than just returning true or false.
> * RD: Tangentially related fn:path only works for nodes. Should we
> extend it to maps and arrays?
> * MK: Maybe,
> * CG: Do we need the debug option if we have fn:differences?
> * MK: Let's wait and see.
> * DN: In case where there are unordered elements and there are
> multiple groups with individuals that are the same, what is the
> order of the comparisons?
> * MK: The current rule is very simple, simplistic even, it says you
> sort them by namespace and local name, and then you compare them.
> If you have multiple elements with the same name, their order is
> going to be significant.
> * JL: What happens if the child elements themselves are in unordered
> sets?
> * MK: The options are passed down.
> * DN: I think this is a bit confusing?
> * MK: Maybe I should change it to do a pure pair-wise set-comparison.
> * DN: Yes.
> * DN: Have you considered an implementation that just makes hashes
> and compares the hashes?
> * MK: Yes, that's the sort of thing. It's note easy but it can be
> done.
> * MSM: Question about the rule that says there's a mapping, are you
> envisioning a 1:1 mapping or just that there is a mapping.
> * MK: I was phrasing it as there must be a pairing: an ordering of A
> and B such that they are pairwise equal.
> * MSM: So an empty element named E will not match in this comparison
> a sequence of 3 empty elements all named E.
> * MK: No.
>
> 2.3. PR #326: Issue 205: make support for higher-order functions mandatory
>
> See [24]pull request #326. We already have one approval for this PR.
> * MK: In the current specs, support for higher order functions is
> optional. That's not really viable anymore. All of the 3.1
> implmentations we know about already support it.
> * JL: Does that mean you have to implement all the HoF?
> * MK: Yes.
> * MSM: Is it really true? I thought eXist didn't.
> * MK: They don't claim to be 3.1, do they?
> * CG: I thought eXist did.
> * MK: We're defining so much functionality with HoF that you really
> have to implement them.
>
> Some discussion of eXist's support.
> * MK: Making a feature mandatory doesn't mean everyone will implement
> it!
> * MSM: True, it just makes comparing conformance easier.
> * MK: It also means it allows users to use features that they might
> not if it was optional.
>
> Proposal: accept this PR
>
> Accepted.
>
> 2.4. PR #324: Proposed syntax and semantics for string templates
>
> See [25]pull request #324. We already have one approval for this PR.
>
> MK reviews the XQuery version.
> * MK: I moved string constructors and string concatenation into the
> same section.
> + ... Proposed syntax is to use backtick delimited strings.
> + ... The fixed part is just what it says, with escaped
> delimiters unescaped.
> + ... The variable part works like attributes in XQuery (but not
> exactly like XSLT, unfortunately)
> + ... That's it, except for a few complications.
> + ... One complication is that ampersands are treated slightly
> differently.
> + ... There's also a tokenization ambiguity: ``[1]. It's
> resolved in favor of string constructor on the longest token
> rule.
> * MK: If we didn't have that rule, then XPath and XQuery would behave
> differently.
> * DN: In other programming languages, this is called "string
> interpolation", maybe we should use the same term.
> * DN: I think there could be more than one variable part in a string
> interpolation, but the prose suggests that there can be only one.
> * MK: It certainly can be more than one, as the syntax makes clear.
> * DN: Okay, maybe there should be at least one example with more than
> one variable part.
> * MK: That's already true!
> * CG: The name "template" is more familiar to me, it's like
> JavaScript.
> * MK: Yes, languages have different names for the same thing but
> slightly different syntaxes.
> * RD: The XSLT spec already uses "attribute value templates" and
> "text value templates".
> * MK: We could call this "string value templates" if we really wanted
> to.
> * RD: I think internal consistency is more important than consistency
> with other languages.
> * MK: The thing I always ask myself is, if someone comes across this
> term in an error message and hasn't read the spec, are they going
> to guess correctly what it's referring to.
> * SF: They're called "template literals" in JavaScript. In others
> they're called by different names.
> * MK: I don't want to cause it a literal because it's an expression.
> * DN: I wasn't trying to force another name, I just thought it would
> be useful to mention "string interopolation" in the prose.
> * SF: We should include "string interpolation" and "template
> literals".
>
> Proposal: accept this PR
>
> Accepted.
>
> 2.5. PR #308: Improve the legends in the diagrams
>
> See [26]pull request #308.
>
> NW introduces the changes.
> * NW: Last week, several folks said these should just be lists. So I
> just made them lists!
> * RD: Would it be possible to move the legend to the right?
> * NW: I'll see what I can do.
>
> Proposal: accept this PR
>
> Accepted.
>
> 3. Any other business
>
> * RD requests issue #307 for the agenda next week.
>
> References
>
> 1. https://qt4cg.org/meeting/minutes/2023/01-31.html#minutes
> 2. https://qt4cg.org/meeting/minutes/2023/01-31.html#new-actions
> 3. https://qt4cg.org/meeting/minutes/2023/01-31.html#administrivia
> 4. https://qt4cg.org/meeting/minutes/2023/01-31.html#roll-call
> 5. https://qt4cg.org/meeting/minutes/2023/01-31.html#agenda
> 6. https://qt4cg.org/meeting/minutes/2023/01-31.html#approve-minutes
> 7. https://qt4cg.org/meeting/minutes/2023/01-31.html#next-meeting
> 8. https://qt4cg.org/meeting/minutes/2023/01-31.html#open-actions
> 9. https://qt4cg.org/meeting/minutes/2023/01-31.html#technical-agenda
> 10.
> https://qt4cg.org/meeting/minutes/2023/01-31.html#h-0BCF3769-7D91-45D1-8D2E-12E48F9E6757
> 11.
> https://qt4cg.org/meeting/minutes/2023/01-31.html#h-8455483D-D0AF-499A-A74A-552B33A9F395
> 12.
> https://qt4cg.org/meeting/minutes/2023/01-31.html#h-C5A6E1C0-5D39-44D5-AEE5-C31BB5386E20
> 13.
> https://qt4cg.org/meeting/minutes/2023/01-31.html#h-F2F35033-A57A-4FE6-B7ED-CF7A4B15983D
> 14.
> https://qt4cg.org/meeting/minutes/2023/01-31.html#h-7C58A4CA-1101-4222-A9D8-4304E75F0B76
> 15. https://qt4cg.org/meeting/minutes/2023/01-31.html#any-other-business
> 16. https://qt4cg.org/meeting/agenda/2023/01-31.html
> 17. https://qt4cg.org/meeting/minutes/2023/01-24.html
> 18. https://qt4cg.org/meeting/agenda/2023/02-07.html
> 19. https://github.com/qt4cg/qtspecs/pull/330
> 20. https://github.com/qt4cg/qtspecs/pull/330
> 21. https://github.com/qt4cg/qtspecs/pull/330
> 22. https://qt4cg.org/dashboard/#pr-319
> 23. https://qt4cg.org/dashboard/#pr-320
> 24. https://qt4cg.org/dashboard/#pr-326
> 25. https://qt4cg.org/dashboard/#pr-324
> 26. https://qt4cg.org/dashboard/#pr-308
>
> Be seeing you,
> norm
>
> --
> Norm Tovey-Walsh
> Saxonica
>
Received on Thursday, 2 February 2023 15:17:10 UTC