Re: ACTION-2217: Spec up file/read and write (and provide links)

On Wed, 15 Apr 2020 08:07:17 +0200, Erik Bruchez <ebruchez@orbeon.com>  
wrote:

> This sounds reasonable.
>
> We can imagine lifting the requirement for a user dialog in some  
> circumstances. For example, a native app using XForms >might want to  
> read/write files, at least in some locations, without the user's  
> constant interaction.

I think that is the clue: you want to protect people from malware that  
read or write files on your machine, so they need some protection, but  
maybe sandboxed files are relatively safe (though even then there may be  
privacy issues).

The reason I proposed the dialogs is simply so that the user is informed  
about what a form is doing with his or her computer.

Steven

>
> -Erik
>
> On Tue, Apr 14, 2020 at 5:45 AM Steven Pemberton  
> <steven.pemberton@cwi.nl> wrote:
>> Here is draft spec text, which involves a slight rearrangement of
>> https://www.w3.org/community/xformsusers/wiki/XForms_2.0#Submission_Options
>>
>> Steven
>>
>> =============================================
>>
>> 11.3 Submission Options
>>
>> How instance data is submitted depends on two aspects:
>>
>> * the URI scheme in the submission resource which determines the  
>> submission protocol
>> * the submission method, which determines the default data  
>> serialization format
>>
>> [OVERVIEW TABLE]
>>
>> Note: Foreign-namespaced attribute values are allowed in the Submission  
>> Method, but no behavior is defined for them.
>>
>> 11.3.1 Submission Protocols
>>
>> 11.3.1.1 The HTTP and HTTPS Protocols
>>
>> Processors must support HTTP/1.1 [RFC 2616], and HTTPS [RFC 2818];  
>> authors are encouraged to follow the finding of the W3C Technical  
>> Architecture Group on when to use the GET method: [TAG Finding 7]
>>
>> [[EXISTING SECTION ON METHODS GET PUT POST AND DELETE INSERTED HERE]]
>>
>> 11.3.1.2 The File Protocol
>>
>> Standalone XForms applications can be greatly helped by being able to  
>> store and retrieve data locally without recourse to a server.  
>> Processors should support the File protocol [RFC 8089]; processors may  
>> sandbox the area used for files.
>>
>> In XForms, the File protocol supports three methods:
>>
>>  * GET
>>    All serialized data, if any, is ignored. A file-open dialog is  
>> initiated with the user, initialised to the location given in the URI.  
>> The user can accept this suggestion, or choose another file as  
>> replacement. If the chosen file is readable, its contents are returned  
>> as the body of the response, with a suitable mediatype, and the  
>> submission succeeds; if the file is not readable, the submission fails  
>> with result-error-response and an error-message of <some message>. The  
>> user can alternatively cancel the dialog, in which case the submission  
>> fails with result-error-response and an error-message of "cancelled".
>>
>>  * PUT
>>    A file-save dialog is initiated with the user, initialised to the  
>> location given in the URI. The user can accept this suggestion, or  
>> choose another file location and name as replacement. If the chosen  
>> location is writable, its contents are initialised or replaced with the  
>> serialized data of the submission, and the submission succeeds; if the  
>> location is not writable, the submission fails with  
>> result-error-response and an error-message of <some error message>. The  
>> user can alternatively cancel the dialog, in which case the submission  
>> fails with result-error-response and an error-message of "cancelled".
>>
>>  * DELETE
>>    All serialized data, if any, is ignored. A file delete dialog is  
>> initiated with the user, initialised to the location given in the file  
>> URI. The user can accept this suggestion, and if the file is deletable,  
>> it is deleted, and the submission succeeds; if the file is not  
>> deletable, the submission fails with result-error-response and an  
>> error-message of <some error message>. The user can alternatively  
>> cancel the dialog, in which case the submission fails with  
>> result-error-response and an error-message of "cancelled".
>>
>> A submission using any other method with a file: URI fails with  
>> result-error-response and an error-message of "Method not supported".
>>
>> 11.3.2 The mailto: protocol
>>
>> Processors may support the mailto: protocol [RFC 6068].
>>
>> It supports four methods: post, multipart-post, form-data-post, and  
>> urlencoded-post. These are actually all the same method, POST, but with  
>> different default serializations. That is to say:
>>
>>   <submission resource="mailto:person@example.com"  
>> method="multipart-post"/>
>>
>> is the same as
>>
>>   <submission resource="mailto:person@example.com" method="post"  
>> serialization="multipart/related"/>
>>
>> For that reason, we only define POST here:
>>
>> * POST
>>   If the serialization used is application/x-www-form-urlencoded, the  
>> serialized data is delivered as part of the URI that is used during the  
>> submit process; otherwise the serialized data is delivered as the body  
>> of the submission.
>>
>> Example
>>
>> <instance id="mail">
>>    <mail to="registrations@example.com" xmlns="">
>>       <subject>Conference registration</subject>
>>       <cc>secretariat@example.com</cc>
>>       <body>Please register me for your conference.</body>
>>    </mail>
>> </instance>
>> <bind ref="to|cc" type="iemail"/>
>>
>> <submission ref="instance('mail')"  
>> resource="mailto:{instance('mail')/@to}" method="urlencoded-post"/>
>> =============================================