Please forgive this late foray into discussion of
XForms, but I have only recently begun to look into a particular
application scenario and have some brief observations which I trust may
be useful to a future version.
Whilst addressing the following points (either separately or
together) could be useful in many other applications, it is my hope that
together they will enable instance data to be submitted as the application payload of an [ebMS 2.0] message: that is, instance data could be serialized into a [SOAPAttach] attachment.
I suspect this could prove to be a popular use case for XForms (e.g. user edits a [UBL 2.0] document using an XForm and submits it directly over [ebMS 2.0],
which is the particular scenario I am currently investigating)—however
it would appear that, as things stand, any such implementation must
handle the xforms-submit-serialize event and define the necessary serialization explicitly?
With reference to the [XForms 1.1] specification, I see two specific hurdles:
§11.11.3 states that "the method attribute of the submissionmust be set to get or post in order to access the SOAP HTTP binding", thereby precluding use of the multipart-post method and making any implementation of [SOAPAttach] more complex; and
§11.9.6 defines the multipart/related serialization specifying that, after the root, there are subsequent body parts "for each node with a datatype of xsd:anyURI populated by upload", thereby precluding XML instance data or other generated content from appearing elsewhere than in the first body part.
As an aside and whilst [WebSocket]
is still in draft form, I think it conceivable that submission over
such a persistent transport could be desirable in the future. It's
feasible to accomplish this with client side scripting, however there
does not appear to be any access through the DOM to an XForm's
serialization and therefore any such script must recreate the form's
serialization for itself. Perhaps a DOM method (e.g. getSerialization() or similar) could be useful?