W3C home > Mailing lists > Public > public-xformsusers@w3.org > April 2018

Non-XML parsing for submission response body

From: Alain Couthures <alain.couthures@agencexml.com>
Date: Sun, 15 Apr 2018 09:50:03 +0200
To: "public-xformsusers@w3.org" <public-xformsusers@w3.org>
Message-ID: <489b987c-282f-87be-dfc0-0575b54349a5@agencexml.com>

Nowadays, there are REST APis in JSON format only: data is to be 
provided in JSON serialization while responses might be in JSON format 
or just in text, or HTML, format.

With XForms 2.0, @serialization and @mediatype can be used to submit an 
instance in non-XML format. Then, an instance can be targeted by the 
submission for storing the response body. There is always a Content-Type 
associated with the HTTP response but, frequently, this value is poorly 
provided or even inadequate.

A way to override the response Content-Type is required. At submission 
level, @response-mediatype might be specified and, possibly, 
@request-mediatype could also explicitly replace @mediatype. Yet, 
@mediatype could also be added to the instance element, allowing also 
its use for external sources.

XSLTForms already supports @mediatype for instance element. It has been 
added for both external sources and inline data.

Using instance/@mediatype also for submission response body would mean 
that the same instance could only be used with one external 
serialization while it is always stored in an XML tree. It might be true 
in most cases but specifying mediatypes at submission level does not 
have this drawback.

Maybe "@mediatype" is not the best name at instance level for this 
purpose and, instead of 
@serialization/@mediatype/@parsing could also be more explicit. For both 
XSLT and XQuery, the way data is to be serialized is named "method" 
(already used in XForms for HTTP verb...) and its values might be "xml", 
"html", "json",... It could probably be better for XForms 2.0 if 
@serialization could accept similar values instead of content types 
("xml" vs. "application/xml", ...) even if the multipart serialization 
support is also to be considered. Identically, instead of 
instance/@mediatype, something like instance/@format or 
instance/@notation could be more convenient.

What do you think?

Received on Sunday, 15 April 2018 07:50:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:49 UTC