6 Les propriétés d'élément de modèle

Ce chapitre définit les contributions infoset pouvant être liées aux nœuds de donnée d'instance avec l'élément bind (voir 3.3.4 L'élément bind). La combinaison de ces contributions à un nœud de donnée d'instance est appelée élément de modèle. Prises ensemble, ces contributions sont appelées propriétés d'élément de modèle ; elles sont définies dans la section suivante. Par opposition, le terme contrainte de schéma se rapporte seulement aux contraintes du schéma XML issues des facettes d'un certain type de donnée.

6.1 Les définitions des propriétés d'élément de modèle

On peut distinguer les propriétés d'élément de modèle selon divers axes.

Les expressions calculées par rapport aux propriétés fixes :

Les règles d'héritage :

Certaines propriétés d'élément de modèle définissent des règles d'héritage, auquel cas le processeur XForms doit assurer le suivi de deux valeurs séparées : d'une part, la valeur locale, qui est appliquée à partir d'un attribut de l'élément bind, et, d'autre part, la valeur héritée, qui est déterminée en combinant la valeur locale évaluée et les valeurs évaluées des nœuds ancêtres dans les données d'instance.

Remarque :

L'exemple d'algorithme de recalcul défini dans D L'algorithme de séquence de recalcul est défini pour agir seulement sur les valeurs locales d'une propriété d'élément de modèle. Il suppose que l'implémentation propage les valeurs combinées aux descendants d'un nœud.

L'assignation des valeurs locales :

Les valeurs locales sont assignées en traitant tous les éléments bind d'un modèle XForms dans l'ordre du document. Une tentative de fixer deux fois la valeur d'une propriété d'élément de modèle sur le même nœud constitue une erreur. Les détails concernant ce traitement se trouvent dans 4.2.1 L'événement xforms-model-construct.

Les sections suivantes listent les propriétés d'élément de modèle disponibles pour tous les éléments de modèle. Pour chacune, on donne les renseignements suivants :

Description
Expression calculée (oui ou non)
Valeurs légales
Valeur implicite
Règles d'héritage

6.1.1 La propriété type

Description : associe un type de donnée de schéma.

Expression calculée : non.

Valeurs légales : toute valeur de type xsd:QName représentant une définition de type de donnée dans un schéma XML.

Valeur implicite : valeur de type xsd:string.

Règles d'héritage : ne s'hérite pas.

L'effet de cette propriété d'élément de modèle est le même que celui produit par un attribut xsi:type placé sur les données d'instance. Toutefois, contrairement à xsi:type, la propriété type peut s'ajouter aux éléments comme aux attributs.

Exemple : Joindre une contrainte de type du schéma XML
<instance>
  <my:nom-personne>
    <my:prenom />
    <my:nom xsi:type="my:chaineNonVide" />
  </my:nom-personne>
</instance>
<bind type="my:chaineNonVide" nodeset="/my:nom-personne/my:prenom" />

Nous illustrons ici deux façons d'associer un type d'un schéma XML à un élément.

6.1.2 La propriété readonly

Description : indique si la valeur est interdite de changement.

Expression calculée : oui.

Valeurs légales : toute expression convertible en un type XPath boolean avec la fonction boolean().

Valeur implicite : false(), à moins qu'une propriété calculate ne soit définie alors true().

Règles d'héritage : si un nœud ancêtre est évalué à true, alors cette valeur est traitée comme true. Sinon, la valeur locale est utilisée.

Remarque :

Cela équivaut à prendre le OU logique de la propriété readonly évaluée sur le nœud local et tous les nœuds ancêtres.

Lorsqu'elle est évaluée à true, cette propriété d'élément de modèle indique au processeur XForms qu'il ne devrait pas autoriser de changements au nœud de donnée d'instance lié.

Outre cette restriction sur les changements de la valeur, la propriété d'élément de modèle readonly fournit une indication à l'interface d'utilisateur XForms. Les commandes de formulaire liées aux données d'instance par la propriété d'élément de modèle readonly devraient indiquer que la saisie et la modification de la valeur ne sont pas permises. La présente spécification ne définit aucun effet en ce qui concerne la visibilité, le focus ou l'ordre de navigation.

Exemple : Joindre une propriété readonly
<instance>
  <my:nom-personne>
    <my:prenom>Roland</my:prenom>
    <my:nom/>
  </my:nom-personne>
</instance>
<bind nodeset="/my:nom-personne/my:prenom" readonly="true()"/>

Nous avons associé ici une propriété readonly à un élément.

6.1.3 La propriété required

Description : définit si une valeur est obligatoire avant que les données d'instance ne soient soumises.

Expression calculée : oui.

Valeurs légales : toute expression convertible en un type XPath boolean avec la fonction boolean().

Valeur implicite : false().

Règles d'héritage : ne s'hérite pas.

Un formulaire peut imposer certaines valeurs, et cette obligation peut être dynamique. Lorsqu'elle est évaluée à true, cette propriété d'élément de modèle indique qu'un nœud de donnée d'instance non vide est obligatoire avant que la soumission des données d'instance puisse intervenir. On définit un nœud non vide ainsi :

  1. Si le nœud de donnée d'instance est un élément, alors la valeur de son attribut xsi:nil ne doit pas être fixée à true ;

  2. La valeur du nœud de donnée d'instance lié doit être convertible en un type XPath string avec une longueur supérieur à zéro.

Sauf indiqué ci-dessous, la propriété d'élément de modèle required ne fournit aucune indication à l'interface d'utilisateur XForms en ce qui concerne la visibilité, le focus ou l'ordre de navigation. Les auteurs XForms sont fortement encouragés de s'assurer que les commandes de formulaire acceptant des données required soient visibles. Un processeur XForms peut fournir une indication selon laquelle une commande de formulaire est obligatoire et peut en rendre compte immédiatement, y compris en limitant la navigation. Le chapitre 4 Le modèle de traitement contient des précisions sur les moyens dont dispose le processeur XForms pour faire respecter des valeurs obligatoires.

Exemple : Joindre une propriété required
<instance>
  <my:nom-personne>
    <my:prenom>Roland</my:prenom>
    <my:nom />
  </my:nom-personne>
</instance>
<bind nodeset="/my:nom-personne/my:nom" required="true()"/>

Nous avons associé ici une propriété required à un élément my:nom pour indiquer qu'une valeur doit être fournie.

Remarque :

Le schéma XML possède un concept nommé de manière similaire : use="required|optional|prohibited". Il diffère de deux façons de la propriété d'élément de modèle XForms : premièrement, use ne s'applique qu'aux attributs, tandis que le required de XForms s'applique à n'importe quel nœud et, deuxièmement, use concerne le fait selon lequel l'attribut entier doit être défini (sans tenir compte de la valeur), tandis que required détermine si le nœud doit fournir une valeur avant la soumission.

6.1.4 La propriété relevant

Description : indique si l'élément de modèle est couramment pertinent. Les nœuds de donnée d'instance ayant cette propriété évaluée à "false" ne sont pas sérialisés pour la soumission.

Expression calculée : oui.

Valeurs légales : toute expression convertible en un type XPath boolean avec la fonction boolean().

Valeur implicite : true().

Règles d'héritage : si un nœud ancêtre est évalué à "false" pour XPath, alors cette valeur est traitée comme "false". Sinon, la valeur locale est utilisée.

Remarque :

Cela équivaut à prendre le ET logique de la propriété relevant évaluée du nœud local et de tous les nœuds ancêtres.

Beaucoup de formulaires ont des sections d'entrée de donnée qui dépendent d'autres conditions. Par exemple, un formulaire pourrait demander à l'interlocuteur s'il possède une voiture : lui demander d'autres renseignements sur sa voiture n'est approprié que s'il a indiqué en posséder une.

La propriété d'élément de modèle relevant fournit à l'interface d'utilisateur XForms des indications concernant la visibilité, le focus et l'ordre de navigation. En général, lorsqu'elle a la valeur "true", les commandes de formulaires associées devraient être rendues visibles. Inversement, pour la valeur "false", les commandes de formulaire associées (et tous les sous-éléments) et les éléments group et switch (et leurs contenus) devraient être rendues indisponibles, retirées de l'ordre de navigation et ne pas pouvoir recevoir le focus.

Remarque :

Une commande de formulaire, un élément group ou un élément switch doivent exprimer une seule liaison de nœud pour être associés à un nœud d'instance.

Exemple : Joindre une propriété relevant
<instance>
  <my:commande>
    <my:article>
      <my:montant />
      <my:rabais>100</my:rabais>
    </my:article>
  </my:commande>
</instance>
<bind nodeset="my:article/my:rabais" readonly="true()"
      relevant="../my:montant &gt; 1000"/>

Nous avons associé ici une propriété relevant à un élément my:rabais pour indiquer qu'un rabais est pertinent lorsque le montant de la commande est supérieur à 1000.

Le tableau suivant montre l'interaction d'interface d'utilisateur entre les propriétés required et relevant.

required="true()" required="false()"
relevant="true()" La commande de formulaire (et ses sous-ensembles) doit être visible ou disponible pour l'utilisateur. L'interface d'utilisateur XForms peut indiquer qu'une valeur est obligatoire. La commande de formulaire (et ses sous-ensembles) doit être visible ou disponible pour l'utilisateur. L'interface d'utilisateur XForms peut indiquer qu'une valeur est optionnelle.
relevant="false()" La commande de formulaire (et ses sous-ensembles) doit être cachée ou indisponible pour l'utilisateur. L'entrée d'une valeur et l'obtention du focus devraient être interdits. L'interface d'utilisateur XForms peut indiquer, si la commande de formulaire devenait pertinente, qu'une valeur sera demandée. La commande de formulaire (et ses sous-ensembles) doit être cachée ou indisponible pour l'utilisateur. L'entrée d'une valeur et l'obtention du focus devraient être interdits.

6.1.5 La propriété calculate

Description : fournit une expression servant à calculer la valeur du nœud de donnée d'instance associé.

Expression calculée : oui.

Valeurs légales : toute expression XPath.

Valeur implicite : aucune.

Règles d'héritage : ne s'hérite pas.

Un modèle XForms peut contenir des éléments de modèle qui sont calculés à partir d'autres valeurs. Par exemple, la somme des articles sur une ligne pour la quantité fois le prix unitaire, ou le montant des taxes à payer sur une commande. On peut exprimer une telle valeur calculée comme une expression calculée en se servant des valeurs d'autres éléments de modèle. Le chapitre 4 Le modèle de traitement contient des précisions sur le moment et la manière dont le calcul s'effectue.

Exemple : Joindre une propriété calculate
<instance>
  <my:commande>
    <my:article>
      <my:montant />
      <my:rabais />
    </my:article>
  </my:commande>
</instance>
<bind nodeset="my:article/my:rabais" calculate="../my:montant * 0.1"
      relevant="../my:montant &gt; 1000"/>

Nous avons associé ici une propriété relevant à l'élément my:rabais pour indiquer qu'un rabais de 10% est pertinent lorsque le montant de la commande est supérieur à 1000.

6.1.6 La propriété constraint

Description : définit un prédicat à satisfaire pour que le nœud de donnée d'instance associé soit considéré valide.

Expression calculée : oui.

Valeurs légales : toute expression convertible en un type XPath boolean avec la fonction boolean().

Valeur implicite : true().

Règles d'héritage : ne s'hérite pas.

Lorsque l'évaluation XPath donne "false", l'élément de modèle associé n'est pas valide ; l'inverse n'est pas nécessairement vrai. Le chapitre 4 Le modèle de traitement contient des précisions sur le moment et la manière dont la contrainte se calcule ainsi que le moment où la validation s'effectue.

Exemple : Joindre une propriété constraint
<instance>
  <my:intervalle>
    <my:depuis />
    <my:jusque />
  </my:intervalle>
</instance>
<bind nodeset="my:jusque" constraint=". &gt; ../my:depuis" />

Ici, une propriété constraint associée à l'élément my:jusque indique que la valeur de celui-ci doit être supérieure à celle de l'élément my:depuis.

Remarque :

On peut obtenir un minimum et un maximum d'occurrences pour les nœuds dans les données d'instance en se servant de la fonction count() dans une propriété constraint.

6.1.7 La propriété p3ptype

Description : joint un élément de donnée P3P à un nœud de donnée d'instance, en indiquant le type de donnée particulier collecté là-bas.

Expression calculée : non.

Valeurs légales : xsd:string.

Valeur implicite : aucune.

Règles d'héritage : ne s'hérite pas.

Cette propriété d'élément de modèle contient une description du type de donnée collecté par le nœud de donnée d'instance associé, fondée sur le système de type de donnée P3P [P3P 1.0]. Ces informations peuvent servir à améliorer la session de remplissage du formulaire en fournissant, par exemple, des données connues au préalable.

Exemple : Joindre une contrainte de type en utilisant une liaison
<instance>
  <my:nom-personne>
    <my:prenom />
    <my:nom />
  </my:nom-personne>
</instance>
<bind type="my:chaineNonVide" nodeset="my:prenom"
      p3ptype="user.personname.given"
      p3ptype="user.name.given"/>

Ici nous avons joint des informations concernant à la fois le schéma XML et le type P3P à l'élément my:prenom via un élément bind.

6.2 Les contraintes du schéma

Le chapitre 5 Les types de données décrivait la manière dont XForms utilise le système de type de donnée du schéma XML pour contraindre l'espace de valeurs des valeurs de données collectée par un modèle XForms. On peut fournir de telles contraintes de type de donnné via un schéma XML. Alternativement, cette section liste divers mécanismes pour adjoindre des contraintes de type aux données d'instance. Les attributs xsi:schemaLocation et xsi:noNamespaceSchemaLocation, pour la localisation des schémas, sont volontairement ignorés.

6.2.1 Le type de donnée atomique

Le modèle de traitement XForms applique les facettes du schéma XML au cours du processus de validation. Au niveau le plus simple, il est nécessaire d'associer un ensemble de facettes (au travers d'un type de donnée du schéma XML) à un élément de modèle. Cela a pour effet de restreindre les valeurs admissibles du nœud de donnée d'instance associé aux représentations valides de l'espace lexical du type de donnée.

L'ensemble des facettes associé à un élément de modèle doit être déterminé par la liste suivante, comme si elle était traitée dans l'ordre donné. Lorsque plusieurs restrictions de type de donnée s'appliquent au même élément de modèle, la combinaison de toutes les restrictions en question doivent s'appliquer. Remarquez que l'on peut produire une combinaison de restrictions qui soit impossible à satisfaire ; on décourage aux auteurs cette pratique.

  1. Un schéma XML associé aux données d'instance ;

  2. Un attribut du schéma XML xsi:type dans les données d'instance ;

  3. Une contrainte XForms type associée au nœud de donnée d'instance au moyen d'une liaison XForms ;

  4. Si aucune contrainte de type n'est fournie, le nœud de donnée d'instance a implicitement type="xsd:string" (par défaut vers une règle de chaîne).

L'exemple suivant déclare un type de donnée basé sur le type xsd:string avec une contrainte de facette supplémentaire.

Exemple : Contrainte de type utilisant le schéma XML
<xsd:simpleType name="chaineNonVide">
  <xsd:restriction base="xsd:string">
    <xsd:minLength value="1"/>
  </xsd:restriction>
</xsd:simpleType>

Ce nouveau type de donnée pourrait alors être associé à un ou plusieurs éléments de modèle au travers de l'une des méthodes soulignées ici.

Exemple : Joindre une contrainte de type
<my:prenom xsi:type="my:chaineNonVide"/>

L'élément my:prenom est défini comme étant de type my:chaineNonVide.

Exemple : Joindre une contrainte de type en utilisant une liaison XForms
<instance>
  <my:prenom />
</instance>
<bind type="my:chaineNonVide" nodeset="/my:prenom"/>

Ici, nous avons joint une information de type à l'élément my:prenom via un élément bind. L'auteur XForms peut ainsi étendre des schémas externes alors qu'il n'a pas la possibilité de les changer.