QT4 CG Meeting 008 Minutes 2022-10-25

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.

Proposal: Accept the agenda.

Accepted.

The next meeting 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.

Proposal: Accept the minutes of the previous meeting.

Accepted.

• [ ] 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
  • https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/0046.html
• [X] QT4CG-008-03: NW to make the GitHub PR link to the diffs
  • Automation withdrawn, https://lists.w3.org/Archives/Public/public-xslt-40/2022Oct/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

• See pull request #197 (you’ll find links to formatted versions of the specs at https://qt4cg.org/).
• See also the nexus of issues #162, #161, #160, #159, #158, #157, and #155.
• See the discussion from two weeks ago and 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.

• See pull request #199
• Updated by NW to correct the errors 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 #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 with the correction to the example?

Accepted.

• See 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.

• See 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.

• See 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.

• See 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

MK proposes that 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 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.