QT4 CG Meeting 175 Minutes 2026-08-11

MK, JK give regrets.

• [X] David J Birnbaum (DB)
• [ ] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [ ] Joel Kalvesmaki (JK)
• [ ] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [X] Wendell Piez (WP)
• [ ] 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 planned for 18 August.

JLO gives regrets.

The action item list in the agenda was incorrect.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-167-03: NW to make a PR for #2482, fallback on bin:decode-string
• [ ] QT4CG-167-05: MK to write a proposal to change #2393 so the functions return JNodes
• [ ] QT4CG-167-07: NW to review tests for interpolated strings with edge cases in mind
• [ ] QT4CG-167-09: NW to close all “nice to have” issues at the end of October if they haven’t progressed
• [ ] QT4CG-170-01: RD to draft a proposal that attempts to address the lexical issues differently.
• [ ] QT4CG-174-01: MK to make an issue or otherwise address CG’s comments on #2734.

This section summarizes all of the issues and pull requests that need to be resolved before we can finish. See Technical Agenda below for the focus of this meeting.

See PR #2707.

CG introduces the PR.

• CG: You know about fn:element-to-map that aids in the construction of maps and arrays to serialize as JSON.
  • … But there’s no way back, so I’m trying to write a function that does the inverse.
• CG: Some information is lost, like comments, processing instructions, whitespace, text nodes…
  • … That can’t be reconstructed, but in principle everything that’s created by the function can be converted back.
• CG: This function tries to provide a way back, but it doesn’t promise to convert arbitrary maps to elements.
• CG: The conversion of lists fails without a plan.
• CG: I tried to reject any input that can’t be converted back.
• CG: There are lots of rules…
• CG: All the options on fn:element-to-map are supported here too.
• NW: It’s not for general conversions, but we can’t tell that a map came from fn:element-to-map. Does that just mean you’ll fail if you encounter something unexpected?
• CG: Yes.
• JWL: Suppose I have a map in my structure that I’ve made myself and parts of it are node trees, would that be permitted? I can see a good case for supporting that.
  • … What I want to do is get something out that isn’t a map, but I want as much information as I can get.
• CG: I think the tricky part is how to decide when it’s expected what you want to create and when it’s an error.
  • … I decided to reject as much as possible, but maybe we should allow more things.
  • … We could have a liberal or strict mode; I’ve got a proposal to do that for fn:element-to-map.
• JWL: Can you show me the second example, the one with dates. What does “dates” mean in the plan?
• CG: It’s just a placeholder. I’ll think about that some more.
• WP: This is awesome. A lot of money has been spent on this kind of conversion problem. What is the relationsip between the plans and record types? Record types are a phenominal way to nail down the structure.
  • … We need to know how to go the other way and we also need to be able to publish plans for specific record types.
  • … I’d like to see this extended, even if it doesn’t have a complete mapping the other way, it’s going to be game changing.
• JLO: I’m also excited to see this. In the introduction, why doesn’t E => element-to-map(OPTS) => map-to-elements() end with => E. That would make it clearer to me.
• NW: But you don’t gets comments and processing instructions and such.
• AP: Could we call it E’?

Some discussion of deep-equal and the detection of comments and processing instructions.

• JLO: That’s mixed content in an array. Is there way to define that as really a text node, or is that impossible?
• CG: Basically, the rules are just inverted here. We could extend the existing rules for element map to make it easier to convert it back.
• WP: The data might start in JSON, and moving into XML might be a way to clean it.
• JLO: I have seen this @ notation and # content notation a lot. Is there a name for that?
• CG: It would have to be defined in the first part.

Proposal: merge this PR?

Accepted.

See PR #2789.

Skip. This one is MK’s.

See PR #2793.

• CG: This was already reviewed by MK. What we did last time was add named groups.
  • … And fn:replace also allows you to define named groups. I’ve added references for them in this PR.
• CG: The syntax is similar to other languages, \k<name>. And I added some examples.
• NW: Are those embedded angle brackets going to be a problem?
• CG: Not in XPath and XQuery, I don’t know about XSLT.
• NW: Yeah, that’s giving me a little bit of heartburn.
• CG: In fn:replace we’ve extended the type of the replacement text to be more flexible.

CG reviews some of the new examples.

• CG: In fn:analyze-string we make a few extensions as well. The name becomes part of the returned group element.
• JLO: Would it make sense to implement this in a way that if you don’t have named groups, you return an array not a map?
• CG: I think it’s problematic to have too many different return types. Patterns can also be dynamic, so static typing is much harder.
• WP: Maybe a default name to handle those cases? Naming them “1”, “2”, and “3” might be even more confusing.
• CG: If there aren’t names, we get positions.

Proposal: merge this PR?

Accepted.

See PR #2794.

• CG: Many different specs are involved, but most of them are only tables or schema stuff. The interesting part is in serialization.
  • … I’ve added a new output method for CSV.
• CG: The options for CSV are handled like the JSON options, they only apply to the CSV output method.

CG reviews the description of the method.

• CG: Other options, like the BOM, also apply.
• JWL: How many of the options are in common with the fn:parse-csv function?
  • … Should there be a common record structure?
• CG: Many of them are the same.
• CG: We tried to have one record type and be able to round trip the data with the same options.
• CG: But the keys need to be named differently because we don’t have the csv- prefix for the parsing maps.
• JWL: So it’s actually a grid, there’s common stuff in the CSV space, but you also have the other ones coming from other parts of serialization.
  • … Then we decided that records aren’t extensible, so I can’t combine two records to make a big record!
• JWL: I guess you could say in the spec, that “this record” is the combination of “these other two records”.
  • … But you can’t programmatically do it.
• CG: In BaseX, we allow option parameters to be a map.
• JLO: This is an interesting addition; we have the same problems as JSON so maybe we’ll have more need to have the options structured by data format.

Proposal: merge this PR?

Accepted.

See PR #2795.

• CG: We have general nodes, GNodes, that came into life because of JNodes, but that may not be clear to many users.
  • … The idea was to drop this term again and rename existing nodes() to xnodes() and to have node() mean either.
• CG: I haven’t dropped the use of GNodes in the spec; that still makes sense. It’s not really possible to use GNode for the GNode type in all cases.
  • … But the user won’t notice this anymore.
• CG: But maybe we should see what MK thinks explicitly.
• JWL: It’s backwards compatible with existing code and such. But will there be a sense that people have to change node() to xnode() in all their XPath expressions?
  • The spec has changed in this regard. Now that you’ve got the possibility of JNodes, do I have to go through and change it all?
• CG: I think it won’t be so much of a problem. It’s backward compatible. Most of the functionality works with both kinds of nodes.
  • … This will reduce the number of places where error messages, for example, contain xnode() which can be confusing.
• AP: Is it interesting to try to do some exercises to look for backwards incompatibility?
  • … I think it’s been helpful to know that “node” still means “XML node” and I need to say “gnode” if I want both kinds.
  • … Is there a more general problem that we’re reversing the original position?
• CG: There are some remarks that try to point out the differences. Perhaps I should highlight those changes.
• AP: Maybe we just need to be very closely.
• WP: I think a close review is in order. I think this is actually a good idea, even a silver lining. This brings the JSON people into parity, you don’t need to rearrange the names.
  • … The concerns that have been raised can be addressed. We can gloss over the meaning of “GNode” in the prose. These are all features as much as they are problems.
• JLO: I find this change bold but also necessary.
  • … Anything is a node for me, the term “gnode” doesn’t roll off the tongue.

Let’s come back to this in a week.

See PR #2812.

• CG: The change is minor. It replaces a “+” with a “ ”.
  • … The use of “+” is a HTML form rule, not a URI rule.
• CG: There’s also an example in parse-uri where the conversion is incorrect.

Proposal: merge this PR?

Accepted.