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

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.

-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"/>
> =============================================
>
>