Re: Comments on XForms 2.0 Working Draft 7 August 2012

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 <eggyal@gmail.com> 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

Received on Wednesday, 8 May 2013 16:15:44 UTC