QT4 CG Meeting 083 Minutes 2024-06-25

CG gives regrets.

• [X] Reece Dunn (RD)
• [X] Sasha Firsov (SF) [x:10-]
• [ ] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JLY)
• [X] Dimitre Novatchev (DN)
• [X] Wendell Piez (WP)
• [X] Ed Porter (EP)
• [X] C. M. Sperberg-McQueen (MSM)
• [X] Norm Tovey-Walsh (NW). Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

This next meeting is planned for 2 July.

• [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
• [ ] QT4CG-080-05: NW to add absolute property to the parse-uri output
• [ ] QT4CG-080-07: NW to update the build instructions in the README
• [ ] QT4CG-082-01: JLO to raise an issue about what to do when validation is requested but not possible.
• [ ] QT4CG-082-02: DN to work with MK to come to agreement on the fn:ranks proposal

• PR #1296: 982 Rewrite of scan-left and scan-right
• MK: DN and I went separate ways, but let’s look at the current proposal which I revised in light of DN comments. MK: The substantive part of the issue is that the two functions were inconsistent with other functions wrt the position parameter.
  • … I tried to add one, and in the process, discovered that fold-left and fold-right were specified incorrectly.
  • … So I took the other approach and removed the position argument from all of them.

MK discovers that the PR doesn’t contain the latest version. We’ll leave it for a week.

• DN: I applaud the decision to remove the position parameter.

• PR #1295: 1096 Redefine array:index-of to use deep-equal for comparisons
• MK: This is an issue that I raised. The original topic was that array:index-of as an accident of the way it was specified atomized one argument but not another. That gave some unexpected behaviors.
  • … That lead to a long discussion. There was a strong desire to have something parallel to sequence indexing.
  • … The proposal I’ve come up with is that we define array:index-of using fn:deep-equal.
  • … I’d support deleting the function entirely, but at least this is simple and consistent.
• DN: I’m pleased to see that collation is the last parameter. Probably a sequence of collations is necessary. If the member of the array contains strings in different collations, then you’ll need different collations for the comparisons.
• MK: That sounds pretty radical. I think if you want that degree of sophistication, you have to do it by hand.
• DN: One collation isn’t sufficient if you have a sequence of strings in different collations.

Some discussion of whether or not this is a problem that needs to be solved.

• MSM: On the topic of collations of properties of strings; that was not only proposed for 2.0, it was also proposed for XSD. The I18N group objected strenuously. I didn’t find the arguments especially persuasive, but the W3C did. It’s clear that many people with experience in internationalization would object to that. I think we shouldn’t go there.

Proposal: Accept this PR.

Accepted.

• PR #1294: 46 Add xsl:item and xsl:sequence/@as
• MK: This takes a number of issues raise separately and attempts to address them all.
  • … The xsl:item is designed to avoid the xsl:sequence when you know the item is going to be a singleton.
  • … Adding an as attribute lets you use stronger type checking and more self-documenting code.
  • … The xsl:item instruction must return a single item, not a sequence or empty sequence.
• DN: I thought XSLT 3.0 was already too large. Now I’m seeing something that I don’t think needs to be done. An item is a kind of sequence. Why do we need a separate instruction? There may be alternatives, we could add an attribute to xsl:sequence for example.
  • … I think XSLT has become an ocean of different things and they aren’t totally exclusive. I get lost trying to determine which things I should use and when. Are we going to eventually get xsl:* everything in the dictionary?
• MSM: Relating to cardinality, if the difference between item and sequence is that item has fixed cardinality, then thinking about systems I have used, and the decision about the empty sequence, I would like to be able to specify empty-or-a-singleton and singleton. I think the as attribute on xsl:sequence would let me do that.
• MK: Yes.
• MSM: FWIW, I think I’m neutral on whether adding xsl:item is useful enough to justify it.
• JLY: Similar thoughts to MSM. You have a problem that if it might be empty, I have to use xsl:sequence. If I know it’s exactly one, I can use xsl:item. If I know there might be more than one, I have to use xsl:sequence again. And you can do it all with xsl:sequence using as.
• MK: Where this is coming from is that people find it more natural to write xsl:value-of which has exactly the wrong semantics.
• JLY: Yes. Maybe getting rid of xsl:value-of would be nice.
• RD: In terms of cardinality, there are four choices. Could we do this with a required attribute.
• MK: Yes, I thought the same thing, you could add optional=true.
• RD: It would make sense required by default and sequence optional by default. That’s probably what most people would want. Does that solve the problem?
• MK: I don’t think you need anything on sequence because you can use as. You could allow ? on an as attribute on xsl:item.
• JK: The motivation for as seems to be that anything with a select should have an as. What problem are we solving?
• MK: I must admit, adding as to xsl:sequence which defines the result of the expression. At the moment we only have as on places where you’re defining an API. This does open the way a little bit for demanding an as attribute in many more places.
• RD: How about anywhere there’s a select?
• MK: Well, xsl:attribute and xsl:processing-instruction have a select attribute and it would be overkill there.
  • … An as attribute changes the behavior.
• MSM: Since I find that the only reason for me not to use as whenever I think about it is to delay errors until production! I can easily imagine wanting an as attribute on xsl:attribute if I want to specify something about the attribute type.
  • … The same is true of specifying the target of a processing instruction.
  • … The extent to which this might change the behavior could be worrisome. I do find something appealing that says if it has a select you can have an as. It’s a little bit like making a particular form of assertion cheap and easy to express.
  • … If we decide to allow xsl:item to be optional, I really hate the idea of having an optional or required attribute. I’d much rather have it be a ? in the as.
• WP: What I’m hearing is that the problem is xsl:value-of which also has select. On balance, I think this addresses a very narrow concern with some users. I know plenty of people who like xsl:sequence and select because of the flexibility.
• JLY: If you put as on an xsl:item type, then it will be the on as attribute that has different semantics. You can’t put a + or * in those places.
• NW: We’re not coming to consensus here.
• MK: I could split it. Or we could drop it.
• MSM: I had the impression that adding as on select had positive to neutral reactions and much of the complication was xsl:item.

Straw poll: separate the proposals or drop the whole thing?

Separate proposals: 7. Drop: 1. Abstaining: 1.

MK will revise PR as he thinks most appropriate.

• PR #1290: Fix keyword tests to treat "fn" = "function"

Stylesheet only fix. Not discussed. MK: merge it!

• PR #1288: 1287 Define parse-xml error conditions
• MK introduces the proposed error conditions for parsing XML.
• JLO: That completes my action! Thank you. I like the dynamic error for DTD validation, but I’m wondering why FODC0007 is the same for either DTD or XSD validation.

Some support for having two different error codes.

• DN: What is the meaning of FODC0008? Is it a GUID or something?
• MK: No, the form of the error identifiers was introduced by Andrew Eisenberg and kept with the IBM tradition of 8 character names.

Some discussion of the semantics of the names.

Proposal: Accept this PR with the amendment that there should be two different error codes for DTD and Schema validation errors.

MK to merge after updating.

• PR #1286: Updated list of incompatibilities in F+O
• MK: We changed the rules on the options parameter. If you use a parameter that isn’t recognized. That’s a backwards incompatibility. I added that to the appendix.

Proposal: accept this PR.

Accepted.

• PR #1282: Revise fn:invisible-xml
• NW explains the changes.

Proposal: Accept this PR.

Accepted.

• PR #1262: 1160 Add collation-available() function
• MK: This changes the semantics of fn:collation. It now generates the string but the error is raised by fn:collation-available()
  • … The only interesting thing about fn:collation-available() is the usage parameter. There are three different reasons why you might want a collation and which collations might be available for each reason differs.
• JLO: I like this. I like the usage parameter. My question is why can’t I do a collation available for all of them? Suppose I want to use all three? Also: where you are using fn:collation-available() which usage is there?
• MK: No fn:collation() just builds the string. This function asks if it’s usable.
  • … I guess we could allow a sequence of enums.
• DN: We need something like union for the different usages. My observation was that we probably could just have a single function, fn:collation() and have it return an empty sequence if no such collation is available.
• MK: The fn:collation function can only be used to build UCA collations, but this function can be applied to any collation.

Some discussion of the UCA vs. vendor defined collations.

• JLY: Originally, collation would form the collation and error if it coudln’t. So the assumption now is that if you run it without checking the collection, the error will occur downstream.

ACTION: QT4CG-083-01 MK to revise fn:collation-available to address multiple usages

• DN: Even if we have usage specified, it doesn’t prevent the user from using it in another usage. That’s probably not something we can address statically. That raises questions about the usability of the usage parameter.
• MK: This function doesn’t stop any existing code from working, it gives the user the ability to avoid the error.