Influence of serialization options in XQuery 3.1 code of p:xquery step

[martin-honnen]

I am wondering whether the use of serialization options in XQuery 3.1 code can change the type of result or potential error with a p:xquery step.

For instance, would a simple

map { 'test' : 'foo' }

have the same result as

declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization";

declare option output:method 'xml';

map { 'test' : 'foo' }

Or would the latter cause an error err:XC0104 as it is not possible to serialize a map with that output method?

Are serialization options ignored by p:xquery as XDM values are the result of the step or is serialization done?

[gimsieke]

I am wondering whether the use of serialization options in XQuery 3.1 code can change the type of result or potential error with a p:xquery step.

The serialization options given in the XQuery should be used by the XProc processor to prime the serialization document property, see § 3.1. Document Properties. There is no guarantee though that a given XSLT or XQuery implementation exposes them. Norm has found out that Saxon does expose them in a certain API.

The serialization parameters will not influence the result, which is an XDM document node, array, map, or atomic value, or sequence thereof.

They won’t be applied until serialization occurs, and they can be overridden by serialization parameters on a step that does the serialization.

For instance, would a simple

map { 'test' : 'foo' }

have the same result as

declare namespace output = "http://www.w3.org/2010/xslt-xquery-serialization";

declare option output:method 'xml';

map { 'test' : 'foo' }

Yes. The XProc processor will attach a document property content-type with the value application/json (as per § 3.3. Creating documents from XDM step results) and, for the latter case, store {'method':'xml'} in the serialization document property.

However, the last sentence in § 3.1 might suggest that the processor must remove (or not attach in the first place) the serialization document property if it is incompatible with the content-type. We might need to clarify this.

Or would the latter cause an error err:XC0104 as it is not possible to serialize a map with that output method?

In §16.3.1. Serialization parameters we say that “the processor must not raise an error if the output could not be serialized with those parameters.”

Only if you are actually serializing, err:XD0020 will be thrown if you attempt to serialize a JSON document as XML.

Are serialization options ignored by p:xquery as XDM values are the result of the step or is serialization done?

Serialization options from XQuery will at best make it to the serialization document property map. Serialization is deferred.

[gimsieke]

Yes. The XProc processor will attach a document property content-type with the value application/json (as per § 3.3. Creating documents from XDM step results) and, for the latter case, store {'method':'xml'} in the serialization document property.

However, the last sentence in § 3.1 might suggest that the processor must remove (or not attach in the first place) the serialization document property if it is incompatible with the content-type. We might need to clarify this.

In § 3.1, one could replace

“If this is the case, the specified serialization properties should be returned in the result document(s) serialization property, as an appropriate serialization properties map.”

with

“If this is the case and inasmuch as they are compatible with the result document content types, the specified serialization properties should be returned in the result document(s) serialization property, as an appropriate serialization properties map.”

However, I’m not sure whether we should amend the core spec at this late stage for such a pathological case though.

One point of view is that a serialization map that contradicts the content-type wouldn’t be “appropriate” in the first place and therefore need not be attached to the result document.

[martin-honnen]

@gimsieke, thanks, I can well live with your explanation on the relevant sections about document properties, it has helped me a lot to have a clear understanding on how XSLT 3 and XQuery 3 are to be used in XProc 3. At least from my point of view you can close the issue without trying to amend the spec.