- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 31 Jan 2023 17:17:30 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m25ycmk4g0.fsf@saxonica.com>
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 Tuesday, 31 January 2023 17:19:15 UTC