QT4 CG Meeting 052 Minutes 2023-10-31

Regrets from DN. MSM may have to leave early.

• [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)
• [ ] 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.

The next meeting is scheduled for Tuesday, 7 November 2023.

No regrets heard.

• [X] QT4CG-046-01: MK to continue the work on #129 for the other specs (we accepted #703)
• [X] QT4CG-050-02: MP to attempt to summarize this discussion and identify specific issues
• [X] QT4CG-051-01: NW to attempt to craft a new issue for the remaining items in #129
  • Overtaken by events
• [X] QT4CG-051-02: NW to attempt to draft a proposal for fn:invisible-xml
• [X] QT4CG-051-03: MK to check that in our view schema components don’t indirectly reference the schema root
• [X] QT4CG-051-04: DN to make the point that in simple, static cases, the arrow operators may be better.
• [X] QT4CG-051-05: DN to correct the typo in item 3 “could be sequence” => “could
• [X] QT4CG-051-06: MK to help DN with the markup in fn:chain examples.

See issue #689.

• CG: The way this function is specified now, it’s very implementation specific.
  • … I think only Saxon woulud be able to do what’s described in the specification.
  • … For BaseX, we lose a lot of information because of function inlining.
• RD: MarkLogic does have an XML-based stack trace, I’ve generally found an XML-based trace more useful than a string based one.
  • … You can do additional processing with the XML
• MK: I doubt we’ll be able to define interoperable output for stack trace.
  • The main idea was to have an interoperable way of invoking it.
• RD: The main thing to get is the inner-most point where the exception was raised. Other bits of context are useful, but can be more flexible.
• SF: Are you proposing to create a schema for the stack trace, to be extended by vendors?
• RD: That could be useful. MarkLogic includes additional variables and things, but having a common base of file number, line number, module path, … would be good.
• WP: I think this is more a question of where to draw a line about conformity of implementations. A strict schema for the output could be very hard to get. The results are likely to be very processor-specific. It should allow maximum freedom in what’s delivered. We could use iXML to go from text back to XML.
• JL: I can’t see any point in going out to text and then going back to structure. The processor has the best context. Are you trying to debug the processor or the program? Most of the folks debugging a processor are probably in this room. There are a lot more users trying to debug their programs. Optimization makes the stack traces just really hard to get. Who is this for?
• RD: To answer the processor or the program, it’s mostly the program. What you often have is a large, complicated application that you’re making calls to. Somewhere deep in that application something goes wrong. When you get it back from your application, “empty sequence can’t be cast as a int”, you have no idea what happened. Any kind of stack trace is probably useful.
• MSM: I find it helpful to have a way to ask “what’s happening” in my queries. I find the standard fn:trace() function useful and by analogy, I think a common way to do stack traces would be useful.
  • … Since a trace message is always directed to me, a human, and not software, I don’t need standarization across processors. Regularity is less important.
• SF: The primary consumer for stack traces is not humans, it’s IDEs. In that context, there are standards. Having a special case for us in XML could work for us. But it would have to be integrated into IDEs. Do we want it to be a standard, or let vendors do it? I think it’s better to make it part of the standard.
• CG: I think we all agree that it’s useful to have a look at the stack trace. Would it also make it part of exceptions, because many languages let you look at the stack trace in an exception.
  • … Because the languages provide so much freedom for optimization, I wonder if the output will be useful. If we implemented stack tracing, then we’d want to suppress some optimizations. That would mean adding the stack trace function would very likely hide the error! I’m not sure we’d meet user expectations.
• RD: One of the use cases is in things like logging exceptions from REST APIs. Where if you just get a message, you don’t have any context. Being able to get the stack trace, even if it isn’t 100% perfect, will help in understanding where the error is. You can provide information for the IDEs as well.

Straw poll: Given the discussion we’ve heard, do you think it’s worth pursuing a standard stack-trace function, or should we leave it to processor extensions? In favor: 4. Opposed: 2.

• MK: I think the bias should always be towards not doing something.

The chair is reluctant to call that consensus in either direction. Cowardly decides to simply leave the issue open for now, but not plan to discuss it again anytime soon.

See issue #130.

• CG: The idea was we have xs:numeric for all kinds of numbers, I get repeated questions about why there’s no xs:binary function. Today we could use a union. From a user perspective, it would be very nice.
• NW: MK, you proposed an alternative.
• MK: We could make them mutually promotable. That achieves much of the same objective and seems to be more consistent with how we’ve addressed similar issues.
• JL: The only difference between the two binary formats is how they’re parsed and “serialized”. I’m tempted to agree with MK.
• MSM: Point of information: if we made it a union type, would either order work?

Some discussion of whether or not the two types are disjoint. Conclusion: there is some overlap.

• MSM: Could you ever get the wrong answer if it was a union type?

Consensus (the scribe believes) was “yes”.

• RD: The issue is what happens if you do xs:binary on an ambiguous string.
• MSM: What do you get if you cast a numeric to a string?
• MK: I don’t recall, but there is an order.

ACTION QT4CG-052-01: MK to propose text for mutual promotion between xs:hexbinary and xs:base64Binary

See PR #772

RD suggests delaying this until after comments on the PR have been addressed.

See PR #770

NW reviews the PR.

Proposal: Merge this PR and continue to work on the tests.

Agreed.

• WP: There’s no verb in item 37.
• NW: Thank you.

See PR #753

MK reviews the PR.

• MK: This is an opportunity to fix an XQuery issue.
  • … Adding the keyword fixed. A fixed default namespace in your element declarations don’t effect the default namespace for elements and typed.
  • … The other part is that you do want the default namespace declaration to effect nested element constructors.
• MK: In element constructors, we change what happens when you say xmlns= something.

MK summarizes the new rules…

Proposal: merge this PR?

Accepted.

CG summarizes the issue.

• MK: The semantics are very, very close to xsl:message
• MK: I’d want to have a single API that captures the message
• JK: It would be nice if we could reconcile the two mechanisms and have message for both.
  • … Can the output of xsl:message be promoted to item or sequence in XSLT and try to merge them
• MK: For simplicity, we should be producing a string here.

NW suggests that we’re drifting towards fn:message.

• SF: How does log-level (error, warning, etc.) fit in?

General consensus that we don’t have log levels, and that may be a good reason not to use fn:log.

• WP: Is the real blocker here that the semantics wrt XSLT?
• MK: Is it close enough to get benefit from name recognition or far enough away that it generates confusion.

Proposal: we call it fn:message instead of fn:log?

Accepted.

• SF: What about actual level-based long functionality?

Agreement that that is a separate issue.