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 |
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 <[hidden email]> wrote:
|
Dear Steven,
Thank you for your reply. Really glad to hear my comments can still be taken on board! > The first part seems easy to fix: we remove the requirement on using get and post. That's excellent, although I can't comment on whether there is any demand to allow additional methods other than "multipart-post". My main observation with merely removing the requirement on submission method is that the rules for "post" should also be followed by method="multipart-post": especially that the Content-type HTTP header should be changed to "text/xml" if the instance data being submitted has as its root element node a SOAP envelope in the SOAP 1.1 namespace. > Can you however be more explicit in what you would like to see as a solution to your second issue? One idea may be to define a new XForms Action, "attach", for each invocation of which an additional attachment is appended to the multipart/related message. It might have attributes similar to the following: * src: the document to be attached - I'm not sure how best to express this, but one should be able to specify a document node that is to be serialised e.g. "instance('attachment')/foo" or a URI to be fetched by the processor e.g. "http://foo.com/image.jpeg" (perhaps evaluated with AVT) or even a base64 literal e.g. "Zm9vYg==" (perhaps literals should be given as the content of the "attach" element, rather than in this attribute); * mediatype: the MIME Content-Type of the attachment (to be inferred where possible if not explicitly given); and * ref: references the instance node (of type xsd:anyURI?), if any, whose value will be set to the Content-ID header of this attachment (if any). What do you think? Kind regards, -- Alan |
> My main observation with merely removing the requirement on submission
> method is that the rules for "post" should also be followed by > method="multipart-post": especially that the Content-type HTTP header > should be changed to "text/xml" if the instance data being submitted > has as its root element node a SOAP envelope in the SOAP 1.1 > namespace. Sorry, that was a little dumb. The Content-Type HTTP header should of course be "multipart/related" - it is its "type" parameter which should be changed as above, but otherwise follow the rules for multipart/related serialisation under §7.9.5.2. -- Alan |
In reply to this post by Alan Egerton
Hi Alan,
Thanks for your reply. The Forms WG discussed this today [1], and while we agree with point one, about relaxing the restrictions on method, we realise that there is still some design work to be done on part two, and we see close parallels with some serialisation work we have recently been doing. So we are going to think about possible solutions over the next two weeks, and then discuss them (please free welcome to chime in). However, we don't want to this issue to block us going to last call, so if we should fail to solve it properly before going to last call, we will take your issue as a last-call comment, so that it doesn't get lost. Best wishes, Steven Pemberton [1] http://www.w3.org/2013/05/08-forms-minutes.html#item02 On Wed, 01 May 2013 22:21:17 +0200, Alan Egerton <[hidden email]> wrote: > Dear Steven, > > Thank you for your reply. Really glad to hear my comments can still > be taken on board! > >> The first part seems easy to fix: we remove the requirement on using >> get and post. > > That's excellent, although I can't comment on whether there is any > demand to allow additional methods other than "multipart-post". > > My main observation with merely removing the requirement on submission > method is that the rules for "post" should also be followed by > method="multipart-post": especially that the Content-type HTTP header > should be changed to "text/xml" if the instance data being submitted > has as its root element node a SOAP envelope in the SOAP 1.1 > namespace. > >> Can you however be more explicit in what you would like to see as a >> solution to your second issue? > > One idea may be to define a new XForms Action, "attach", for each > invocation of which an additional attachment is appended to the > multipart/related message. It might have attributes similar to the > following: > > * src: the document to be attached - I'm not sure how best to express > this, but one should be able to specify a document node that is to be > serialised e.g. "instance('attachment')/foo" or a URI to be fetched by > the processor e.g. "http://foo.com/image.jpeg" (perhaps evaluated with > AVT) or even a base64 literal e.g. "Zm9vYg==" (perhaps literals should > be given as the content of the "attach" element, rather than in this > attribute); > > * mediatype: the MIME Content-Type of the attachment (to be inferred > where possible if not explicitly given); and > > * ref: references the instance node (of type xsd:anyURI?), if any, > whose value will be set to the Content-ID header of this attachment > (if any). > > What do you think? > > Kind regards, > -- Alan |
Hi Alan,
I just wanted to draw your attention to a proposal by Erik Bruchez to do with multipart submissions: http://lists.w3.org/Archives/Public/public-forms/2013May/0014.html All commentary gratefully received! Best wishes, Steven Pemberton On Wed, 08 May 2013 18:14:52 +0200, Steven Pemberton <[hidden email]> wrote: > Hi Alan, > > Thanks for your reply. The Forms WG discussed this today [1], and while > we agree with point one, about relaxing the restrictions on method, we > realise that there is still some design work to be done on part two, and > we see close parallels with some serialisation work we have recently > been doing. > > So we are going to think about possible solutions over the next two > weeks, and then discuss them (please free welcome to chime in). > > However, we don't want to this issue to block us going to last call, so > if we should fail to solve it properly before going to last call, we > will take your issue as a last-call comment, so that it doesn't get lost. > > Best wishes, > > Steven Pemberton > > [1] http://www.w3.org/2013/05/08-forms-minutes.html#item02 > > On Wed, 01 May 2013 22:21:17 +0200, Alan Egerton <[hidden email]> > wrote: > >> Dear Steven, >> >> Thank you for your reply. Really glad to hear my comments can still >> be taken on board! >> >>> The first part seems easy to fix: we remove the requirement on using >>> get and post. >> >> That's excellent, although I can't comment on whether there is any >> demand to allow additional methods other than "multipart-post". >> >> My main observation with merely removing the requirement on submission >> method is that the rules for "post" should also be followed by >> method="multipart-post": especially that the Content-type HTTP header >> should be changed to "text/xml" if the instance data being submitted >> has as its root element node a SOAP envelope in the SOAP 1.1 >> namespace. >> >>> Can you however be more explicit in what you would like to see as a >>> solution to your second issue? >> >> One idea may be to define a new XForms Action, "attach", for each >> invocation of which an additional attachment is appended to the >> multipart/related message. It might have attributes similar to the >> following: >> >> * src: the document to be attached - I'm not sure how best to express >> this, but one should be able to specify a document node that is to be >> serialised e.g. "instance('attachment')/foo" or a URI to be fetched by >> the processor e.g. "http://foo.com/image.jpeg" (perhaps evaluated with >> AVT) or even a base64 literal e.g. "Zm9vYg==" (perhaps literals should >> be given as the content of the "attach" element, rather than in this >> attribute); >> >> * mediatype: the MIME Content-Type of the attachment (to be inferred >> where possible if not explicitly given); and >> >> * ref: references the instance node (of type xsd:anyURI?), if any, >> whose value will be set to the Content-ID header of this attachment >> (if any). >> >> What do you think? >> >> Kind regards, >> -- Alan |
Free forum by Nabble | Edit this page |