QT4 CG Meeting 024 Minutes 2023-02-28

Regrets: BTW

• [ ] Anthony (Tony) Bufort (AB)
• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:10-]
• [X] Michael Kay (MK)
• [X] John Lumley (JL)
• [X] Dimitre Novatchev (DN)
• [X] Ed Porter (EP)
• [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, 7 March 2023.

No regrets heard.

• [ ] 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.
• [X] QT4CG-021-03: RD to change must to will in DOM notes about lowercase
• [X] QT4CG-021-04: RD to revise and move the note about unrecognized entities
• [ ] QT4CG-023-01: NW to review the stylesheets for functions across XPath and XSLT
• [X] QT4CG-023-02: MK to write a PR to drop xsl:function-library from the spec.
• [X] QT4CG-023-03: MK to start a new thread for discussion function namespace flexibility
• [X] QT4CG-023-04: MK to review and develop a proposal for separating element and type default namespaces
• [ ] QT4CG-023-05: NW to put record types on an agenda.
• [X] QT4CG-023-06: MK to revisit and make a PR for an as attribute on xsl:mode

An email proposal from MK.

Mike walks us through the email.

• MK: Are any of these non-contentious?
  • #45, you can always write your own vendor-defined version
  • #60, the function assumes you can downcase strings, so there’s no issue except perhaps the previous error code
  • #112, leave open for now
  • #147, no concrete proposal, close
  • #260, essentially indistinguishable from array:index-where
    • DN: I think it’s confusing to have functions with different names in this area.
      • … I think we should also have array:deep-index-of, I will propose that
      • … Please keep this one open.

ACTION QT4CG-024-01: MK to add namespace-uri-for-prefix argument changes to the compatibility appendix

See pull request #320. We ran out of time while discussing this in meeting 22.

• CG: Let’s look at the comments in the PR
• NW: Good idea.

We turn our attention to PR #320 comments.

• CG: I think we should consider unordered-children as a better name.
• MK: The property is a set of element names that has the semantics that there is no ordering among any of the children of those elements.
• CG: My idea was we could ignore the order of nodes generally and not consider comments or elements; I think we could avoid looking at element names.
• MK: All children of all elements? That seems unlikely to me
• RD: I think one case where the generalization could be useful is in unordered content of key values. Possibly. But I don’t see any other cases where that would apply.
• MSM: In general, I’m a fan of anything that’s a generalization, but I don’t understand. Does anything have children other than an element?
• CG: A comment could occur before or after an element.
• RD: Deep equal also applies to sequences of items.
• MSM: But do any of the items have anything that our specs call “children”
• MK: Should we look at what the proposed spec actually says?
• MSM: Yes, but calling it unordered-elements does make me wonder if users might think they should name the elements whose order doesn’t matter!
• RD: Should we have separate issues for generlizing this?
• CG: It might make sense to have a use case that clarifies the usefulness of unordered comparisons.

MK brings up the specification prose.

• MK reads clause J.IV.
  • … It is about the order of all of the children of selected elements.
• MSM: Can I specify ‘*’ as an option?
• MK: Not at the moment, but we could add that.
• JL: Is there a case for this to allowed to be wildcarded in the namespace or the local name?
• MK: It just makes the API more complex.

General agreement that there might be use-cases for both of those

• CG: Would it be possible to write the test for permutations in XQuery?
• MK: Yes, perhaps, but it’s not easy.

MK describes the implementation he’s got which uses a hashcode for each child and then compares the hashcode in an N^2 comparison.

• RD: You could do something similar in XQuery if you had a version of deep-equals that returned the hash
• MK: I’d like to say we’re not completely happy with unordered-elements, so take it out and reopen it as a new issue.
• MSM: I’d be happy to accept the proposal with the current treatment for unordered elements and consider adding wildcards as a new issue.
• JL: I’d agree with that.
• DN: It seems to me that this function is extremely complicated. I think we should break this into simpler problems. We could have a function deep-equal and then have different functions for each case: documents-equal, elements-equal, atomic-values-equal, etc.
• RD: In terms of this function, the complexity in the implementation already exists. Effetively all this proposal is doing is allowing certain of the deep-equal features to be optional. Well, mostly. A lot of the complexity is already there. If you have a complicated structure where you have a map of elements or a map of arrays of elements, you’ll have to pass through the options. I don’t think you can separate out the different behaviors that this function is doing.
• MK: DN has come up with an interesting alternative idea, can we ask him to expand on that so we can compare them.
• DN: What is the task?
• MK: Rather than these boolean options, propose an alternative design.

ACTION QT4CG-024-02: DN to develop an alternative proposal for deep-action.

• DN: I have very strong objection to not making treat-errors-as-false the default.
• MK: I’m very reluctant to have a situation where something is not equal to itself by default.

Some discussion of the NaN problem; the assertion is that these are exceptional cases.

• RD: Different languages can specify different comparison behaviors. JavaScript and Java specify different behavior on things like NaN. I think one of the difficulties with trying to fit rigerous mathematical descriptions of numeric types is that you run into issues like the numbers are fixed, limited value. While 300 is a valid integer, it’s not in the set of unsigned bytes. If you add two unsigned bytes you can…
• MK: I’d like to observer that this is a change to how deep-equal handles node trees, not numbers. Can we do that separately?
• DN: We need a comparison function in lots of places and it should always return a value. The only thing we don’t agree on is what to do when there are two function items. We can just consider them unequal unless there’s some way to show that they’re equal. I don’t like that a set of one function item would not be equal to itself. But that’s just a special case.
• NW: This is just about the default? (Yes.)
• CG: I think those (NaN, INF, etc.) are separate issues like MK and RD said.
• JK: I support the proposal; but we only got half way down through the issues…
• JK: The two-whitespace options appear to have overlapping domains.
• MK: Yes, I wish there was a better way.
• JK: I think you need to specify what happens in the overlapping cases, and to make the defaults such that there isn’t any overlap. I vote for normalizing true and stripping false.
• MK: I think the rules are all there; I think I tried to clarify the description on the basis of these comments.
• RD: In XQuery there’s a boundary-space property…
• MK: The first thing to do is factor out what the options are. Normalizing whitespace where there’s a mixture of text nodes on the one hand, stripping indentation on another.
• JK: I think there are probably three levels of stripping.
• MK: Yes, probably.
• MSM: Can someone describe the three options?
• MK: The “ruthless” option is that you remove all text nodes that are whitespace only and you also normalize space in text nodes that contain a mixture of whitespace and non-whitespace characters.
  • … The next option is that you ignore “layout whitespace”, but you treat whitespace in other nodes as significant.
• MSM: Every memory I have of phrases like “layout whitespace” is painful.
  • … I think there are three levels in XSD but I don’t think they have the same kind of “black pit” quality.
  • … The middle ground is that adjacent whitespace characters are replaced with a single blank.
• RD: We’ve got “not preserved” and “not normalized” and “not preserved” and “normalized” which are the same thing. … RD describes the other options in the state table…
  • … So I think all the options make some kind of sense.
• MK: The note in the spec now attempts to present the synthesis of the options.

Proposal: accept this PR, with three new issues:

1. What should the default be for the issue of errors
2. Can whitespace handling be improved?
3. Can the specification of unordered be improved?

ACTION QT4CG-024-03: NW to create issues for improving fn:deep-equal