@qt4cg statuses

I propose an option sandbox=yes for fn:transform, with the effect that the executed stylesheet has no means of accessing or updating external information other than via the fn:transform parameters and result value.

This is to provide an effective and portable way of executing untrusted code.

There are various ways one might specify it: the simplest would be just to state the intent (as in the sentence above) and leave implementations to work out the detail.

An API might also allow transformations to be executed in a sandbox, but that of course is outside our control.

Related: #2034, #1270.

I propose to drop the allow-external-entities and entity-expansion-limit options. They reflect only some of various existing limits that XML parsers provide.

Instead, it seems more reasonable to define such limits globally. It remains to be shown whether we find an implementation-oblivious approach for this.

I skimmed all the specs and nothing looks wrong; I'm going to go ahead and merge this but please report any problems you find that you think might be related.,

Fix #2075

We have extended parse-csv() -- and introduced csv-doc() -- with the ability to read binary input. But we don't provide any way to specify an encoding, and we give no rules for inferring an encoding if none is specified.

Fix #2180

Fix #2187

XQuery §3.2.6 states:

By contrast, xs:untypedAtomic("red") instance of enum("red", "green", "blue") returns false; but the [coercion rules] ensure that where a variable or function declaration specifies an enumeration type as the required type, an xs:untypedAtomic or xs:anyURI value equal to one of the enumerated values will be accepted.

However, looking at the coercion rules, this appears not to be the case.

It seems intuitive that an untypedAtomic value should match an enumeration type (otherwise if the required type is enum("yes", "no"), supplying an attribute whose value is "yes" will fail). And since we generally treat string, untypedAtomic, and anyURI as a single family for equality comparison, it makes sense to accept anyURI as well.

Test case DynamicFunctionCall-136 applies.

I would like to propose a change here so that instead of only outputting the content property of the JNode, we also output the selector property (if present).

I would like to see consideration given to adding an fn:xproc function please. We have an fn:invisible-xml, so why not an fn:xproc?

I think a potential function signature could look like:

fn:xproc($xproc as document-node(element(p:declare-step), $options as map(xs:string, item()+)) as map(xs:string, item()*)`

Map keys/values for $options could be something like:

• "input": Map { "name": "some-name", Map { "type": "some-type", "value": item()* }}
• "option": Map {"name": "some-name", Map { "type": "some-type", "value": item()* }}

Implementers are free to add additional key/value options to the $options map.

The result of the transformation is returned as a map. There is one entry in the map for the default output port, and one for each secondary output port. The key is an xs:string value. The key for the default output port is the string "default" otherwise. The key for secondary output ports, is the name of the port.