SUPANN définit une syntaxe d'attributs, dite attribut étiqueté, dont les valeurs sont constituées chacune d'une étiquette et d'une valeur.
L'étiquette identifie la nomenclature utilisée pour la valeur qui suit.
Cette syntaxe permet de faire co-exister dans le même attribut des valeurs issues de nomenclatures ou provenances différentes sans risques de collisions.
Remarques:
Une valeur d'attribut étiqueté obéit à la syntaxe suivante:
{ETIQUETTE}valeur
Il n'y a pas d'espaces entre ces éléments.
{UAI:0751717J:ETUID}
désigne un identifiant étudiant (ETUID) localement défini dans l'établissement de code 0751717J issu de la nomenclature UAI.Les contraintes sont celles du type d'attribut utilisé, à l'exception des caractères “{” et “}” qui sont interdits.
Chaque type d'attribut défini comme “étiqueté” a ses propres règles définissant les étiquettes autorisées. Trois cas sont possibles:
Lorsque l'ajout d'étiquettes locales est autorisé (cas “semi-ouvert” ou “ouvert”), celles-ci DOIVENT être identifiées par l'ajout d'un préfixe hiérarchique basé sur le code de l'établissement, pour en indiquer la provenance.
Exemple: l'étiquette locale “ACTIVITE” définie par l'université Paris 1 (Code UAI: 0751717J) sera libellée :
{UAI:0751717J:ACTIVITE}
Cet autre exemple montre une étiquette définie par un établissement ou un prestataire défini par son SIRET:
{SIRET:48264601500016:BDGTYPE}
Lorsque cela ne génère pas d’ambiguïtés, si l'établissement considère qu'il n'a qu'une seule nomenclature interne pour un attribut donné, il peut aussi utiliser son code établissement seul comme étiquette pour l'identifier; par exemple:
{UAI:0751717J}
Attention, les étiquettes locales ne sont pas exploitables dans un cadre inter-établissement (fédération d'identités par exemple), à moins d'établir des conventions bilatérales entre fournisseurs de services et d'identités.
Cependant, si cette étiquette identifie une nomenclature potentiellement partagée (par exemple, définie au niveau national, ou dans une application mutualisée), celle-ci peut être proposée au groupe de travail SUPANN pour normalisation : voir Évolution des recommandations.
Dans ce cas l'étiquette et la valeur sont traitées comme un tout indissociable. La recherche et la comparaison s'effectuent en égalité.
Exemple de filtre LDAP :
(attributEtiquete={ETIQ1}valeur1)
Indexation: une indexation en égalité (“eq”) est en général suffisante pour cet usage.
Dans ce cas, on s'intéresse exclusivement aux valeurs précédées d'une étiquette particulière, les autres étiquettes devant être ignorées.
Exemple de fitre LDAP isolant les entrées possédant l'étiquette souhaitée:
(attributEtiquete={ETIQ1}*)
Un traitement des valeurs lues est nécessaire pour en retirer l'étiquette.
Exemple via une expression rationnelle Perl :
$valeur =~ s/^\{ETIQ1\}//i
Si l'attribut est multi-valué, il peut aussi être nécessaire d'exclure les valeurs qui ne comportent pas l'étiquette recherchée. Cela peut se faire de deux manières:
foreach ($entry->get_value("AttributComposite")) { /^\{ETIQ1\}(.*)$/ and push @valeurs, $1 }
Indexation: pour cet usage, une indexation en égalité (“eq”) et sous-chaîne initiale (“subinitial”) est recommandée. Celle-ci permet de filtrer les valeurs selon leur étiquette.
Les attributs SUPANN suivants font appel à des valeurs étiquetées :