- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 25 Oct 2022 17:47:40 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m21qqv4zoa.fsf@saxonica.com>
Hello,
The draft minutes from today’s meeting are now available:
https://qt4cg.org/meeting/minutes/2022/10-25.html
QT4 CG Meeting 008 Minutes 2022-10-25
Table of Contents
* [1]Draft Minutes
* [2]Summary of new and continuing actions [0/6]
* [3]1. Administrivia
+ [4]1.1. Roll call [10/13]
+ [5]1.2. Accept the agenda
+ [6]1.3. Next meeting
+ [7]1.4. Approve minutes of the previous meeting
+ [8]1.5. Review of open action items [4/7]
* [9]2. Technical Agenda
+ [10]2.1. Review pull request #197 (was 166; variadic
functions)
+ [11]2.2. Review pull request #199 (was 177; items before,
etc.)
+ [12]2.3. Review pull request #202 (was 196; subtyping)
+ [13]2.4. Review pull request #207: new fn:QName#1 variant
+ [14]2.5. Review pull request #217
+ [15]2.6. Review pull request #215
+ [16]2.7. Issue #96, starting/ending sequence functions
* [17]3. Any other business
Draft Minutes
Summary of new and continuing actions [0/6]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-005-03: RD to review the variadic functions proposal in
#197 (formerly #166)
* [ ] QT4CG-007-05: NW to make an issue for Martin's proposed
ammendment to map:build
* [ ] QT4CG-008-01: MK to review RD's comments on PR #202
* [ ] QT4CG-008-02: NW to review MKs comments on PR #215
* [ ] QT4CG-008-03: MK to make a PR for issue #96,
starts|ends-with-sequence
1. Administrivia
1.1. Roll call [10/13]
Regrets: BTW, JK expected at [0:15]
* [X] Anthony (Tony) Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Christian Gr¸n (CG)
* [X] Joel Kalvesmaki (JK) [0:15-]
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Ed Porter (EP)
* [ ] Liam Quin (LQ)
* [ ] Adam Retter
* [X] C. M. Sperberg-McQueen (MSM)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW). Chair. Scribe.
1.2. Accept the agenda
Proposal: Accept [18]the agenda.
Accepted.
1.3. Next meeting
The next meeting [19]is scheduled for Tuesday, 1 November. Any regrets?
Note well: next week, the United Kingdom and Europe will no longer be
on daylight saving time. Please confirm the meeting time in your time
zone!
* DN: I may have to leave at half past the hour.
1.4. Approve minutes of the previous meeting
Proposal: Accept [20]the minutes of the previous meeting.
Accepted.
1.5. Review of open action items [4/7]
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-005-03: RD to review the variadic functions proposal in
#197 (formerly #166)
+ Reviewed the previous version; just started looking at it from
the updated revision
+ I have noticed that PR contains various other commits (NW
thinks this is rebasing)
* [X] QT4CG-008-01: MK to implement the resolution of issue #165
(":=" and no "$")
+ Absorbed into the current version of the variadic proposal
* [X] QT4CG-008-02: NW to fix or replace #199, it doesn't reflect the
original correctly
+ [21]https://lists.w3.org/Archives/Public/public-xslt-40/2022Oc
t/0046.html
* [X] QT4CG-008-03: NW to make the GitHub PR link to the diffs
+ Automation withdrawn,
[22]https://lists.w3.org/Archives/Public/public-xslt-40/2022Oc
t/0047.html
* [X] QT4CG-008-04: RD to review pull request #202
+ Completed.
* [ ] QT4CG-008-05: NW to make an issue for Martin's proposed
ammendment to map:build
+ Continued
2. Technical Agenda
2.1. Review pull request #197 (was 166; variadic functions)
* See [23]pull request #197 (you'll find links to formatted versions
of the specs at [24]https://qt4cg.org/).
* See also the nexus of issues [25]#162, [26]#161, [27]#160,
[28]#159, [29]#158, [30]#157, and [31]#155.
* See the discussion from [32]two weeks ago and [33]last week.
Anything to discuss today?
* MK: There's been useful feedback: minor technical corrections and
editorial suggestions.
+ I think I can implement those and make a draft everyone will
accept
* MSM: The rules for binding arguments to parameters say something to
the effect that at such-and-such a point all the arguments will be
optional, but that's not true.
* MK: Yes, we need a new rule that says that's an error.
* MSM: I'd like to read it one more time.
MK will update the PR to address feedback.
The expectation is that we'll have a proposal we can all accept by next
week and we'll propose to accept it. Please review it before the
meeting.
2.2. Review pull request #199 (was 177; items before, etc.)
* See [34]pull request #199
* Updated by NW to correct the errors [35]observed last week.
Mike gives a brief tour, scrolls through the diffs to F&O.
* MK: We're proposing fn:items-before(), fn:items-after(),
fn:items-starting-where() and fn:items-ending-where()
+ ... Minor typo, fn:items-after() uses fn:items-before() in an
example.
* RD: Where these say "the function then returns", that could be
misinterpreted.
* MSM: It kind of has to be that way because we first define $P.
Agreement that both paragraphs are connected.
* MK: These functions are all obviously very similar.
* JL: Am I correct in thinking the difference between the `where' and
`before' and `after' versions from before is whether the boundary
is included or not?
* MK: Yes.
* CG: I had a fairly general comment in the original issue [36]#149.
I note that many languages have functions take-while() and
drop-while() that do more or less the same thing. My basic question
is, do we need to reinvent the wheel, or would there be value in
using the existing function names and semantics?
* MK: Sometimes names from other lanaguages just don't fit our
conventions at all. I don't see any particular problems with
take-while() and drop-while() except that they don't immediately
suggest ot me where the boundary condition is.
* MSM: I like names that are noun-phrases, not verb phrases.
* MK: We do have some function names that are imperative verbs...we
aren't consistent.
* MSM: Yes, but when faced with a choice...
Proposal: accept these wit the correction to the example?
Accepted.
2.3. Review pull request #202 (was 196; subtyping)
* See [37]pull request #202
Mike reviews.
* MK: This primarily affects the XPath spec and text that's common to
XQuery.
+ ... This is essentially editorial, straying into technical
choices about how things are stated.
+ ... It doesn't change any of the semantics.
+ ... Main purpose was to clarify the presentaiton of the
subtyping rules.
+ ... Also fixing a bug raised against 3.1 in terms of a
reliance on things having a most specific dynamic type which
isn't true for functions, for example.
+ ... Trying to get rid of the reference to the dynamic type of
a value; it doesn't compare the type, it just determines if
the sequence type matches.
Some discussion of how the phrase "this is a subtype of" relates to the
comparision of types and the comparison of values with types.
* MK: In 3.6.2, we see some new defined terms used.
+ ... Added reference to the subtyping rules
+ ... The main thing in 3.7 is that the very long list of 35
bullet points has been expanded into subsections with headers
and examples. I've also introduced some notation to try to
make the charts clearer. (Not usefully presented in the diff!)
+ ... It assumes we're going to agree enumeration types
+ ... If I've got it right, none of the rules have changed!
* RD: I've included these in my reviews, but in the section on union
type matching, I found it confusing. There's an example of where
two types can be different because of the union member ordering. I
think you meant to swap one of the type member orderings because
they're the same order but you have the cast as...
* MK: Yes, I remember you pointing that out...
* RD: I'm referring to section 3.7; in the second note about subtype
not being acyclic. The two unions are the same, I think you meant
to flip one of them.
* MK: Yes, I think that's right.
* RD: I also tried to make the wording a bit clearer in my review
comments. I also have some comments about a couple of bugs that
might be in the general rules.
* MK: Give me an action to review RD's comments on this proposal.
ACTION QT4CG-008-01: MK to review RD's comments on PR #202
Note from scribe: what follows is a bit confused; MSM was having issues
with audio so this is partly transcribed from chat and partly read out
from chat.
* MSM: I am concerned about the assumption that all atomic types
which contain a given atomic value have a meet (greatest lower
bound) which is in the type lattice. That may be true (I think it
is but haven't thought much) for the built-ins, but it is not
guaranteed for all schema-defined atomic types
* MK: I think the point here is that it relates to the discussion we
just had on one of the GitHub reviews. We're never concerned about
whether or not type contains a value. They're constructed with a
particular type. The fact that a value would be valuid as an
xs:short for example, is irrelevant if it's constructed as an
xs:positiveInteger. It's not an instance of an xs:short even if it
would validate as one!
* MSM: For atomic values in particular, there is always one dynamic
type that is specifically associated with the value, so we can
refer to the dynamic type of an atomic value without ambiguity;
this will be a subtype of all the other types that it matches.
* MK: I think that's true.
* MSM: That's from the dynamic evalutaion phase.
We'll come back to this next week.
2.4. Review pull request #207: new fn:QName#1 variant
* See [38]pull request #207
Mike continues to drive...
* MK: We exend the semantics of fn:QName to take one or two
arguments.
+ ... When we have the proposal on variadic functions accepted,
we'll still have two functions because the arguments are
different
+ ... This departs from our usual precedent that the different
fucntions have corresponding arguments and some are defaulted.
+ ... In this case, the meaning of the first argument is
different between the two variants
+ ... The two argument form is unchanged.
+ ... the single argument form is new and does what it says. In
particular, it provides a way to build QNames from EQNames.
* JL: Since this is effectivley two different functions that produce
the same type output, I'm not sure they should have the same name.
It's counter to what we've done before. I'd have qName-from-EQName
for the first one. Otherwise, what do you do with currying on the
first argument?
* MK: I think it's just so conveneint to be able to construct a QName
from an NCName or an EQName with a function calle fn:QName that any
other name seems contorted.
* RD: Can't you do the first two bits from xs:QName?
* MK: Yes, but I thought it was convenient here to have one function
that does it all
+ ... One, because it's eaier to remember
+ ... Two, you don't want to have to work out what kind of input
you have before you decide what to call.
* RD: Couldn't we have fn:parseQName(), consistent with
fn:parseXML()?
* MK: We could do that.
* RD: That would make it clearer what it's doing. I think of fn:QName
as constructing a QName given an namespace URI and a local name.
In chat, JK gives +1 to the suggestion. MSM agrees.
* DN: Isn't this what an xs:QName() constructor does?
* MK: We don't have a constructor for the EQName string.
* DN: Can't we redefine the constructor?
* MK: No, it has to be consistent with XSD.
Consensus leans towards two functions. No one objects.
Proposal: Address the single argument functionality with a new function
named fn:parseQName().
Accepted.
Mike will submit a PR. If we get a couple of approvals and no
objections after a couple of days, we'll regard it as accepted and
merge it without further discussion next week.
2.5. Review pull request #217
* See [39]pull request #217
* MK: This fixes a bug in the grammar.
Proposal: Accept this PR.
Accepted.
* DN: Why are all the specs changed?
* NW: They aren't; it's impossible to tell what specs will be
changed, so we have to build them all.
2.6. Review pull request #215
* See [40]pull request #215
* MK: What's the status here? I made some comments...
* NW: Apologies, I missed them.
ACTION QT4CG-008-02: NW to review MKs comments on PR #215
2.7. Issue #96, starting/ending sequence functions
MK [41]proposes that [42]this issue may be ready to be decided.
* DN: This is a sequence generalization of the string functions
fn:starts-with() and fn:ends-with(). I've provided an
implementation for all the exmples in pure XPath. Everything should
be clear. I think these are useful convenience functions.
* MK: Any reason not to include a contains sequence function?
* DN: There is [43]another issue about that because there are
questions about contiguous or not-contiguious subsequences.
* DN: I thought that when we were are looking at the argument types
question, we could have at least a flag that says treat a string as
a sequence of codepoints. If we had this, then we could have just
these functions on sequences.
* RD: That wouldn't work for collations.
* MK: It would only work for the Unicode codepoint collation.
Some discussion of the names.
JK: This could be useful if we're really going to introduce composite
keys in maps. It'd be easy to check in a key.
ACTION QT4CG-008-03: MK to make a PR for issue #96,
starts|ends-with-sequence
* DN: I want to draw your attention to the compare argument which
probably we could think about having a better default after we have
decided about options on the fn:deep-equal() function. We want this
function to return false and not raise an error.
* MK: We can do that by using fn:deep-equal and using partial apply.
3. Any other business
* JL: Heads up, in two weeks time at least three of us will be at
[44]Declarative Amsterdam.
References
1. https://qt4cg.org/meeting/minutes/2022/10-25.html#minutes
2. https://qt4cg.org/meeting/minutes/2022/10-25.html#new-actions
3. https://qt4cg.org/meeting/minutes/2022/10-25.html#administrivia
4. https://qt4cg.org/meeting/minutes/2022/10-25.html#roll-call
5. https://qt4cg.org/meeting/minutes/2022/10-25.html#agenda
6. https://qt4cg.org/meeting/minutes/2022/10-25.html#next-meeting
7. https://qt4cg.org/meeting/minutes/2022/10-25.html#approve-minutes
8. https://qt4cg.org/meeting/minutes/2022/10-25.html#review-of-actions
9. https://qt4cg.org/meeting/minutes/2022/10-25.html#technical-agenda
10. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-variadic-functions
11. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-items-before
12. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-subtyping
13. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-fn-qname
14. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-typeswitch
15. https://qt4cg.org/meeting/minutes/2022/10-25.html#pr-parse-uri
16. https://qt4cg.org/meeting/minutes/2022/10-25.html#issue-96
17. https://qt4cg.org/meeting/minutes/2022/10-25.html#any-other-business
18. https://qt4cg.org/meeting/agenda/2022/10-25.html
19. https://qt4cg.org/meeting/agenda/2022/11-01.html
20. https://qt4cg.org/meeting/minutes/2022/10-18.html
21. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0046.html
22. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0047.html
23. https://qt4cg.org/#pr-197
24. https://qt4cg.org/
25. https://github.com/qt4cg/qtspecs/issues/162
26. https://github.com/qt4cg/qtspecs/issues/161
27. https://github.com/qt4cg/qtspecs/issues/160
28. https://github.com/qt4cg/qtspecs/issues/159
29. https://github.com/qt4cg/qtspecs/issues/158
30. https://github.com/qt4cg/qtspecs/issues/157
31. https://github.com/qt4cg/qtspecs/issues/155
32. https://qt4cg.org/meeting/minutes/2022/10-11.html#pr-variadic-functions
33. https://qt4cg.org/meeting/minutes/2022/10-18.html#pr-variadic-functions
34. https://qt4cg.org/#pr-199
35. https://qt4cg.org/meeting/minutes/2022/10-18.html#pr-items-before
36. https://github.com/qt4cg/qtspecs/issues/149
37. https://qt4cg.org/#pr-202
38. https://qt4cg.org/#pr-207
39. https://github.com/qt4cg/qtspecs/pull/217
40. https://qt4cg.org/#pr-215
41. https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0017.html
42. https://github.com/qt4cg/qtspecs/issues/96
43. https://github.com/qt4cg/qtspecs/issues/94
44. https://declarative.amsterdam/
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 25 October 2022 16:48:56 UTC