Hi Martin,
I have relaxed the type checking of map arguments. Inter alia, booleans will be treated similarly to the string values 'yes' and 'no', and functions calls like the following one will now be evaluated as expected:
serialize(1, map { 'indent': true() })
A new snapshot is online. Adaptive serialization is still on my mental queue (I’ll have to decide if we should apply the same rules here for the 'adaptive' and the 'basex' serialization method).
Have fun, Christian
On Tue, Apr 2, 2019 at 11:03 PM Martin Honnen martin.honnen@gmx.de wrote:
On 02.04.2019 22:37, Christian Grün wrote:
What's your view of adaptive serialization of map(xs:string,xs:string) and a character map, should the character map be applied to the map's key and value string values?
My general view on the adaptive serialization method is that I would have loved it to become what the name implies (adaptive: best fit for the type that’s to be serialized). Instead, it has more or less become a debugging method, and many details have eventually been left to the implementation. As a consequence, we don’t have real use cases for this method, but if it’s used for debugging, it might be better if character maps were ignored, because they could easily create output that’s difficult to reuse.
For XSLT 3 (which shares serialization methods with XQuery) Michael Kay has committed https://github.com/w3c/xslt30-test/commit/21685399a560de67391707cbf5cbff536b... to the XSLT test suite where the defined test results suggest that character maps are to be taken into account for strings with the adaptive output method. And Saxon 9.9's AdaptiveEmitter https://saxonica.plan.io/issues/4187#note-7 has been "adapted" to use a character map "when outputting strings as atomic values". Guess that means that Saxon 9.9 in the next maintenance release will use that code also for XQuery serialization.