Re: Comments on XForms 2.0 Working Draft 7 August 2012

Thanks for the comment. We are always happy to incorporate feedback from  
users if it helps them using XForms! It is not too late: though it might  
be too late to make the next draft, it is still in time for the final spec.

The first part seems easy to fix: we remove the requirement on using get  
and post.

Can you however be more explicit in what you would like to see as a  
solution to your second issue?

Best wishes,

Steven Pemberton


On Tue, 30 Apr 2013 11:45:59 +0200, Alan Egerton <eggyal@gmail.com> wrote:

> Dear all,
>
> W3C's SOAPAttach defines a standard way to associate a SOAP message with  
> one or more attachments in a multipart MIME structure for transport. >  
> OASIS's ebMS specification extends SOAPAttach, defining ebXML-specific  
> extensions for the SOAP envelope (first MIME part) and specifying that  
> >application payload should appear in subsequent MIME parts.
>
> There remain (from the XForms 1.0 and 1.1 specifications) two issues  
> that frustrate XForms clients from submitting instance data as  
> SOAPAttach >attachments (and therefore as ebMS messages):
>
> Firstly, section 7.10.3 (SOAP HTTP Binding) states that "The method  
> attribute of the submission must be set to get or post in order to  
> access the >SOAP HTTP binding".  Whilst this is not fatal (as one could  
> generate a SOAP message through scripting), it would be a considerable  
> improvement if >one could simply specify the "multipart-post" method to  
> access a SOAPAttach binding.
>
> But more importantly, section 7.9.5.2 (Serialization as  
> multipart/related) expresses that subsequent MIME parts exist "for each  
> node with a >datatype of xsd:anyURI populated by upload".  This  
> precludes submitting form instance data itself anywhere other than the  
> first MIME part, which >SOAPAttach reserves for the SOAP envelope.  If  
> one wishes to submit instance data as a SOAPAttach attachment, e.g. to  
> be ebMS application payload, >one must serialise the entire message  
> manually - defeating many of the benefits of using XForms!
>
> I don't know whether such use case is within scope for this  
> specification, but I imagine it ought to be.  I also don't know whether  
> it is now too >late to incorporate this feedback into the work on v2.0,  
> but I'd appreciate any thoughts/comments/consideration that you can give.
>
> Kind regards,
> -- Alan