QT4 CG Meeting 080 Minutes 2024-06-04

• MK: The devil is in the details and there are a lot of details
  • … Including in the grammar
• JLO: I’d like to have this

Some discussion of whether this is mostly about maps.

• MK: I’m unsure about doing this for arrays
  • … It just saves a few keystrokes

Some discussion of how it would work with maps.

• MK: This capability is for the use case where the keys are known at compile time.
• JLO: We could limit it to record destructuring?
• MK: Yes, but that’s not really a datatype
  • … You could restrict it to just keys that are NCNames or QNames…but which is it?

“Hard”/”Optional”

• MK: I’m torn about whether this is desirable or not

“Easy”/”Optional”

• MK: I think this is a bit out of date.
  • … Generally, I think there’s a need to reflect some of the changes we’ve made to the standard function library to make corresponding changes for the XSLT defined functions.

There’s no conceptual difficulty, it’s just legwork.

“Optional”/”Easy”

We wish RD was here to explain HTML templates.

• JLO: The content of the template element isn’t visible in the DOM. It’s used for instantiating something

Some attempt to understand the meaning of a template element.

• JLO: It’s used when creating new instances.
• MK: If this is an HTML feature, users will want to be able to create them through the HTML serialization method.
  • … If the parse-html function does something special, does it round-trip?

“Revisit”

• MK: It’s fairly easy if you just wave your hands about the implementation
  • … My anxiety is that someone is going to use it for timing things, then it gets tied in with things like lazy evaluation.
• NW: Or have some functions that you aren’t allowed to lazily evaluate?
• MK: The xsl:message instruction is like that, it just leaves it to implementations to do what makes sense
  • … But at the XPath level, it’s a lot more complicated
• MK: You could do it in pure code by having a monitor function (scribe: as shown in the comment in the issue)
  • … No, that won’t work! It would evaluate the function before it started!
• MK: The other way to do it is just with a system date-time function with a note to implementors that it’s useful to evaluate this eagerly.

PR pending.

• MK: I don’t think I want to do this. I prefer the spec as written.
  • Extension elements generally have boolean attributes, string attributes (usually AVTs), or expressions (typically @select).

“Revisit”

• MK: This is a hybrid of sorts between maps and functions.
  • … I think this is too difficult.

“Hard”/”Optional”

One angle here is dynamic function calls taking keyword arguments that’s popped up in several places.

After half an hour spent reviewing the proposal, the chair proposed we mark it hard and optional.

”Hard”/“Optional”

”Hard”/“Optional”

Close with no action.

• JLO: The biggest problem seems to be “what is the type of a value”? Is it integer or decimal?
• MK: The type system is such a mess
  • But atomic values clearly have a type label. A function can return that.
    • There’s one complication, what to do if it is an anonymous type.
      • (If you evaluate against a schema with an anonymous type.)
      • One solution would be the nearest type up the hierarchy that has a name
  • Nodes have a well defined kind. There’s also a “content annotation”, an element validated against a type might be a “part number”, for example.
    • We could define a function that returned “element and part number”

Some discussion of nodes. You might also want to get the element name.

• MK: Not many people write schema-aware XSLT or XQuery code.
  • It’s just a pain to start with.

Returning to the discussion.

• MK: The real problem is what to do with functions, and arrays, and maps. They don’t have an intrisic type. An empty map belongs to an infinite number of types.
• JLO: But an empty map is “map(*)”!
• MK: For all maps, arrays, and functions, you could say all you get back is that it’s one of those.
• JLO: That would be good, but you could also look into the map or array.
  • Both BaseX and in my own hack of that function, do introspection.
• MK: I’ve no problem that it’s useful. It was defined by EXSLT for 1.0 very quickly.
  • … There’s plenty of evidence that it’s needed, it’s just the detail.
• MK: The other question is what kind of result do you return?
  • Type, in principle, should be first class objects, but that’s a big step in terms of the data model.
• JLO: All of the existing versions get you strings. But it could be an enum.
• MK: I think you want it to be a structured result.
• NW: A record with an optional qname type and an option node kind?
• MK: Yes, I think that would be more useful than a string you have to parse.

If we limit the scope to just saying map, array, or function does that make it easy?

“Hard”/”Optional”

PR pending.

There are a bundle of things in this area that we keep coming back to by other routes.

• MK: We’ve done some of this in the function coercion rules.

“Revisit”

• MK: I think we’ve made this part of the status quo, but we don’t want to lose Jirka’s proposal for an extension.

We’ve asked Jirka to open a new issue for his extension.

Close this issue without further action.

• MK: Back in the age of 4GLs this was called a stereotype. There’s a general feature but it’s too complex for this use case. How do you define the boundaries?
  • … One of the motivations for this is that copy-namespaces="no" doesn’t do what users expect.
  • … There are all sorts of degrees of elaboration possible.
• JLO: If I wanted tei:p output as html:p what would I do?
• MK: You’d have to write a mode with a single template rule that matches all elements and changes the namespace.
• NW: It’s certainly optional, do we want to keep it?
• MK: Let’s abandon it.

• NW: It looks like defining the behavior is the tricky part.
• MK: Nothing to do with URIs is easy!

ACTION: QT4CG-080-01: NW to add what the DocBook stylesheets do for this function

“Optional”/”Easy”

• MK: There are a number of issues with packages introduced in 3.0.
  • … There are only a few people using them in anger, but they’re the one’s finding issues.
  • … It would be nice to have more feedback.
  • … Certainly one issue is that packages can take parameters (particularly static parameters). If you write a package that has a parameter that’s the localization attributes and you then want to versions of that package in a stylesheet with different localization attributes, there’s no way to do that.

“Required”/”Hard”

There are a group of issues related to transiency

“Revisit”

(We’ve come back to this issue on the afternoon of the second day).

• JLO: CG has a point about collection and doc being different.
• MK: Yes, except pragmatically, in our experience, people read the same document many times but rarely read the same collection more than once.
  • … But maybe that’s not the case in other environments
  • … CG says he imagines doing collections over database and filestores differently.

Is it a database or filestore is one dimension. What’s the duration of an execution scope is another. If an execution scope is republishing a suite of documents, then you really don’t want be holding onto the whole collection.

• MK: A common use case is to process the documents in the collection one at a time. It’s such horrible overhead to hold all of the documents just in case you come back to that collection again.
• NW: It sounds like we might get consensus to relax the requirement.

This is related to the question of transiency because a transient block or something like that would give the user the appearance of control.

Some discussion of how database and filesystem access differs.

• MK: The issue quotes the existing text. The transient proposal doesn’t change that. The transient proposal gives the user an interoperable way of switching that off but it doesn’t change the default.
  • … For our user base, I think the default is wrong.
• JLO: So what we want is an interoperable way to specify that.
• EP: Would it be reasonable to change the default for XPath and not XQuery?
• MK: We could say that the implementation must provide an option for it to be deterministic but that doesn’t have to be the default.

Some discussion of the use of an options parameter. That’s not necessarily something you can know statically, but certainly the 99% case is that it will be a literal!

ACTION: QT4CG-080-02: NW to fix issue classification so PR #1181 isn’t misclassified as an XSLT issue

Some discussion of PR #1181 which addresses this issue.

PR pending

• MK: The whole implicit context dependencies of some functions is very worrying. The fact that strip-space and preserve-space apply globally is very unsatisfactory.

Some discussion

• MK: These need to be options parameters on the functions (parse-xml, doc, etc.)

“Required”/”Hard”

• NW: Looks useful to me.

“Optional”/”Easy”

Some discussion of the fact that xsl:sequence isn’t intuitive but xsl:value-of returns a text node.

MK’s response in this issue is a separable issue. It’s a tangent.

ACTION: QT4CG-080-03: MK to make a separate issue for @as on xsl:value-of

With respect to @select on xsl:text, it’s hard to argue against.

“Optional”/”Easy”/

This seems to have garnered some support.

“Optional”/”Easy”/

We’ve done some of this in other ways, or in other open PRs. Needs to be revised in light of the current language.

“Optional”/”Hard”

• MK: One school of thought says that locating packages should be outside the core language. You should be able to configure where they come from without changing your source code. OTOH, we know from Query and Schema that it’s much more convenient to say where they come from inline.

“Optional”/”Easy”

Build issue. Let NW fix it.

Duplicate of 296, close with no further action.

• MK: I think the proposal is to break the way it’s currently defined.
  • … In the cases where it’s changing it, the existing behavior is almost certainly not what the user intended.

“Optional”/”Easy”

Some consideration of what it means in stylesheets with other versions. Might we just consider it a bug fix?

• MK: We have a catch-all issue that streamability of 4.0 hasn’t been addressed.

“Required”/”Easy”

Build issue.

• MK: In the 3.x builds, we had a role for examples that caused them to be syntactically validated.

• MK: We allow modules to use different schemas if they’re compatible
  • … And the spec is clearer about error conditions
  • … We don’t have the ability to import incompatible schemas and validate against them separately.

“Optional”/”Hard”

MK observes that part of this is now possible, you can have incompatible schemas in use provided you don’t refer to them from your query.

Like #305, this is about options on parse-xml, doc, etc.

“Required”/”Hard”

• MK: Not too difficult now that we have error maps.

“Required”/”Hard”

• MK: Override with visibility hidden seems to be the same as accept with visibility hidden.
  • … Perhaps this is “existing callers, use this version, but I don’t want to call it from my package.”
  • Java doesn’t give you private overrides, do we really need this?
• MK: I can see the need for accept with alias, but is that really needed often enough to justify?
• JLO: That seems sensible enough to me, it’s “import as”.

“Optional”/”Hard”

PR pending, but the PR is out of date and there are open actions to change it.

This seems to have garnered some support.

“Optional”/”Easy”

Superseded by #1127, close without further action

• MK: Might involve a data model change, that’s always difficult.

“Optional”/”Hard”

PR pending

• MK: I wanted to do it for two reasons: it’s useful to be able to use functions, and also to make it possible in XPath rather than only XSLT and XQuery.
  • … CG asks why not move the XQuery syntax into XPath
  • … I don’t like that partly because it only solves one of the problems, not the other
  • … From an XSLT perspective, wanting to keep the XPath grammar small
• NW: I predict it will be difficult to get consensus

Some discussion of whether it should be an extension; but users don’t tend to use extensions if there’s another way.

“Revisit”

• NW: It does seem bad that serialization and items-to-json behave differently.

Some discussion of the streamability consequences of serializing a sequence as an array.

• MK: We’re revisiting items-to-json anyway.

“Revisit”

• MK: My last comment is to scrap the functions and go with the update syntax

“Revisit” after the PR on update syntax.

Related to #576, marked revisit.

“Revisit”.

(We’ve come back to this issue on the afternoon of the second day).

• MK: A common error is that you can’t use a map in document content. The proposal is that instead of telling you that, it gives you a document that contains a representation of that map.
• NW: What about the streaming problem?
• MK: We could have an extra serialization parameter “serialize sequence as array”.
• NW: And what’s the default?

Some discussion of streaming. This isn’t specifically about XSLT streaming, it’s about the fact that serializers often work “on the fly”.

• MK: A JSON serializer would have to look ahead to find out if the top-level item was a sequence. So it’d have to buffer the whole thing.

With respect to serializing +Inf, -Inf, NaN, using null per the standards is probably the right thing to do.

• MK: The whole point here is to avoid conflicts with system functions. You don’t want a query to fail just because we added a new function to the static context.

“Optional”/”Hard”

Consensus: we need an actual PR for fold-lazy.

“Optional”/”Hard”

“Required”/”Hard”

Consensus: provide the stack trace on error, but not as a function.

“Required”/”Easy”

See #716

“Optional”/”Hard”

• MK: I think I proposed this for neatness.

“Optional”/”Easy”

See #708

“Optional”/”Hard”

“Required”/”Easy”

• MK: My preferred is named local functions.
  • … Putting all the functions first avoids hoisting and other problems.

See #745

“Optional”/”Hard”

See #735.

Close with no action.

“Required”/”Easy”

“Required”/”Hard”

What’s the proposal?

• MK: I think we determined that the case should be preserved.

“Required”/”Easy”

Addressed by recent changes.

Superseded by #1238

• MK: Some of the comments here are superseded by more recent work.
• MK: We could get rid of array:members and array:split as user-visible functions.

“Required”/”Hard”

• MK: The names are local to the spec, they don’t have any effect on queries.
  • … So it is purely editorial.

“Optional”/”Easy”

PR pending.

PR Pending (#832)

• JLO: It’s now or never.

“Required”/”Easy”

“Optional”/”Easy”

• MK: In some ways, this is like the discussion we had about transitive closure. We decided there that what most people would want and need is something that applies the transitive closure.
  • … What DN has pointed out here is that fn:chain is similar.
  • … I think I probably want the composition function more often.

“Optional”/”Easy”

• MK: To do random numbers properly, we decided we need to have something more complicated.
  • … The same arguments apply to UUID.
  • … One thing that occurs to me is to add UUID as a subfunction of random number generator.

Some discussion of which flavors of random UUID require access to the time, and if that could compromise the output of the random number generator.

• NW: MK is right that we’d need fn:uuid-generator …

“Optional”/”Hard”

“Optional”/”Hard”

“Optional”/”Hard”

PR pending

“Optional”/”Easy”

Close without further action

Close without further action

“Optional”/”Easy”

“Required”/”Easy”

“Optional”/”Easy”

• MK: We have to do this, we can’t leave one function that’s different from all the others.

“Required”/”Easy”

This is roughly a duplicate of #967.

“Required”/”Easy”

ACTION: QT4CG-080-04: NW to revise p:invisible-xml

“Optional”/”Hard”

“Optional”/”Hard”

“Required”/”Hard”

PR pending

• MK: Under CG’s proposal, an untyped atomic is problematic. If you say, if the first thing in the sequence is a number, then everything else is coerced to a number, you get some quite strange results.

“Required”/”Easy”

Related to other issues about having options arguments for these functions.

“Required”/”Hard”

“Optional”/”Hard”

“Optional”/”Hard”

“Required”/”Hard”

PR pending

We just don’t think this is something we are prepared to do.

• MK: The fn:format-number function has always been context independent.

“Optional”/”Hard”

Useful functionality. But will it be hard to implement efficiently?

“Optional”/”Hard”

“Optional”/”Hard”

“Required”/”Easy”/

“Revisit”, CG isn’t present.

“Optional”/”Hard”

“Revisit”, CG isn’t present.

Some discussion of the issue; making the XPath prolog a separable part of the language might be useful.

Close without action.

Editorial. Not discussed at the f2f.

“Required”/”Easy”

(Doing the easy parts is easy!)

Part of the nexus of issues about arguments to dynamic functions.

“Revisit”

“Optional”/”Easy”

“Required”/”Easy”

“Optional”/”Easy”

“Required”/”Easy”

“Required”/”Hard”

“Revisit”

“Optional”/”Easy”

ACTION: QT4CG-080-05: NW to add absolute property to the parse-uri output

See issue #1169 and PR #1185.

“Revise”

“Revise”

• MK: We have half-to-even but we don’t have the other modes.
  • You can usually wangle it by negating, rounding, etc. But it’s a kludge.
• NW: This is preventing real users from getting the results they need.

“Required”/”Easy”

• MK: I think the last time we looked at this in 3.x, we agreed that most functions have a “principle argument”, the first argument, and it makes sense to allow that and return an empty sequence.
  • … There are other conflicting positions, for example that empty sequences to string functions give the empty string.

PR pending

“Optional”/”Hard”

“Required”/”Easy”

PR pending

• MK: I think I’m persuaded.

“Optional”/”Easy”

• JLO: There’s an extension to XQuery Update in eXist DB that looks like the new map and array syntax.
• MK: It’s obviously desirable, but the prospect of taking on XQuery Update is daunting.
  • … Partly because of issues of consensus on the 3.x specifications.
  • … You could decide that it was a false start and go back to the 1.0 spec.

“Optional”/”Hard”

“Optional”/”Easy”

• MK: This has always been a pretty sore area. If you call a function that calls a function that calls a function that calls generate-id, are you allowed to pull that function out of a loop?
  • … It’s hard to maintain function identity in all case.

“Required”/”Hard”

“Optional”/”Easy”

“Required”/”Easy”

• MK: It needs working through. I hit it with arrays, where I wanted to sort the array and then carry on.

“Optional”/”Hard”

• NW: Does the presence of this ugly gotcha raise this to the level of required?
• MK: I think so.

“Required”/”Hard”

“Required”/”Easy”

“Required”/”Easy”

“Required”/”Easy”

“Optional”/”Easy”

PR prending

• MK: That’s not the only possible interpretation, but it seems a reasonable default.

“Optional”/”Easy”

Merged without discussion.

Merged without discussion.

Agreed.

• MK: There are some sections that have been moved around so that we can align the grammar between XPath and XQuery.
• MK: We’re a bit looser these days about what it means to compare two QNames, we used to spell it out very precisely everywhere.

Wait until NW and CG agree that the prose and the tests are consistent and correct.

Blocked. (The build failed.)

• MK: We have a responsibility because it will seen as an endorsement.

Wait for WP to provide more background information.

• MK: Having two different collations seems impractical. Either that’s unnecessary or I don’t understand what the function is for.
• NW: I took that to mean just what it appears to say, that you have a collation for the keys and a different collation for the items.
• JLO: I thought we said that the collations could be made part of the functions.

Some discussion of how the use case (the football scores) could be done today.

• MK: My mental model is you sort by the key and the partition. It’s a variant of sort that delivers a partitioned result.
  • … So why on earth do you need two collations?
• JLO: Could this be done with fn:sort and fn:partition?
• MK: Yes, but you might have to evaluate the sort key twice.

Some discussion of whether that could be avoided by passing in tuples.

Some discussion about whether or not the Swedish collation in the language example is doing anything.

Finding anagrams doesn’t appear to require fn:ranks, you could just group on the constructed character/frequency string.

We look briefly at MK’s formulation.

• MK: It’s basically sort followed by partition.
• EP: The only difference is that you don’t have two collations?
• MK: I’m not sure because I haven’t tried to address the boolean parameter about duplicates.

Some discussion of dealing with duplicates. For simple cases, you could remove them from the input. Where that wasn’t possible, you’d have to post-process.

• MK: What is missing from this formulation that is in DN’s presentation?
• JLO: The ability to make distinct values.
• MK: Then maybe that should be added to sort?
  • … Why should the way fn:ranks behave differently than fn:sort with respect to duplicates?

Unclear how to proceed.

MK made the requested change. Needs to be reviewed again.

• MK: Are we sure this isn’t recursive? That ?* isn’t defined in terms of map:get()?

No, that’s not the case. (We checked.)

• MK: Okay, the design works. But do we like it? It means there’s one function that does two very different things.
• NW: I’m not a huge fan, I think it hinders discoverability. I go looking for functions to get the keys and values out of a map, I’ll find map:keys but not map:values. So I have to write that myself? It might be a while before I thought of having map:get(()) do it.
• JLO: If I’m using an expression for the argument to map:get and I accidentally use an empty sequence, I’m going to get wildly different results.
  • … Why is values so bad?
• MK: In many ways I prefer the status quo.

We don’t seem to have consensus for this change.

• JLO: Why ##any?
• MK: Following the convention for XSD, using a string with ## in it shouldn’t be used as a namespace.

In the XSLT spec:

• MK: We’ve reverted the change that made element and type namespaces different. There’s a change here that corrects an error where we failed to do that.

See discussion of fn:ranks above.

Accepted.

It appears that there might be a rebasing problem.

(MK rebased and pushed.)

• NW: Looks fine to me.

Some discussion of the (dis)similarity of JSON parsing mandated by the fact that unparsed-text must reject non-XML characters.

• JLO: Is there an HTML version of html-doc?
• MK: No.

Agreement that it should be raised, JLO will do so.

ACTION: QT4CG-080-06: NW to investigate the cross-spec reference errors in the build

ACTION: QT4CG-080-07: NW to update the build instructions in the README

Accepted.

Accepted.

ACTION: QT4CG-080-08: MK to work out what happened to his next-match PR

• NW: In this note:

  These rules affect the way an xs:untypedAtomic key value is handled. Given the shallow lookup expression $A?$x, if $A is an array and $x (after atomization) is xs:untypedAtomic then the value of $x is converted to an integer (by virtue of the coercion rules applying to a call on array:get). With a deep lookup expression $A??$x, by contrast, the semantics are defined in terms of a map lookup, in which xs:untypedAtomic values are always treated as strings.

  Is the reference to array:get correct? (Is the note correct overall?)

• NW: fn:selection:path should be fn:selection-path
• MK: Allowing a sequence in UpdateExpr causes a grammar ambiguity
• JLO: ExtendClause is missing from the definition of UpdateClause

Some discussion of the ambiguity. For a single clause leave out the curly braces:

  update map $data …

For multiple clauses use the curly braces but precede by do.

• MK: Needs another pass, but we’re getting there.
  • … What I quite like about it is that most users won’t need to worry about most complexities. The syntax is reasonably intuitive. Users will be able to use the expressions without a deep understanding of the semantics.

ACTION: QT4CG-080-09: MK to address comments made on PR #832

Needs revision, come back to later.

• 158, Support optional parameters on dynamic functions
• 1136, Defining names for parameters on typed function tests
• 1175, XPath: Optional parameters in the definition of an inline function

MK observes that the primary obstacle is argument names.

• MK: If you declare a function with keyword arguments x, y, z, and you pass it to a another function as an argument where the expected names are p, q, and r, what happens?
  • … There have been lots of suggestions that we’d like the names of the parameters to be a lot more visible. Perhaps starting in the function type.
  • … The purpose is for the caller of the function to call arguments by name.
  • … Where does that come from? If it’s in the author’s declaration then you can’t pass x, y, z if p, q, and r, are expected.
  • … I don’t want to constrain the caller of the function to use the same name as the recipient.
  • … If function coercion changes the names, how does that work.

Some discussion of what’s different here. It’s about dynamic evaluation, not whether or not the function was declare statically.

(Note to readers: the code examples were constructed on the fly while being projected. It’s likely that intermediate stages have been lost.)

declare local:add($v1, $v2, $rounding-mode:="normal") {…}
declare local:sub($a, $b) {…}

add(v2:=3, v1:=1)
add(1,3)

let $partial := local:add(1, ?)
$partial(v2=3) (: error :)

declare local:higher-order($op, $f as function(xs:double, xs:double)) {
  $f(2, 3) (: ok :)
  $f(v1=2, v2=3)  (: wat? :)
}

local:higher-order(3, local:add#2)
local:higher-order(3, local:sub#2)

declare local:higher-order($op, $f as function($x as xs:double, $y as xs:double)) {
(:  $f(2, 3) (: ok :)
  $f(x=2, y=3)  (: ok :)

  let $g := $f(y=?, x=3)
:)
  $op => $f(x=2)
}

add(v2=7, v1=14)

• MK: Keyword arguments allow you to change the argument order in dynamic function calls.
  • … Optional parameters can only be called with keywords, and keyword parameters must be optional. They are always implicitly passed through by names.
  • … If you declare a function with an optional, keyword based $collation parameter, it passes through silently and can be called by its original name.
• JLO: But then you can’t ask “does this function have a collation argument?”
• MK: You could provide an interogative to ask.
  • … But then you can’t pass an option statically because you can’t know statically!
• MK: It’s much more like passing an options map where the names are dynamic.

declare local:add($v1, $v2, $rounding-mode:="normal") { ... }
declare local:sub($v1, $v2) { ... }

declare local:higher-order($op, $f as function($x as xs:double, $y as xs:double)) {
  $f(1, 2)
  $f(1, 2, rounding-mode:="special")
}

local:higher-order(3, local:add#2) (: function works :)
local:higher-order(3, local:sub#2) (: dynamic error in the second call to $f in higher-orde: :)

• MK: Instead of binding $rounding-mode to it’s default when you create the closure, you allow it to be passed through by name.
• NW: I don’t think we’re making improvements…

Looking at the example from issue #1175:

Let’s extend it so that data flow analysis won’t answer the question “is increment correct”?

let $incr := if ($random)
             then fn($arg1, $increment := 1) {$arg1 + $increment }
             else fn($arg1, $decrement := 1) {$arg1 - $decrement }
 return
  (
   $incr(5),
   $incr(5, increment := 2),
   $incr(5, increment := 3)
 )

Presumably this raises a dynamic error when $random is false. It’s impossible to know statically what will happen.

• MK: It’s very much like an options argument on every function and the binding of keyword parameters was creating a binding for that option. In which case it might not be an error. You’d just be supplying an option the function doesn’t use.

Consensus in the room is that keyword arguments on dynamic function calls doesn’t work.

• 1169, Maps & Arrays: Consistency & Terminology
• 1179, Editorial: `array:values`, `map:values`

• 748, Parse functions: consistency
• 1021, Extend `fn:doc`, `fn:collection` and `fn:uri-collection` with options maps
• 1252, Add a new function fn:html-doc

• 285, Stability of collections
• 1183, transient() - a function to make functions nondeterministic
• 1209, 1183 Add transient mode and the transient{} expression

CG points us to his comment about using an any keyword in XQuery.

• MK: I don’t feel strongly about it one way or the other.
• MK: We’re very fuzzy about what strings are acceptable as namespaces.

DN asserts that we need support for map-variadic functions.

MK says that the it isn’t the case because function items can’t be variadic, so you can’t pass them to apply.

• DN: Right now, I think fn:apply can take any function. But that’s not the case?
• MK: No, at the moment, you can pass any function item to fn:apply and function items can’t be variadic currently!
• DN: I think we see the problem here, we need to do something about it.