Discussion:XIMF XML tags/fr
- Combien d'éléments ihm sont autorisés dans un élément instance ?
Un seul élément ihm est chargé par instance, il permet de générer la grille des entêtes XIMF en rédaction et lecture de message
- La documentation des fichiers ximfmail-profile.xml n'est pas disponible.
Quel type de documentation (wiki adullact ou .doc) est attendu?
- Quel est le rôle de l'élément "acces" ?
je ne vois pas où j'ai utilisé un élément acces dans un fichier ximfmail-profile.xml
- Quelle est l'utilité des identifiants associés aux éléments instance, shema, ihm, etc.
Les attributs id ne sont pas exploités par le moteur XIMFMAIL sauf l'instance dont l'id "id=smtp". Celui-ci est utilisé par le moteur pour gérer un message smtp standard.
- Quelle est l'utilité de l'attribut name associé aux éléments instance. Y a-t-il une vérification s'assurant que les fichiers utilisés par une instance correspondent bien à l'instance à laquelle ils sont associés ?
l'attribut name est un des attributs permettant de discréminer les instances. Il est effectivement utilisé par le moteur pour afficher, composer les messages d'un compte
- Quel est l'intérêt de renseigner un attribut "id" à l'élément "dictionary" (étant donné qu'un seul élément "dictionary est autorisé dans l'élément "instance") ?
cet attribut n'est effectivement pas obligatoire
- Il semble que les fichiers headers définissent des champs d'entête devant être envoyés alors que ces mêmes entêtes ne sont pas spécifiés dans le fichier ihm. Ce comportement est logique, en effet, l'utilisateur n'a pas forcément besoin de savoir tout ce qui est envoyé via le formulaire.
Comment intégrer un header (nommé aussi header technique) dans le message sans qu'il soit affiché dans le formulaire XIMF de l'IHM ?
Par exemple, dans l'instance Amoco, le champ d'entête X-XIMF-Security-Policy-Identifier est automatiquement envoyé alors que les champs d'entête X-XIMF-Primary-Precedence et X-XIMF-Copy-Precedence ne le sont pas. Comment est faite la différence ?
Si un élément ximf:header ne contient pas d'attribut "ilk" et propose un choix unique de valeur (l’élément fils est ximf:string), alors le moteur "déduit" qu'il s'agit d'une valeur technique à envoyer sans la présenter à l'utilisateur.
- Comment est effectuée la vérification de l'attribut isMandatory et quelles sont les conditions de fonctionnement de celui-ci ? Est-il possible, par exemple, de spécifier l'attribut isMandatory=true d'un élément header si le contenu de celui-ci est un élément « set » qui dispose des attributs minItem et maxItem ? Actuellement, lorsque l'on crée un élément set avec les attributs minItem et maxItem, le champ du formulaire associé ne peux pas être validé : e.g.,
<ximf:set id="value-amoco-classification" minItem="1" maxItem="64" separator=";" technicalSeparator=".">
- Quelles sont les contraintes associées à l'attribut type d'un élément header ?
- L'attribut type d'un élément "ximf:header" ne contraint pas les éléments fils associés.
- L'attribut de l'élément « compstring » nommé « contentFactorise » devrait s'appeler « contentFactorize ».
ok
- Y a-t-il une définition des fichiers associés aux instances XIMF (e.g, le fichier attribution-list.xml utilisé dans l'instance Caterpillar) ?
non mais la structure du fichier xml doit être celle donnée en exemple
- Comment le moteur XIMF sait qu'un élément est une "attribution-list" ?
Si un élément "set" contient un attribut "ref" dont la valeur ne permet pas de trouver l'élément associé dans l'instance alors le moteur Ximfmail inspecte le répertoire local où est stocké l'instance et vérifie si le nom d'un fichier xml correspond à la valeur de cet attribut.
- Les éléments autorisés dans un élément « rule » ne sont plus à jour. La présente documentation spécifie 12 éléments : AliasHeader, AliasValue, Compatibility, Association, SecureHeaders, SecurityLabel, Constraint, Assignment, Processing, Accessibility, Role et Custom. Le schéma XML fourni avec le mail en spécifie 5 : Constraint, Processing, Compatibility, Policy et Custom et place les autres en tant qu'extentions des 5 éléments cités précédemment.
ok
- Les éléments SecureHeaders et SecurityLabel associés à l'élément « rule » ne figurent pas dans la nouvelle version du shéma xml. On les retrouve dans les fichiers rules-*.xml mais les éléments sont commentés, ils sont, de plus, présents dans une autre instance : comment ces éléments sont utilisés dans Trustedbird ?
Ces règles ont été créées après la rédaction du document pour répondre à des besoins spécifiques. Les deux éléments permettent de forcer l'utilisation des mécanismes de sécurité associés. Je les ai commenté car leur utilisation nécessite l'import de certificats et l'extension étant un exemple, je n'ai pas voulu bloquer les interfaces des utilisateurs ne disposant pas de certificats.
- L'élément ximf:classificationPictures n'est pas documenté. De plus, il serait bon d'avoir des précisions sur la raison qui a motivé l'ajout de cet élément dans les fichiers de règles (alors qu'il semblerait être plus adapté au fichier headers-*.xml).
Un fichier header-*.xml décrit les noms et valeurs d'entêtes XIMF de messages. L'élément ximf:classificationPictures est un moyen d'associer à une valeur d'entête une image. Il m'a donc semblé qu'afficher une image dépend plus d'une règle de gestion de message que de description d'entête de message.
- Comment sont gérées les règles associées aux champs multivaleurs (disposant par exemple des attributs minItem/maxItem ou les champs multiset) ?
- L'élément assignment n'apparaît pas dans le shéma xml qui avait été envoyé.
- L'attribut valueRef est-il obligatoire ?
Oui, un élément ximf:aliasValue permet d'associer une valeur définie par l'attribut valuRef à une autre valeur définie par l'attribut valueName. Par contre, l'élément aliasValue n'est pas obligatoire.
- L'élément refHeader n'est pas documenté, s'agit-il en fait de l'élément headerRef ?
- L'élément accessibility n'apparaît pas dans le shéma xml qui avait été envoyé.
