Table des matières | Précédent | Suivant | Bas de page |
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.
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 :
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é ;
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
;
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 ;
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 ;
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
Une fois les données d'instance XML remplacées, les opérations src
,
et l'événement xforms-model-construct
est distribué à l'élément model
.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
.
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].
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 QNamesans préfixe |
non disponible | non disponible |
(tous) | tout nom qualifié de type QNameavec 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.
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 :
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
.
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 ;
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
".
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
.
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--
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 :
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 :
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-1Un fichier --AaB03x Content-Disposition: form-data; name="resume"Content-Type: text/plain; charset=iso-8859-1Voici mon fichier test --AaB03x--
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 :
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 ;
Les nœuds d'élément sélectionnés pour l'inclusion sont codés selon la description 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.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
).
Tous ces codages sont concaténés en conservant l'ordre du document.
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.
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.
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.
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.
Table des matières | Haut de page |