QT4 CG Meeting 081 Minutes 2024-06-11

CG gives regrets.

• [X] Reece Dunn (RD) [x:10-]
• [ ] Sasha Firsov (SF)
• [ ] 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)
• [ ] 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 18 June.

CG gives regrets for three weeks.

• [ ] QT4CG-063-06: MK to consider refactoring the declare item type syntax to something like declare record
• [X] QT4CG-077-03: MK to add a note about document order across documents
• [ ] QT4CG-077-04: MK to review inconsistencies discovered in review of #1117
• [ ] QT4CG-078-01: MK to make the default for normalize-newlines backwards compatible.
• [ ] QT4CG-079-01: WP to seek expert advice on hashing functions.
• [ ] QT4CG-080-01: NW to add what the DocBook stylesheets do for this function
• [ ] QT4CG-080-02: NW to fix issue classification so PR #1181 isn’t misclassified as an XSLT issue
• [ ] QT4CG-080-03: MK to make a separate issue for @as on xsl:value-of
• [ ] QT4CG-080-04: NW to revise p:invisible-xml
• [ ] QT4CG-080-05: NW to add absolute property to the parse-uri output
• [ ] QT4CG-080-06: NW to investigate the cross-spec reference errors in the build
• [ ] QT4CG-080-07: NW to update the build instructions in the README
• [ ] QT4CG-080-08: MK to work out what happened to his next-match PR
• [ ] QT4CG-080-09: MK to address comments made on PR #832
• [X] QT4CG-080-10: NW to find out if we can change the community group name

Let’s see if there’s any follow-up discussion from the face-to-face now that the minutes have been published for a few days.

• JK: As a result of the face-to-face, do we know when we’ll finish?
• NW: I think this is the first step in “turning the ship.”
• MK: I think I came away with a good sense of what we need to do.
• WP: What are we publishing?
• NW: The whole kit-and-kaboodle.
• JLY: Who’s implementing? Just Saxonica and Base X?
• MK: There are a few more implementors, but they may be doing partial implementations.
  • … We have no formal requirement to demonstrate two complete, interoperable implementations.

See PR #1260

• MK: This arose from a real-world example. We can’t support German accounting standards at the moment, apparently.
  • … Adds a third argument to fn:round().
• RD: Would it be worth in fn:round-to-even() stating that it’s equivalent to one of the fn:round() options.
• MK: Yep.

Proposal: Accept this PR.

Accdepted.

ACTION: QT4CG-081-01: MK to update fn:round-to-even to point to fn:round

See PR #1259

• MK: CG raised a grammar ambiguity. I’ve added an extra-grammatical constraint to resolve the issue.
  • … It only arises in XQuery, but I’ve said it should be rejected in XPath (in case we add things to XPath in the future).
• RD: It’s good to make it illegal in XPath in the short term.
• WP: It also arises because you’re using keywords as element names.
• DN: Tangentially, perhaps we could adopt a convention for identifying rules. When you add a new rule, you have to remember all the other rules.
• MK: It’s an interesting point. We have all these rule numbers but we never use them.
• NW: I think they’re useful where the snippet is copied in a new context.
• JK: I’ve found them useful.
• MK: What about stable numbers in the grammar?
• JK: If the names are unique, you don’t need separate parallel one, but the reader needs some nomenclature to indicate that they’re looking at a copy.
• RD: I don’t think it’s worth adding another identifier that is unique when we’ve got the unique name vs. the numbering.
  • … The ordering issue is if we want to add new grammar rules to the end or whether we want to keep them colocated within the relevant section.
• JLY: I’ve lived with this a long time. The order is important. The numbers do give you an idea of where you are.
• DN: We can still do with numbers, just spread them out so there’s space between them.

ACTION: QT4CG-081-02: NW to make an issue about how grammar productions should be identified

(The scribe failed to record our decision, but believes there was consensus to accept this PR.)

See PR #1258

• MK: This is the issue that we’ve made the default for a new parameters so that numbers got converted to double rather than remaining as they were.
  • … This PR changes the double function to the identity function.
  • … You can still get doubles if you want.
• RD: Does this now mean that you could pass in a non-JSON atomic type value.
• MK: This function only gets called if the string is recognized as a number.
  • … There are some options for vendor extensions, but generally this is only called when it matches a JSON number.
• RD: If it’s written as a number without quotes, it’ll be an xs:decimal.
• MK: No, assuming that the XML isn’t being schema validated, we’re generating an element whose name is number and whose content is a string.

Proposal: Accept this PR

Accepted.

See PR #1257

• MK: We identify lots of things we need for options parameters. I thought I’d make a start with fn:parse-xml and fn:parse-xml-fragment.
  • … For fn:parse-xml, the starter set I put in are base-uri, dtd-validation, strip-space, and xsd-validation.

MK walks through the description of the various options.

• JLY: What was the justification for not giving more power to strip-space?
• MK: Syntactic complexity and how to package it into an options map.
• JLY: And you could do it in post-processing.
  • … Also, when you have the xsd-validation, do you need the word type before the EQName?
• MK: I was thinking of extensibility, in case you want an EQName for something else.
• RD: For the strip-space option, there is a boundary space policy in the static context.
  • … That has preserve and strip as options. Would it make sense to make the default that static context value?
• MK: I don’t think so. For XSLT, I haven’t said it defaults to the XSLT-defined rules either.
  • … I don’t think it makes sense to use the same rules for different kinds of documents.
  • … You might import a data-oriented document when your “primary” document is text.
• RD: Would it make sense to call the option “boundary-space” and have preserve and strip?
• MK: Boundary space has a lot of baggage associted with braces as well as brackets.
• RD: Should we allow preserve and strip as options?
• JLO: I think a lot of this applies to the fn:doc functions as well. Should we have them in a central place to make them reusable?
• MK: As I said, this was a starter set with one function. If we find a way to reuse them, then we could.
• DN: I thought we were talking about using records for using options like this. If we used a record, we could reuse it.
• MK: We are using a record. It’s not using the record type in the signature.
• DN: That’s confusing.
• MK: I think we’re going to find reuse at individual options, but not necessarily the whole record.
  • … Some of parse-xml will be common with the doc function, but others may be common elsewhere.
• DN: If a record has more than one optional field.
• NW: I think it would be a mistake to try to compose tiny records. That’s not helpful to the reader.
• JLY: Can we use variables for handling these things? Forming compound records from variables, or make the records extensible. You could have a common one that goes across a number of calls.
• RD: I was going to mention, we should make these extensible to allow vendors to allow their own options. If we do find that several functions have the same set, we can defined named record types for them.
• MK: I think the records probably should be extensible.
• JLO: The function signature says the default is an empty map. Do we want to say that instead of an empty sequence? I could call fn:parse-xml with just one parameter.
• MK: You’re right, that should be optional.
• JLY: Can we have a parse-xml that produces an empty document?
• NW: No, that doesn’t parse.

Proposal: accept this PR.

Accepted.

ACTION: QT4CG-081-03: MK to make the options parameter optional in fn:parse-xml and fn:parse-xml-fragment

See PR #1256

• MK: I added the sentence that the option parameter conventions apply.
  • … Spelled out a little more what the returned parsing function.
• RD: Should the return type of the returned function be document-node
• NW: I think it could be changed that way.
• JLY: What does it do about ambiguity?
• NW: What it says on the box: one document marked ambiguous.
• DN: What’s the point of an empty grammar?

Some discucssion

ACTION: QT4CG-081-04: NW to update the function signature of fn:invisible-xml ACTION: QT4CG-081-05: NW to describe why the grammar option can be empty on fn:invisible-xml

Proposal: accept this PR.

Accepted.