Re: Comments on XForms 2.0 Working Draft 7 August 2012

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  
<steven.pemberton@cwi.nl> 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 <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, 22 May 2013 15:43:26 UTC