QT4 CG Meeting 022 Minutes 2023-02-14

Regrets: BTW

• [ ] Anthony (Tony) Bufort (AB)
• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:08-]
• [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) [:06-]
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW). Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is scheduled for Tuesday, 21 February 2023.

Focus next week is XSLT; MK to help with the agenda.

Regrets: CG.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
• [ ] QT4CG-016-08: RD to clarify how namespace comparisons are performed.
• [ ] QT4CG-021-01: NW to raise a PR addressing the points in issue #307
• [ ] QT4CG-021-02: NW to check for deprecated URI features and add options for them in fn:build-uri and fn:parse-uri
• [ ] QT4CG-021-03: RD to change must to will in DOM notes about lowercase
• [ ] QT4CG-021-04: RD to revise and move the note about unrecognized entities

See pull request #342.

• MK: This is a bug from a Saxon user. The XHTML and HTML methods add meta elements with a content type. HTML5 has introduced a new meta element that doesn’t have a content type, it just says charset=. If we leave that one in the document, then you get an HTML validation error.
  • … Compliance with the serialization spec leads to invalid HTML.
  • … We fixed that in Saxon but now we’re not compliant with the serialization spec!
  • … This PR proposes to update the serialization spec.

The changes are all in the serialization spec.

• MK: I did some housekeeping; I dropped all the diff markup from before 3.1. Fixed a few whitespace issues.
• MK summarizes changes to section 4.
  • Some discussion of the change from “along with discarding” to “possibly replacing”

ACTION QT4CG-022-01: NW to investigate the illegible, dark blue background color in serialization

• MK discusses the changes in the beginning of 6.1.14.
• MK: Basically, this just licenses the new syntax if that’s what you choose to do.
• MK: It says pretty much the same thing for the HTML output method in 7.4.13.
• DN: Seems ok, but I’m a little bit concerned about using “might” and “may”. That means it depends on the implementation.
• MK: Yes, that’s a good point. I decided not to require that implementations use the new behavior. Some implementations might want to keep the old syntax.

Some discussion about the fact that it’s an implementation-defined result.

• NW: Perhaps making this a “should” requirement would help?

Some discussion of the fact that this only applies to the HTML5 output method.

• MK: Should we even continue supporting versions of HTML before 5 anyway?
• MSM: For what it’s worth, as a late adopter, I would be very unhappy if we got rid of HTML4 because that’s typically what I use.
  • … I do kind of like the idea that if we’re going to offer this as a choice we should add it to the list of things that are implementation-defined.

ACTION QT4CG-022-02: MK to add meta element selection to the list of implementation-defined things in serialization

• SF: Depending on the situation, I’d be rendering in XHTML or HTML5. That means I’d have to change how the meta tag differently in different cases.
• MK: They’re different output methods, but they share a lot in common. The way the spec is structured, they have to be described twice, but both methods take the same option.
  • … I don’t really understand how XHTML evolves as HTML5 changes.
• RD: Effectively, XHTML is an XML serialization of the HTML5 DOM.
• NW: That’s what I thought.
• DN: I’m happy we discussed this. We must be aware that I find this is a problem as a developer. I think if there are implementation defined things, maybe we should provide an appendix that shows the choices implementations made.

Some discussion of the appropriateness of adding this to the specification. The Schema WG did not find the process of trying to maintain this kind of thing easy or satisfactory.

DN remains concerned that there should be some place where the implementation defined features for all the implementations can be recorded.

• MK: Are you volunteering?
• DN: I don’t have much experience, but maybe.

Proposal: Accept this PR

Accepted.

See pull request #344.

• MK: I think this was originally raised by RD. The only question here is how far to go. I chose not to go very far. I changed things so that let and for can be repeated but not mixed.

MK shares the XPath spec for review.

• MK: SimpleForClause allows the keyword “for” as an alternative to “,” which makes it look more like an XQuery FLOWR expression with multiple “for”s
  • … The spec describes how the “for”s are syntactic sugar.
• MK: We do the same thing for let expressions in SimpleLetClause.
  • … This doesn’t preclude going further, but it’s a starting point.
• DN: Who needs this? We have the “,” why do we need repeated “for” or “let”?
• RD: It’s a preference thing; if you’re copying code from XQuery where you’ve used multiple fors or lets, or if you have an XQuery background, it will be what’s familiar.
  • … Kind of like how many languages support multiple variable declarations by commas or repeated specifications. (int x; int y; int j; vs. int x,y,j;)
• DN: Then maybe the prose should explain that.
• MSM: I’m kind of torn; MK has probably hit something of a sweet spot here, precisely because for/let and the “,” are synonymous. Because XPath is not quite the same as XQuery makes me have to think harder. And the fact that XPath is more restrictive, that helps me keep track of the boundary. Anything that makes it look more like XQuery makes me worry that I’ll have a harder time maintaining the distinction.
  • … As to the concern, why would anyone want to do this, I use repeated “for” instead of “,” as a rhetorical device. It lets me make it clear to six-months-from-now-me, that these are the variables I’m going to be changing and not these other variables. Using “for” to signal a fresh start is useful to me.
• JL: Something that’s bugging me: the “,” embedded after the let stands for “return let”. When “let” is embedded, it also means “return let”. But you could write “return let”, so you’ve got a weirdly redundant token!
• MK: It’s just saying you can leave out the return.
• RD: This is saying that these are defined in terms of single lets and single fors because XPath originally only had one. So you had to define the comma version as an expansion. Or was it something like that?
• MK: It allowed the “,” from the beginning. The reason that it was a macro was to avoid adding tuple streams of bindings to the semantics.
• DN: I hear what MSM is saying, that he doesn’t want XQuery to be mechanically put into XPath. I wouldn’t object to having in XPath an XQuery feature that gives us new functionality, but this doesn’t provide any new functionality.
• MK: From my perspective, I find laying things out with “,”s much more difficult. I’ve tended to standardize on putting the comma at the beginning of the line which is ugly. Putting it at the end makes it seems like part of the expression. The comma can disappear at the end of the line, but the “let” stands out more.
• DN: Then we should make sure that the spec says this is for readability or the other reasons so that it’s cleary.
• JL: The note at the end of 4.13 is an example of code that’s easier to read with multple “let”s.
• DN: I wouldn’t find it any harder to read if the second and following “let”s were replaced with commas.
• RD: We don’t have similar justification for any of the other parts of the spec.
• MK: There are lots of places where we do and lots of places where we don’t.
• EP: Wouldn’t it be just as good to put that in the changes appendix?
• MSM: I think the list of changes is the right place to say that this change is syntactic sugar. I sometimes react allergically when changes are described as for usability when I find them less usable.

ACTION QT4CG-022-03: MK to add a note about why multiple for and let clauses were added to XPath

Proposal: Accept this PR

Accepted.

(MK will provide the note and then we’ll merge the PR.)

See pull request #320. When last we met, Mike was working on test cases and an implementation. More detail is expected.

• MK: I have committed further changes. Let’s take a look.
• MK: Where are we…
• MK: The collation parameter should allow empty sequence.

ACTION QT4CG-022-04: MK to update the collation parameter on fn:deep-equal to accept an empty sequence.

• MK: I’ve renamed and clarified a few options.
  • … Added ‘base-uri’ to compare base URIs.
  • … There was a comment about consistency of ‘idref’ vs. ‘idrefs’
  • … I renamed one of the parameters to ‘normalized-space’ for consistency.

ACTION QT4CG-022-05: MK to make sure that the option list in fn:deep-equal is sorted lexicographically

• MK: XSLT users are familiar with ‘preserve-space’ so I went with that name.
  • … I expanded how equal-strings is described to include a code implementation.
  • … The rest is fairly mechanical…
  • … Added a note describing how the different whitespace handling options relate to each other.
  • … I decided not to consider xml:space attributes.
• MSM: If you say xml:space=preserve and two documents have different indentation, I will be preserved if they compare the same.
• MK: Basically, whitespace is significant unless you say it isn’t and there are a variety of ways to do that.
  • … There’s a note about what it means if you specify both preserve-space and normalize-space. Basically 1 space equals 2 spaces, but no zero spaces.
• MK: The only real error condition is trying to compare functions. You can get errors if you specify invalid options. I decided that ‘false-on-error’ doesn’t stop invalid options from being an error.
• MK: And I added more examples. And there are many more in the test suite.
• DN: I think this is very well done, but I would be more happy if the default for the option ‘false-if-error’ was true. We need a comparison function in many other places where we don’t want errors. If we can’t change it here, I want another function with exactly the same semantics but with false-if-error set to true.
• MK: But that means that some sequences aren’t equal to themselves, which bugs me.
• DN: This inequality-to-self happens only if there are special, abnormal values in the sequences such as NaN, plus or minus Infinity.
• RD: You can’t really disregard things like NaN and infinities when comparing values because in the IEEE specification, there’s more than one NaN. That’s one of the reasons why comparing two NaN values returns false.
• DN: It is a lie that 'INF' is equal to 'INF'. We all know that the infinity of all irrational numbers is greater than the infinity of all rational numbers. When the Domain of the comparison function has these abnormal values removed, then we truly have the property of reflexivity, and thus the comparison is an equivalence relation.
• MK: In deep-equal it returns true.
• DN: We should fix that too.
• MK: We’d need a new option if we wanted to change that.
• RD: When comparing things like NaNs and infinities, what you typically do is rely on the IEEE spec and things like the C comparison functions that have specific behavior. We may not like that behavior, but it is what it is.
• DN: I’m proposing a new function deep-comparison that doesn’t have backwards compatibility issues and can have any semantics we want.

We’ve run out of time. We’ll come back to this issue in two weeks; next week is an XSLT-focused meeting.