QT4 CG Meeting 100 Minutes 2024-11-26

DB, JLO give regrets.

• [ ] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [ ] Sasha Firsov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:05-]
• [X] Michael Kay (MK)
• [ ] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Dimitre Novatchev (DN)
• [ ] Wendell Piez (WP)
• [X] Ed Porter (EP)
• [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 3 December.

CG gives regrets.

The CG does not plan to meet on 24 or 31 December.

(Items marked [X] are believed to have been closed via email before this agenda was posted.)

• [ ] QT4CG-080-07: NW to update the build instructions in the README
• [ ] QT4CG-082-02: DN to work with MK to come to agreement on the fn:ranks proposal
• [ ] QT4CG-088-01: NW to consider how best to add a dedication to MSM.
• [ ] QT4CG-088-04: [Someone] needs to update the processing model diagram needs vis-a-vis the static typing feature
• [ ] QT4CG-089-01: CG to draft a PR that attempts to resolve the operators described in #755 to a smaller number of orthogonal choices.
• [ ] QT4CG-097-02: MK to make the XSD schema component references into links to XSD
• [ ] QT4CG-097-03: DN to proposal an axis for accessing the siblings of a node.
• [ ] QT4CG-098-02: NW to look at the XSL stylesheet for XSD, #374.
• [X] QT4CG-099-01: MK to add a default layout option for elements-to-map.
  • MK looked and decided that it doesn’t work. Came up with a different idea to disable some options.

See PR #1570.

MK introduces the PR.

• MK: After discussion, decided to add type-of() which does more than node-kind().
  • … MK reviews the prose of the PR …
  • … We walk up the type hierarchy to the first non-anonymous type
• JWL: Isn’t a sequence of strings better than a union? You might have to re-tokenize.
• MK: Maybe.
• NW: What about a case when there’s a different binding for xs:?
• MK: I don’t have a very clear picture of what the use cases are for this function.
  • … My use cases are diagnostic, so it’s just for human readability.
• CG: I like it, simple strings are what users want, I think. If you want to do more sophisticated things, write your own function.
• RD: In terms of possible uses: within my XQuery plugin, I’m doing a similar sort of logic when determing the types of a value in things like query result output, profiling, debugging, etc.

Proposal: Accept this PR.

Accepted.

See PR #1604

MK introduces the PR: this is a bit of syntactic sugar designed to encourage people to say when a well-formed document node is expected.’

• MK: We allow NameTestUnion in a DocumentTest
  • … Have clarified the text with respect to document-node(E).
  • … document(NTU) is a shorthand for document(element(NTU)).
  • … So document(*) is a well-formed XML document.
• MK: It’s expanded in the subtyping rules.
• NW: What about whitespace text nodes?
• MK: The standard rules for generating an infoset when parsing won’t give you any whitespace there.
  • … You could programmatically construct them that way; the spec was a little bit ambiguous.
  • … I sort of looked for all the evidence I could find and decided that the intention was that they aren’t allowed.
• MK: I’ve used the new syntax in Functions and Operators.

Proposal: Accept this PR.

Accepted.

See PR #1603

• MK: This is purely editorial; I found some text that was a mess.
  • … Both maps and arrays have a section called “other operations”. I’ve updated them both.
  • … For maps it’s a summary of things you can do with maps other than apply functions to them.
  • … For arrays, we had two almost identical sections with odd headings.
  • … Rewrote the section to say something useful.

Proposal: Accept this PR.

Accepted.

See PR #1599

• CG: This is pretty small. We’ve talked about it several times.
  • … I’d like to change the type of the $err:stack-trace from function to string so that it’s easier to serialize.
  • … The CG should be able to provide a lazy string if it takes too much time to materialize.
• MK: I think you’re probably right.
• RD: What effect would this have on compatibility. If someone wanted to call this across different implementations. Wouldn’t they have to do implementation-specific things for the stack trace.
• CG: The stack tracke string is entirely implementation defined.

Some discussion of the return type.

• MK: I think we should prescribe a string or nothing. If you want to parse it, you’ll have to know what product you’re dealing with.

Proposal: Accept this PR.

Accepted.

See PR #1505

• MK: I think we can accept this contingent on making the equivalent change.
  • … MK walks through the prose of the PR; it brings XSLT in line with the XPath changes.

Proposal: Accept this PR.

Accepted.

MK to make the corresponding change to $err:stack-trace and then merge the PR.

See PR #1586

• MK: This is also primarily editorial. I also picked up the change to add a named record type for key-value pairs. It was a separate issue but in the same general area.

MK reviews how the material is presented.

This PR involves stylesheet changes so it’s not usefully presented in the formatted PR. We’re looking at a local build on MK’s machine.

• MK: The map:pairs() function now has a link to the key-value-pair record type in a free-standing section.
  • … There’s a bit of a consistency issue regarding which are extensible and which aren’t.
  • … Generally on input we want to accept additional properties and ignore them.
• MK: There are about 5 record types now.
  • … I’ve anticipated putting them in the fn: namespace and adding them to the static context.
• RD: Do we have the declare item type syntax standardized?
• MK: Declare record is standardized in XQuery
• RD: Should we also have a signature for those?
• MK: If we put them as implicitly declared records, you also get a constructor function for them. So fn:key-value-pair duplicates the map:pair function.
• RD: Should we make the record type with that implicit constructor?
• MK: I think it’s logical to have the record and the constructor function having the same name.
• RD: What I mean is replace map:pair with the map-pair record type.
• MK: Yes, I think that’s where this leads.
• CG: Could it just be pair? Do we have other pairs?
• MK: That’s an open question. Currently, we use the name pair qualified by map:. If we called the record type map-pair, I think we’d have enough context for it.
• JWL: I’m in favor of using key-value-pair, not just pair or map-pair.

Proposal: Accept this PR.

Accepted.

See PR #1587

• MK: This is a bit related to what we do about the EXPath file and binary modules.
  • … This allows us to read a binary resource.
  • … (The PR also tidies up a lot of things about base URIs in the static and dynamic contexts.)
• MK: There’s a big question about what we call this function.
  • MK: … The function is completely straightforward.
  • MK: … Wait, the paragraph about mapping to URIs is wrong.
• MK: There needs to be a parallel change about binary resources. Unfinished business.
• JWL: The result type doesn’t have an option on it, but the rules say it could be.
  • … Are we going to try to get an output method to output a binary resource?
• MK: That gets to the thorny question of functions with side effects.
• JWL: No, I mean as part of the serialization.
• NW: I think JWL is only proposing that we need a binary output method.
• CG: The function is marked as deterministic, does that mean it always needs to return the same result?
• MK: Yes, I think I decided to be consistent with the other resource functions.
  • … I’m not happy about that, but this didn’t seem to be the right place to change it.
• CG: All the functions in the file module are all non-deterministic, so you can decide which ones to use.
• DN: In the summary of the function it says it returns binary, but it should say that it returns xs:base64Binary to avoid confusion.
  • … To me, “resource” means a URL or a URI, not the content. I’d prefer to have a more exact name like: binary-resource-content.
• NW: I suppose we could go with binary-doc for parallelism?
• MK: Maybe, but we tend to think of doc as XML documents.
• DN: Is it meaningful to ask what kind of format it is, in the case when it’s an executable?
• MK: It’s a question as to whether this relates in any way to HTTP content types.
• DN: Maybe we could have some way of getting more information about the type of the resource.
• JWL: The example we use the EXPath binary specification is things like images.
  • … There’s typically a MIME type, but you can also sniff.
• MK: From the magic bytes at the start.
• RD: I think it would be more useful to have MIME type detection as a separate function.
• NW: MIME type detection is just a mapping to filename extensions these days, so less useful.
• DN: Binary can be a little bit risky. It has security implications maybe? Maybe there should be some warning for this. And should there be an additional parameter for virus checking?
  • … Maybe in some applications we would not want the function to be deterministic.
• MK: I think that’s a valid point, but determinism is completely orthogonal to the question of what the resource type is.
  • … I think the security implications are orthogonal as well. JavaScript is text and it can do anything it likes.
• JK: I wonder if there are any thoughts about what to do about the file library.
• MK: The specification depends totally on assumptions about order of execution that ends up being thoroughly unsatisfactory from a specification point of view, but livable from a product perspective.