11 La soumission

Le langage XForms est conçu pour rassembler des données d'instance, les sérialiser en une représentation externe et la soumettre avec un protocole. XForms définit un ensemble d'options pour la sérialisation et la soumission. Les sections suivantes définissent le traitement des données d'instance pour leur soumission et le comportement des options de sérialisation et de soumission.

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).

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].

Remarque :

D'autres liaisons, en particulier au système d'adresse URI mailto: (qui peut) et aux systèmes https: et file: (qui devraient), peuvent être prises en charge. Les liaisons à ces systèmes ne font pas l'objet d'une définition normative dans XForms. Les implémentations qui choisissent d'offrir une liaison vers ces systèmes devraient faire particulièrement attention aux questions de vie privée et de sécurité. Dans les systèmes http: et https:, les créateurs de formulaires sont invités à suivre les conclusions du Groupe Architecture Technique du W3C concernant les conditions dans lesquelles utiliser la méthode get [TAG Finding 7]

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 :

Système d'adresse URI method Sérialisation Soumission
http https mailto "post" application/xml HTTP POST, ou équivalent
http https file "get" application/x-www-form-urlencoded HTTP GET, ou équivalent
http https file "put" application/xml HTTP PUT, ou équivalent
http https mailto "multipart-post" multipart/related HTTP POST, ou équivalent
http https mailto "form-data-post" multipart/form-data HTTP POST, ou équivalent
http https mailto "urlencoded-post" (à éviter) application/x-www-form-urlencoded HTTP POST, ou équivalent
(tous) tout autre nom qualifié de type QName sans préfixe non disponible non disponible
(tous) tout nom qualifié de type QName avec préfixe définie par l'implémentation définie par l'implémentation

Remarque :

Les attributs dans un espace de nommage étranger sont admis sur l'élément submission mais aucun comportement n'est défini par XForms 1.0.

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 :

Exemple : multipart/related
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.

Remarque :

Les agents utilisateurs HTML existants sont incapables de coder les caractères spéciaux (tels que les guillemets doubles) et les caractères non-ASCII dans les paramètres Content-Disposition: form-data name et filename. La prise en compte de cette méthode de sérialisation n'est retenue que pour les applications existantes, les nouvelles applications devraient utiliser application/xml ou multipart/related.

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 :

Exemple :

Exemple : multipart/form-data
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 :

Exemple : application/x-www-form-urlencoded
Prenom=Ren%C3%A9;

Ce format se compose de simples couples nom-valeur.

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

Voici les données d'instance correspondant à l'exemple ci-dessus. Remarquez qu'une très faible partie des données est préservée. Les auteurs souhaitant disposer d'une plus grande intégrité des données devraient choisir un autre format de sérialisation.

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 :

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