expath-cg icon indicating copy to clipboard operation
expath-cg copied to clipboard

Request body serialization

Open adamretter opened this issue 6 years ago • 12 comments

I think we need better controls over Request body serialization. Some concerns I have:

xs:base64Binary, xs:hexBinary Value will be sent as binary data, the media type will be application/octet-stream.

What happens when you actually want to send base64 encoded or hex encoded data?

xs:string The string will be serialized as UTF-8 octets, the media type will be text/plain.

What happens when you need an encoding which is not UTF-8? For example the HTTP 1.1 default of ISO-8559-1

node() The node will be serialized as XML, the media type will be application/xml.

What happens when you want to send HTML5?

map(*) The map will be serialized as JSON string, the media type will be application/json.

What happens when you try and serialize a map which has something in it which cannot be serialized to JSON like a function() or sequence of more than one item?

Of course we already have a lovely spec that clearly defines such things - XSLT and XQuery Serialization 3.1.

I think the above serialization rules are actually fine as the defaults, but that we need to be able to offer greater control over serialization to the user. I would propose that we add an additional arity set of function signatures which take a $serialization-parameters argument which follows the example of fn:serialize and uses the rules of the XSLT and XQuery Serialization 3.1.

I am not quite sure what to do with regards sending base64 binary data, perhaps it is as simple as $binary cast as xs:string? Perhaps we might want to introduce a binary serialization method and any additional parameters that we need for that, so that we can control base64 and hex binary serialization.

adamretter avatar Aug 10 '18 08:08 adamretter