11.1 L'événement xforms-submit

La soumission commence par l'action implicite d'un événement xforms-submit.

Cible : submission

Bouillonne : oui.

S'annule : oui.

Information de contexte : aucune.

Il ne peut y avoir, en aucun cas, plus d'un seul traitement de soumission concurrent en cours pour un modèle XForms particulier pour une soumission XForms particulière. Depuis le début de l'action implicite de l'événement xforms-submit jusqu'à l'achèvement de l'action implicite de l'événement xforms-submit-done, ou xforms-submit-error, l'action implicite d'événements xforms-submit successifs est de ne rien faire.

Sinon, par défaut, l'action de cet événement détermine les étapes suivantes :

1. Un nœud des données d'instance est sélectionné, en fonction des attributs sur l'élément submission. Le nœud indiqué et tous ceux pour lesquels c'est un ancêtre sont retenus pour le reste du processus de soumission. Tout nœud considéré non pertinent, comme défini dans la section 6.1.4, est supprimé ;

2. Toutes les données d'instance sélectionnées sont revalidées, selon les règles dans 4.3.5 L'événement xforms-revalidate, en ne prenant en compte que les nœuds d'espace de nommage concernés pour la sérialisation, comme décrit dans 3.3.3 L'élément submission. Toute donnée d'instance invalide interrompt le traitement de la soumission après distribution d'un événement xforms-submit-error ;

   La validité de toutes les données d'instance sélectionnées est vérifiée selon les règles dans la section 4.3.5 L'événement xforms-revalidate (aucun événement de notification n'est marqué pour distribution dans cette opération). Tout nœud de données d'instance sélectionné, qui est obligatoire mais vide ou qui est invalide, interrompt le traitement de la soumission après distribution d'un événement xforms-submit-error ;

3. Les données d'instance sélectionnées sont sérialisées selon les règles édictées dans 11.2 Les options de soumission ;

4. Les données d'instance sérialisées sont soumises au moyen du protocole indiqué par les règles édictées dans 11.2 Les options de soumission ;

5. La réponse renvoyée de la soumission est appliquée comme suit :

   • Pour une réponse de succès comprenant un corps, lorsque la valeur de l'attribut replace sur l'élément submission est "all", l'événement xforms-submit-done est distribué et le traitement de soumission s'achève avec le remplacement du document conteneur entier par le corps renvoyé ;

   • Pour une réponse de succès comprenant le corps d'un type de média XML (comme défini par les indicateurs de type de contenu dans [RFC 3023]), lorsque la valeur de l'attribut replace sur l'élément submission est "instance", la réponse est analysée en tant que code XML. et Si l'analyse réussit, alors toutes les données d'instance internes correspondant à l'instance soumise de l'instance indiquée par l'attribut instance sont remplacées par le résultat., en utilisant le même traitement que celui des données d'instance chargées au travers de l'attribut src, et l'événement xforms-model-construct est distribué à l'élément model. Une fois les données d'instance XML remplacées, les opérations rebuild, recalculate, revalidate et refresh sont réalisées sur l'élément model, sans distribution d'événements invoquant ces quatre opérations. Le traitement de soumission s'achève alors après distribution d'un événement xforms-submit-done ;

   • Pour une réponse de succès comprenant le corps d'un type de média non-XML (c'est-à-dire, avec un type de contenu ne correspondant à aucun des indicateurs dans [RFC 3023]), lorsque la valeur de l'attribut replace sur l'élément submission est "instance", rien n'est remplacé dans le document, et le traitement de soumission s'achève après distribution d'un événement xforms-submit-error ;

   • Pour une réponse de succès comprenant un corps, lorsque la valeur de l'attribut replace sur l'élément submission est "none", le traitement de soumission s'achève après distribution d'un événement xforms-submit-done ;

   • Pour une réponse de succès ne comprenant pas de corps, le traitement de soumission s'achève après distribution d'un événement xforms-submit-done ;

   • Les comportements des autres valeurs possibles de l'attribut replace ne sont pas définis dans la présente spécification ;

   • Pour une réponse erronée, rien n'est remplacé dans le document et le traitement de soumission s'achève après distribution d'un événement xforms-submit-error.

11.2 Les options de soumission

Le modèle XForms définit un élément submission contenant les attributs suivants qui affectent la sérialisation et la soumission. Cette section résume les comportements pour les valeurs admissibles de ces attributs et introduit les sections suivantes qui définissent le comportement pour la sérialisation et la soumission. (Cf. 3.3.3 L'élément submission pour les autres attributs de l'élément submission qui affectent la sérialisation).

• action (xsd:anyURI)

• method (xsd:string, énuméré ci-dessous)

Pour le système d'adresse URI de l'attribut action, XForms définit de manière normative une liaison au protocole HTTP/1.1 [RFC 2616].

L'attribut method détermine le format de la sérialisation et le système d'adresse URI utilisé dans l'attribut action détermine le protocole de soumission, selon le tableau suivant :

11.3 La sérialisation application/xml

Ce format permet d'exprimer les données d'instance sous une forme XML qu'on peut traiter directement avec les outils de traitement XML prêts à l'emploi. En outre, ce format est apte à la soumission d'un contenu binaire.

Les étapes de la sérialisation sont les suivantes :

1. Le document XML est produit selon les règles de la méthode XML output définie dans [XSLT 1.0], section 16 et 16.1, en utilisant les valeurs fournies comme attributs de l'élément submission.

   1. La gestion des nœuds d'espace de nommage : Le comportement par défaut est tel que chaque nœud d'espace de nommage est sérialisé conformément aux règles de la méthode XML output, de sorte qu'au moins une déclaration d'espace de nommage apparaisse dans le document XML sérialisé pour chaque espace de nommage visible. Les autres espaces de nommage hérités sont déclarés sur l'élément racine du document XML sérialisé. Toutefois, si l'attribut includenamespaceprefixes est présent sur l'élément submission, alors toutes les déclarations d'espace de nommage non utilisés visiblement dans les instances de données (comme défini dans [Exc-C14N]) et, le cas échéant, l'espace de nommage par défaut s'il est vide, sont exclus de la sérialisation de l'élément racine, à moins que le préfixe d'espace de nommage correspondant ne soit listé dans ce même attribut includenamespaceprefixes. La valeur spéciale "#default" représente l'espace de nommage par défaut ;

   2. Le type de média : Par défaut, le type de média de l'instance XML sérialisée est "application/xml" mais il peut se changer en un type compatible en utilisant l'attribut mediatype de l'élément submission. Les auteurs devraient s'assurer que le type indiqué soit compatible avec "application/xml".

11.4 La sérialisation multipart/related

Ce format est destiné à l'intégration de XForms dans des environnements qui brassent de grandes quantités de données binaires et où l'inclusion de données sous les types xsd:base64Binary ou xsd:hexBinary n'est pas souhaitable.

Dans ce format, les données d'instance XML sont sérialisées comme composant une partie du message multipart/related [RFC 2387], en utilisant les règles décrites dans 11.3 La sérialisation application/xml. Le contenu binaire des nœuds d'instance de type xsd:anyURI peuplés par la commande upload (cf. 8.1.6 L'élément upload) est sérialisé dans des parties distinctes du message multipart/related [RFC 2387].

Ce format suit les règles des flux de donnée MIME multipart/related dans [RFC 2387], les conditions particulières de cette sérialisation étant listées ci-dessous :

• Les conditions de l'en-tête du message multipart/related :

  • Elle doit contenir un paramètre type du type de média de l'instance XML sérialisée ;

  • Elle doit contenir un paramètre start se référant au paramètre Content-ID de la première partie du corps (racine).

• Les conditions de la première partie du corps (racine) :

  • Elle doit avoir un paramètre Content-Type du type indiqué par l'attribut mediatype de l'élément submission ;

  • Le contenu est sérialisé selon les règles édictées dans 11.3 La sérialisation application/xml.

• Les conditions des parties suivantes ;:

  • Une partie pour chaque nœud de type de donnée xsd:anyURI peuplé par la commande upload avec :

    • Une en-tête Content-Type qui représente le type de la pièce jointe s'il est connu, sinon "application/octet-stream" ;

    • Une en-tête Content-Transfer-Encoding ;

    • Une en-tête Content-ID dont la valeur correspond à l'adresse URI dans le nœud de donnée d'instance associé ;

    • Le contenu binaire associé à l'adresse URI, sérialisé conformément à l'indication de l'en-tête Content-Transfer-Encoding.

Content-Type: multipart/related; boundary=f93dcbA3; type=application/xml; start="<980119.X53GGT@example.com>"
Content-Length: xxx
--f93dcbA3
Content-Type: application/xml; charset=UTF-8
Content-ID: <980119.X53GGT@example.com>
<?xml version="1.0"?>
<uploadDocument>
  <title>Ma proposition</title>
  <author>Gaspard EXEMPLE</author>
  <summary>Une proposition pour un nouveau projet.</summary>
  <notes image="cid:980119.X17AXM@example.com">(voir la zone manuscrite)</notes>
  <keywords>proposition projet financement</keywords>
  <readonly>false</readonly>
  <filename>image.png</filename>
  <content>cid:980119.X25MNC@example.com</content>
</uploadDocument>
--f93dcbA3
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <980119.X25MNC@example.com>
...données binaires ici...
--f93dcbA3
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <980119.X17AXM@example.com>
...données binaires ici...
--f93dcbA3--

11.5 La sérialisation multipart/form-data

Ce format est donné pour des raisons de compatibilité avec l'existant afin de permettre l'utilisation de clients XForms avec les serveurs conformes [RFC 2388]. Cette méthode convient pour la persistence du contenu binaire. Les informations contextuelles de chemin, les valeurs d'attribut, les espaces et préfixes d'espace de nommage ne sont pas préservés. Par conséquent, des éléments différents sont susceptibles de se sérialiser dans le même nom.

Ce format suit les règles des flux de données MIME multipart/form-data édictées dans [RFC 2388], les conditions particulières de cette sérialisation étant listées ci-dessous :

• Chaque nœud d'élément est visité dans l'ordre du document ;

• Chaque élément n'ayant exactement qu'un seul enfant nœud de texte est sélectionné pour l'inclusion ;

• Les nœuds sélectionnés pour l'inclusion sont codés comme des parties MIME Content-Disposition: form-data conformément à [RFC 2387], le paramètre name correspondant au nom local de l'élément ;

• Les nœuds d'élément de tout type de donnée peuplés par la commande upload sont sérialisé comme étant le contenu défini et ont, en outre, un paramètre Content-Disposition filename si disponible ;

• La valeur du paramètre Content-Type doit être "text/plain", sauf pour les types xsd:base64Binary, xsd:hexBinary et les types dérivés, auxquels cas l'en-tête représente le type de média de la pièce jointe si ce type est connu, sinon "application/octet-stream". Le paramètre Content-Type peut avoir un paramètre charset, le cas échéant.

Exemple :

Content-Type: multipart/form-data; boundary=AaB03x
Content-Length: xxx
        
--AaB03x
Content-Disposition: form-data; name="document"; filename="b.txt"
Content-Type: text/plain; charset=iso-8859-1
Voici un fichier.
Il fait deux lignes.
--AaB03x
Content-Disposition: form-data; name="titre"
Content-Type: text/plain; charset=iso-8859-1
Un fichier
--AaB03x
Content-Disposition: form-data; name="resume"
Content-Type: text/plain; charset=iso-8859-1
Voici mon fichier test
--AaB03x--

11.6 La sérialisation application/x-www-form-urlencoded

Ce format de sérialisation est destiné à permettre l'utilisation d'un formulaire afin de réunir les données nécessaires pour produire une adresse URI qui nomme une ressource afin d'y accéder par une opération HTTP GET.

C'est une extension du type de contenu de formulaire [XHTML 1.0] application/x-www-form-urlencoded, avec des règles particulières pour le codage des caractères non-ASCII et ceux réservés.

Ce format ne convient pas à la persistence du contenu binaire. Par conséquent, on recommande d'utiliser une autre méthode de sérialisation pour les formulaires aptes à recevoir un contenu binaire.

Les étapes de la sérialisation sont les suivante :

1. Chaque nœud élément est visité dans l'ordre du document. Chaque élément ayant un sous-élément nœud de texte est sélectionné pour l'inclusion. Remarquez que les informations des attributs ne sont pas préservées ;

2. Les nœuds d'élément sélectionnés pour l'inclusion sont codés selon la description EltName=value{sep}, dans laquelle = est un caractère littéral, {sep} est le caractère séparateur indiqué par l'attribut separator sur l'élément submission, EltName représente le nom local de l'élément et value représente le contenu du nœud de texte. Les nœuds d'élément sélectionnés pour l'inclusion sont codés selon la description EltName=value, dans laquelle = est un caractère littéral, EltName représente le nom local de l'élément et value représente le contenu du nœud textuel. Le caractère séparateur {sep}, donné par l'attribut separator sur l'élément submission, s'utilise entre les couples nom-valeur codés : EltName=value{sep}EltName=value{sep}EltName=value. Remarquez que ni les informations contextuelles de chemin ni les espaces de nommage ou/et leurs préfixes ne sont préservés. Par conséquent, des éléments différents sont susceptibles de se sérialiser dans le même nom.

   • Le codage de EltName et value est le suivant : les caractères espace sont remplacés par des signes + puis les caractères non-ASCII et ceux réservés (comme défini par le document [RFC 2396] amendé par des documents successifs dans le suivi IETF) sont échappés, en remplaçant le caractère par l'octet, ou les octets, de la représentation UTF-8 du caractère, chaque octet étant à son tour remplacé par un code %HH, où HH représente la notation hexadécimale en capitales de la valeur d'octet et % est un caractère littéral. Les sauts de ligne sont représentés par des couples de caractères CR LF (c'est-à-dire, %0D%0A).

3. Tous ces codages sont concaténés en conservant l'ordre du document.

Exemple :

Prenom=Ren%C3%A9;

<NomPersonne title="M.">
  <Prenom>René</Prenom>
</NomPersonne>

11.7 Les méthodes de soumission post, multipart-post, form-data-post et urlencoded-post

Ces méthodes de soumissions représentent le concept HTTP POST ou un concept équivalent (tel qu'un message électronique). Les données de formulaire sérialisées sont livrées en tant que corps du message.

11.8 La méthode de soumission put

Cette méthode de soumission représente le concept HTTP PUT, ou un concept équivalent (tel qu'écrire dans un fichier local). Les données de formulaires sérialisées sont livrées en tant que corps du message.

11.9 La méthode de soumission get

Cette méthode de soumission représente le concept HTTP GET, ou un concept équivalent. Les données de formulaire sérialisées sont livrées en tant que partie de l'adresse URI qui est demandée au cours du processus de soumission.

Cette méthode ne convient pas pour la soumission de formulaires qui sont prévus pour changer d'état ou pour entraîner d'autres actions sur le serveur. Cf. [RFC 2616] pour les utilisations recommandées de HTTP GET.

L'adresse URI se construit comme suit :

• L'adresse URI de soumission de l'attribut action est examinée : si elle ne contient pas de caractère point d'interrogation ?, il lui en est adjoint un ; si elle en contient déjà un, alors il lui est adjoint un caractère de séparation, celui indiqué par l'attribut separator ;

• Les données de formulaires sérialisées sont adjointes à l'adresse URI.

Aucun corps de message n'est envoyé avec la requête.