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

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

Received on Tuesday, 14 April 2020 12:45:06 UTC