5. Problèmes rencontrés

5.1 Jeux de caractères

L’une des principales caractéristiques du balisage XML est sa portabilité. Les documents XML peuvent ainsi contenir n’importe quel caractère Unicode, à l’exception des caractères de contrôle. Malheureusement, de nombreuses bases de données ne proposent pas d’aide, ou qu’une assistance limitée, pour Unicode et exigent une configuration spéciale pour utiliser les caractères non conformes au code ASCII. Si vos données contiennent des caractères qui ne sont pas conformes au code ASCII, vérifiez que votre base de données et votre logiciel de transfert acceptent ces caractères et la manière dont ils sont gérés. Il est indispensable de contrôler soigneusement comment la base de données (ou le système à partir duquel sont extraites les données) gère et manipule le codage.

Étant donné que les documents XML doivent être codés en UTF-8 (de préférence), il est possible d’utiliser d’autres schémas de codage, tel ISO-8859-1, à condition que ces schémas soient clairement indiqués dans la déclaration de l’en-tête XML de début afin qu’ils soient reconnus et représentés correctement dans le service d’archivage XML central d’AGRIS.

5.2 Références d’entités prédéfinies

XML prédéfinit les cinq références d’entités ci-dessous. Ces références sont utilisées dans les documents XML pour remplacer certains caractères qui seraient autrement interprétés comme une partie du langage de balisage.

5.3 Espace blanc

Quatre caractères sont traités comme des espaces blancs dans les données XML: la tabulation horizontale, le changement de ligne, le retour à la ligne et le caractère espace ASCII. Aucun d’entre eux ne doit apparaître dans une même balise XML. La frappe de la saisie doit être identique à ce qui doit apparaître dans la base de donnée web AGRIS. Il faut donc éviter les deux situations suivantes:

5.4 Eléments répétables

Les éléments répétables ou qualificatifs doivent tous avoir des balises multiples.

L’exemple suivant n’est pas acceptable:

Le codage correct est le suivant:

5.5 Taille des documents XML

Il faut éviter de créer et d’envoyer des documents XML volumineux. Si la taille des fichiers dépasse 500Kb, il faut les découper en deux fichiers ou plus. Lorsque l’on découpe un fichier, il ne faut pas oublier de mettre les en-têtes corrects dans les fichiers créés (voir 4.1). Pour manipuler des documents XML dans de grands services d’archivage, il vaut mieux découper chaque ressource XML dans chaque document.

5.6 Schéma pour xml:lang

L’attribut xml:lang procure aux auteurs XML un moyen cohérent d’identifier le langage d’un document donné. Le PA AGRIS se sert de cet attribut pour des éléments dont on considère qu’il est nécessaire de connaître le langage de contenu. Cette extensibilité permet également des valeurs multiples de l’élément spécifié en différents langages. Utilisez le schéma ISO639-2 (code à 3 lettres) pour l’attribut xml:lang.

5.7 Balises d’éléments vides

Les balises sans éléments, de sous-éléments ou d’attributs doivent être présentes sans contenu. Lors de la mise en correspondance de la structure de la base de données avec un document XML, il faut vérifier que les types d’éléments optionnels et les attributs correspondent à des colonnes annulables (c'est-à-dire à des champs permettant des valeurs nulles) et réciproquement. Si l’on ne suit pas cette procédure, on risque de produire des documents invalides (lors du transfert de données depuis la base de données) et de créer des éléments ou des qualificatifs vides indésirables.

5.8 Balises obligatoires

Malgré la flexibilité du schéma DTD, il faut respecter certaines règles pour obtenir un document XML valide. Certains éléments, qualificatifs et schémas obligatoires doivent être insérés dans les balises. Les documents valides doivent ainsi contenir au moins les cinq éléments fondamentaux suivants pour chaque ags:resource:

• <dc:title>
• <dc:date>
• <dc:subject>
• <dc:language>
• <agls:availability>

5.9 Incohérence entre métadonnées locales et éléments du PA AGRIS

Les systèmes locaux contiennent souvent des champs particuliers qui répondent aux exigences locales, mais qui n’ont pas d’élément correspondant dans la structure de métadonnées définie par le PA AGRIS. Lors du processus de configuration et de conversion, ces métadonnées ne doivent pas être prises en compte. La présente version de métadonnées PA AGRIS est flexible et permet d’accepter différents types d’informations. Il sera sans doute possible d’envisager d’ajouter des qualificatifs ou des schémas essentiels dans les versions ultérieures.

5.10 Imbrication, principe du ‘dumb-down’ et conformité au DC

La série de métadonnées du Dublin n’est pas totalement adaptée à la description des ressources et, dans certains cas, l’élément DC a été qualifié pour les besoins des ressources AGRIS.

La qualification des éléments du Dublin Core est fondée sur une règle que l’on appelle familièrement le principe du ‘dumb-down’. D’après cette règle, tout qualificatif doit pouvoir être ignoré et ce, sans que la valeur ne perde son sens. Bien que cela entraîne une certaine perte de spécificité, la partie restante de la valeur du terme (moins le qualificatif) doit conserver sa validité globale et son utilité pour la recherche. On suppose donc que la qualification doit raffiner un élément et non pour en changer la portée sémantique.

Les raffinements d’élément (qualificatifs) partagent la signification de l’élément non qualifié, mais avec une portée plus restreinte. Lorsque cela est nécessaire ces qualificatifs sont ’ignorés’ ” en éléments Dublin Core par des imbrications pour respecter la conformité au DC. L’exemple suivant ignore ags:publisherPlace et ags:publisherName dans l’élément fondamental dc:publisher. De cette manière, le raffinement d’élément es ignoré et la valeur utilisée comme contenu de l’élément fondamental non qualifié est dc:publisher.