Comments on XForms 2.0 Working Draft 7 August 2012

[Alan Egerton]

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

[Steven Pemberton-3]

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 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

[Alan Egerton]

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

[Alan Egerton]

> 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

[Steven Pemberton-3]

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

[Steven Pemberton-3]

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