Présents : Mireille, André, François, Brice, Cyril, Grégory

Objet : Contraintes: syntaxe et exemples

Points abordés:

• Syntaxe en vigueur jusqu'a cette reunion

• Identification d'un axe

• Gestion du 'unknown'

• Details syntaxiques

• Application de la syntaxe aux exemples de contraintes donnees le 9/11

Syntaxe en vigueur jusqu'a cette reunion

Jusqu'a maintenant les contraintes suivaient la syntaxe suivante:

(| signifie ou; * signifie 0 ou plusieurs occurences; + signifie 1 ou plusieurs occurences; [] sont utilises pour un element facultatif)

(Exemples)

Identification d'un axe

Jusqu'a present, dans la syntaxe, un axe etait identifie par la valeur de son UCD. En realite, il est tout a fait possible que ce champs soit mal ou pas renseigne, rendant impossible l'application des contraintes. Par exemple, un axe dit "observable" pourrait etre identifie a coup sur par le fait qu'il s'agit d'un axe dont le champs independantAxis egal a false. Ainsi, un axe ne peut etre identifie que par un ensemble de contraintes.

Par consequent, il faut changer la syntaxe courante. Dans la syntaxe de {ensProperty} et de {singleProperty}, il faut remplacer ucd par Charac[{logicOperation}] (ou {logicOperation} est une contrainte simple du genre "ucd='pos'" ou un ensemble de contraintes concatenees par des AND ou OR).

Exemple: au lieu de: 1:pos.numBins, on aurrait: 1:Charac[ucd="pos"].numBins.

Neanmoins, cette syntaxe peut rendre la lecture et/ou l'ecriture des contraintes assez difficile: s'il faut au moins 3 contraintes pour identifier un axe, et qu'il y a plusieurs contraintes (voir toutes) a ecrire sur cette axe, leur ecriture risque de s'averer longue et repetitive (compensee par le copier/coller) tandis que la lecture risque d'etre beaucoup plus difficile. C'est pourquoi, il pourrait etre utile de definir des alias pour les axes les plus utilises. Ces alias peuvent etre definis a deux niveaux: au niveau des UTypes (pour les axes les plus courants) et au niveau du fichier de contraintes (pour les moins courants en general mais surtout pour les plus utilises dans CE fichier de contraintes).

Les alias definis au niveau de la definition des UTypes devront etre remplaces par la syntaxe Charac[{logicOperation}] juste avant que le fichier ne soit interprete par Aida.

Les alias definis dans le fichier de contraintes sont definis par la personne qui redige les contraintes de ce fichier, et ne peuvent etre utilises que dans ce fichier. C'est comme une variable locale ou un "define" (en C).

Gestion du 'unknown'

Il est possible que certaines proprietes/meta-donnees d'un fichier Characterisation ne soient pas renseignees bien qu'obligatoires ! Dans ce cas, l'utilisateur mettra la valeur 'unknown'.

Du point de vue de l'evaluation des contraintes, les contraintes qui portent sur une propriete dont la valeur est 'unknown' ne devraient pas etre evaluees (et dans ce cas, on passe a la contrainte suivante sans relever l'erreur) ou alors elles devraient stoper la validation des contraintes (toutes les contraintes suivantes ne seront pas evaluees). Pour le moment, on passe a la contrainte suivante mais une erreur de validation est affichee.

Par consequent, il faudrait que le traitement par defaut de cette valeur particuliere soit de passer a la suivante sans envoyer de message d'erreur. Neanmoins, si l'utilisateur juge cette valeur comme problematique pour la validation des contraintes suivantes, il doit avoir la possibilite de stoper la validation du fichier de contraintes. Pour cela, on peut envisager 2 manieres (non exclusives) de realiser ceci: soit un mot clef ( STOP_AT_UNKNOWN({logicOperation}) ) soit un bloc STOP_AT_UNKNOWN dont chaque contrainte serait susceptible de stoper la validation du bloc si la valeur 'unknown' est rencontree.

On pourrait egalement ajouter une valeur particuliere a la syntaxe courante: la valeur UNKNOWN. Ainsi, l'utilisateur pourrait faire une contrainte qui imposerait qu'une propriete est soit differente de 'unknown soit egale a 'unknown'.

Details syntaxiques

NEAR:

Le deuxieme parametre de la contrainte NEAR doit etre une valeur absolue (difference maximale) et non relative aux valeurs comparees.

WARNING:

L'inconvenient de la syntaxe actuelle de la contrainte WARNING est qu'elle impose que la contrainte a verifiee soit un de ses parametres. Si la contrainte est longue et/ou complexe, la lecture, tout comme l'ecriture, de la contrainte WARNING peut etre difficile.

C'est pourquoi, il serait mieux de changer la syntaxe de WARNING. Au lieu de deux parametres, il n'y en aurait qu'un seul: le message a afficher si la contrainte n'est pas verifiee. Cette derniere contrainte serait la condition d'un IF. Ainsi, un WARNING ne pourrait etre utilise que juste apres la ligne IF (condition).

Exemple: Au lieu de WARNING(EXISTS("3"), "L'entree 3 n'existe pas !"), on aurait: IF (EXISTS("3")) WARNING("L'entree 3 n'existe pas !") FI

Application de la syntaxe aux exemples de contraintes donnees le 9/11

Rapport de test de ces contraintes

Remarque: Certains mots (n'appartenant pas a la syntaxe des contraintes) sont en italiques car:

• il s'agit de l'alias d'un axe
• une valeur numerique ou chaine de caracteres quelconque
• s'il se termine par un '?', j'ignore a quoi il correspond.

1. Verifier que tous les Ik ont une resolution spatiale proche et exprimee dans la meme unite:

2. Verifier que les tailles sont identiques:

3. Verifier que les images sont superposables:

4. Observables: (min-max)>=100 sinon WARNING:

5. ...

MASK: Verifier que le mask est donne en entree:

MASK 1.Observable Axis: min=0, max=1:

MASK 2.SpatialAxis: numBins = numBins INPUT image (Meme taille):

Output: