Céline CAPRON Laurent FALLET. Implémentation XML de la norme ISO 11179-3

Céline CAPRON Laurent FALLET Implémentation XML de la norme ISO 11179-3 Janvier 2004

Table des matières 1 Introduction 3 2 XML Schema 5 2.1 Introduction....................................... 5 2.2 Différences entre DTD et XSD............................. 5 2.3 Syntaxe......................................... 6 2.4 Types.......................................... 9 2.4.1 Dérivation par restriction............................ 10 2.4.2 Dérivation par liste............................... 11 2.4.3 Dérivation par union.............................. 12 2.5 Exemple concret.................................... 12 2.6 Utilisation pratique des XSD.............................. 15 2.6.1 Liens entre XML et XSD............................ 15 2.6.2 Organisation physique des fichiers XSD.................... 16 2.7 Outils.......................................... 17 2.7.1 Editeur de XSD................................. 17 2.7.2 Validateur.................................... 17 3 La Norme ISO 11179-3 18 3.1 Présentation....................................... 18 3.1.1 ISO, AFNOR et IEC.............................. 18 3.1.2 But de la norme ISO/IEC 11179........................ 18 3.2 Structure du modèle conceptuel............................. 18 3.2.1 Le domaine conceptuel (Conceptual Domain)................. 19 1

ISO 11179-3 TABLE DES MATIÈRES 3.2.2 Domaine de valeurs............................... 19 3.3 Exemples d application de la norme.......................... 20 3.3.1 ISO 3166.................................... 20 3.3.2 ISO 6709.................................... 22 4 Travail réalisé 24 4.1 Choix du XML..................................... 24 4.2 Processus de transformation mis en place....................... 25 4.2.1 Technologies à disposition........................... 25 4.2.2 Schéma des transformations.......................... 26 4.2.3 Problème(s) rencontré(s)............................ 28 4.3 Perspectives techniques................................. 31 5 Conclusion 33 6 Bibliographie 34 7 Annexes 36 7.1 Répartition du travail.................................. 36 7.2 Diagrammes....................................... 37 7.3 Contenu du CD..................................... 38 2

1 Introduction Le sujet de l étude suivante peut être défini ainsi : "La norme ISO 11179 définit un cadre de développement de spécification de métadonnées (données sur des données). La troisième partie de cette norme 1 propose un modèle objet de cette spécification. L objectif de ce projet est d implémenter ce modèle en XML." Les technologies de l information sont en plein essor, avec un objectif majeur : décorréler le contenu d un document de son support. Pour connaître le support d un document, il suffit de se référencer aux métadonnées. Cependant il existe plusieurs normes sur les métadonnées de part le monde. Par exemple, dans le domaine des documents pédagogiques, il existe la MLR "Metadata for Learning Resources". Le MLR est le domaine conceptuel de la norme ISO 11179. La MLR possède plusieurs instanciations : la LOM ("Learning Object Metadata" 2 ), l IMS ("Instructional Management Systems"), le Dublin Core 3, MPE... tous ces standards se situent au niveau de la représentation. Le problème qui se pose est le suivant : comment serait-il possible de passer aisément d une représentation à une autre? Actuellement, passer de l une à l autre exige un traducteur. Or s il existe N normes différentes, il faut un traducteur pour chaque interaction, ce qui revient à N(N 1) traducteurs pour pouvoir passer d une représentation à n importe quelle autre. En effet il y a 2 transformations pour chaque couple (voir schéma). L objectif de la norme ISO 11179 est qu elle soit commune à toutes les représentations. Chaque représentation pourrait se situer par rapport à la norme, et créer un traducteur vers l ISO 11179, ainsi que son inverse. Cette dernière deviendrait l intermédiaire entre 2 représentations. Ce procédé permet de réduire le nombre de traducteurs nécessaires à 2N. La complexité est donc grandement réduite. FIG. 1 Intérêt d un traducteur commun entre diverses représentations 1 référence ISO/IEC 11179-3 :2003(E) 2 IEEE 1484.12.1 3 ISO 15836 3

ISO 11179-3 1 Introduction Notre travail a donc consisté à réaliser une ébauche de l application en XML de la partie 3 de la norme ISO 11179 (Registry metamodel and basic attributes). Le présent rapport est organisé comme suit : dans la première partie, nous exposerons les spécifications techniques du XML Schema, ses particularités et avantages. Dans une seconde partie, nous résumerons la partie de la norme qui nous concerne, puis les 2 exemples dont nous nous sommes servis. Enfin, dans la dernière partie, nous évoquerons le travail réalisé et les perspectives. 4

2 XML Schema 2.1 Introduction Le W3C XML Schema est un langage de définition de données écrit en XML, pour décrire et structurer le contenu des documents XML. XML Schema, aussi connu sous le nom de XSD, est le vocabulaire permettant d exprimer les règles de validation d un document XML. XML Schema est une recommandation de la W3C. Pour être valide, un document XML doit se conformer à un ensemble de contraintes. Voici un exemple de fichier XML : <lieu> <latitude>32.904237</latitude> <longitude>73.620290</longitude> <incertitude unite="metres">2</incertitude> </lieu> Les contraintes sur ces données sont : un lieu doit contenir une latitude, une longitude, et une incertitude latitude et longitude doivent être des réels à 6 décimales latitude a un intervalle de -90 à +90, longitude de -180 à +180 l incertitude doit être un entier non négatif l attribut unite ne peut contenir que les valeurs metres ou miles Ces contraintes peuvent être exprimées en utilisant des DTD (Document Type Definition), ou des XSD (XML Schema Definition). Il est possible de spécifier la structure d un document, aussi bien que le type de données de chaque élément ou attribut. XSD est un langage récent (publié par la W3C en mai 2001, après 2 ans de développement), donc bien plus évolué que les DTD. 2.2 Différences entre DTD et XSD Une des méthodes précédant le XML Schema pour la description de la structure des documents est la DTD. Voici quelques critères de comparaison : la syntaxe des DTD est spécifique, non XML (apprentissage nécessaire) ; les DTD ont une faible capacité de définition des types de données ; par exemple on ne peut pas spécifier une contrainte du type : "cet élément sera un entier dont la valeur sera comprise entre 0 et 12" ; les DTD supportent 10 types de données contre plus de 44 pour les XSD ; possibilité avec XML Schema de créer ses propres types de données ; 5

ISO 11179-3 2.3 Syntaxe XSD est orienté objet : possibilité d étendre ou restreindre un type (en dérivant d un autre type) ; XML Schema permet de spécifier un élément dont le contenu sera unique (clé), pour une région ou la totalité du document ; XSD a la possibilité de définir plusieurs éléments au même nom mais avec un contenu différent ; XML Schema supporte un contenu vide ; les XSD permettent de définir des éléments substituables ; Pour résumer : DTD non XML peu modulaire non typé XSD langage XML extrêmement modulaire typé Pour toutes ces raisons la technologie XSD a été choisie pour structurer les documents de notre projet. 2.3 Syntaxe Prenons pour commencer un document XML relativement simple : <?xml version="1.0" encoding="utf-8"?> <book isbn="0836217462"> <title>being a Dog Is a Full-Time Job</title> <author>charles M. Schulz</author> <character> <name>snoopy</name> <friend-of>peppermint Patty</friend-of> <since>1950-10-04</since> <qualification>extroverted beagle</qualification> </character> <character> <name>peppermint Patty</name> <since>1966-08-22</since> <qualification>bold, brash and tomboyish</qualification> </character> </book> Nous allons créer pas à pas le XSD, en suivant le document XML. Tout d abord ouvrons un élément schema, qui commence un schéma W3C XML Schema, permettant de définir l espace de nom cible : 6

ISO 11179-3 2.3 Syntaxe <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/xmlschema"> Il existe 2 catégories d éléments : les complextype, ayant des attributs et des sous-éléments, et les simpletype, réservés aux attributs et éléments sans sous-élément ou attribut et ne contenant donc que des valeurs. La liste des sous-éléments sera décrite à l intérieur d un élément sequence, qui définit une liste ordonnée d éléments : <xsd:element name="book"> <xsd:complextype> <xsd:sequence>... </xsd:sequence> </xsd:complextype> </xsd:element> A l intérieur de cette structure nous allons décrire les éléments "title" et "author" comme des types simples, puisqu ils n ont ni attribut ni sous-élément. Le type string que nous utilisons est préfixé par l espace de noms que nous avons choisi pour le schéma (xmlns:xsd="http://www.w3.org/2001/xmlschema") : <xsd:element name="title" type="xsd:string"/> <xsd:element name="author" type="xsd:string"/> A présent, nous rencontrons l élément "character" qui doit être considéré comme un type complexe. Nous allons déclarer sa cardinalité, à savoir qu il peut y en avoir autant qu on le désire : <xsd:element name="character" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:sequence> minoccurs est le nombre minimum d occurrences et maxoccurs le nombre maximum d occurrences. Ici, maxoccurs est déclaré "unbounded" c est à dire que l élément peut être répété autant de fois que l auteur du document xml le souhaite. Ces deux attributs ont une valeur égale à 1 par défaut. On déclare ensuite les éléments formant la séquence, en utilisant des types simples, dont le type date. Il faut ensuite refermer la séquence de "character" et de "book", puis déclarer l attribut "isbn" de "book" (on déclare toujours les attribut après les éléments) : 7

ISO 11179-3 2.3 Syntaxe <xsd:element name="since" type="xsd:date"/> <xsd:element name="qualification" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> </xsd:sequence> <xsd:attribute name="isbn" type="xsd:string"/> </xsd:complextype> </xsd:element> </xsd:schema> La définition des éléments et attributs à l endroit où ils vont être utilisés peut devenir lourde si le document est complexe. Il existe une autre méthode, plus proche des DTD, qui consiste à définir un catalogue d éléments et d attributs, puis à utiliser des références aux éléments et attributs prédéfinis : <!-- définition des éléments simpletype --> <xsd:element name="title" type="xsd:string"/> [...] <xsd:element name="qualification" type="xsd:string"/> <!-- définition des attributs --> <xsd:attribute name="isbn" type="xsd:string"/> <!-- définition des éléments complextype --> <xsd:element name="character"> <xsd:complextype> <xsd:sequence> <!-- les éléments simpletype sont référencés en utilisant l attribut "ref" --> <xsd:element ref="name"/> <!-- la cardinalité est définie quand l élément est référencé --> <xsd:element ref="friend-of" minoccurs="0" maxoccurs="unbounded"/> <xsd:element ref="since"/> <xsd:element ref="qualification"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="book"> <xsd:complextype> <xsd:sequence> <xsd:element ref="title"/> <xsd:element ref="author"/> <xsd:element ref="character" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute ref="isbn"/> </xsd:complextype> 8

ISO 11179-3 2.4 Types </xsd:element> </xsd:schema> Dans notre premier exemple, nous définissions localement les éléments et attributs, à l endroit où ils apparaissaient dans la structure du document. Les éléments définis localement ne peuvent pas être utilisés comme élément racine du document XML. De plus les éléments et attributs locaux ne peuvent être réutilisés ailleurs dans le schéma qu à l endroit défini. Les éléments définis globalement, comme dans l exemple ci-dessus, permettent d utiliser "character" comme élément racine, et de réutiliser les définitions dans d autres types, où à d autres feuilles de l arbre. Le choix à réaliser entre les 2 méthodes varie selon que l on favorise la souplesse ou la profondeur du XSD. 2.4 Types Nous avons vu qu il existe des types simples et des types complexes. Les types simples représentent les feuilles de l arbre, et les types complexes sa structure. Un type peut être considéré comme une classe, ses éléments et attributs étant des objets, instances de cette classe. Il existe environ 44 types prédéfinis. Il y a quelques types de départ, appelés types primitifs, qui permettent d obtenir les autres types. Ci-dessous une petite description xs :string : chaîne de caractères, similaire à xs :normalizedstring et xs :token. Les différences résident dans la gestion des séparateurs dits "blancs" (espace, tabulation, retour chariot... ) xs :language : spéficie le code de langue, par exemple en, en-us, fr ou encore fr-fr. xs :ID : valeur unique sur l ensemble du document xs :IDREF : valeur d un ID se trouvant dans le document xs :ENTITY : valeur qui correspond à celle d une entité externe déclarée dans une DTD xs :hexbinary, xs :base64binary : différents codages xs :decimal : ensemble des nombres décimaux xs :integer : entier sans limite de taille, qui a les types dérivés xs :nonpositiveinteger, xs :positiveinteger, xs :negativeinteger... xs :long, xs :int, xs :short, xs :byte : entiers sur 64, 32, 16 ou 8 bits. Il existe la même chose en xs :unsignedlong, xs :unsignedint... xs :float, xs :double, xs :boolean, xs :datetime, xs :date, xs :gyear, xs :time, xs :duration... xs :NMTOKENS, xs :IDREFS, xs :ENTITIES : listes d items délimités par des séparateurs Voici une architecture des types de base : 9

ISO 11179-3 2.4 Types FIG. 2 Graphe de hiérarchie des types de données prédéfinis Il est possible d obtenir de nouveaux types par dérivation des types simples. Il existe 3 types de dérivations : la dérivation par restriction, par liste ou par union. La dérivation par restriction est la plus communément utilisée. 2.4.1 Dérivation par restriction La dérivation par restriction est faite en appliquant des facettes sur un type de base dont le type dérivé conserve la sémantique. Les facettes sont des contraintes élémentaires dont la nature et les conséquences dépendent du type de base. Plus simplement, les types sont créés en ajoutant de nouvelles contraintes aux valeurs initialement autorisées. 10

ISO 11179-3 2.4 Types Voici un exemple de dérivation par restriction : le type de base, un string, est restreint à une chaîne de 5 caractères numériques, grâce à un pattern : <xs:simpletype name="typecodepostal"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{5}"/> </xs:restriction> </xs:simpletype> Il existe 3 types de facettes : facette xs:whitespace, qui gère le séparateur espace pour les types string et normalized- String ; facette xs:pattern, qui s applique au champ lexical (comme nous l avons vu dans l exemple précédent) ; toutes les autres facettes, qui s appliquent à l espace de valeurs ; Il est également possible de préciser les valeurs minimum ou maximum (inclue ou exclue), longueur, codage (en octets ou caractères),... Il est important de signaler que les facettes ne s appliquent pas à tous les types, mais seulement à certains. Par exemple, la facette fractiondigit le nombre de chiffres après la virgule ne s applique qu au type decimal, et non entier (bien entendu). Autre exemple de dérivation par restriction, qui n autorise que 3 valeurs possibles, grâce à une enumeration : <xs:simpletype name="typetaille"> <xs:restriction base="xs:string"> <xs:enumeration value="petite"/> <xs:enumeration value="moyenne"/> <xs:enumeration value="grande"/> </xs:restriction> </xs:simpletype> 2.4.2 Dérivation par liste La dérivation par liste crée un type liste à partir d un type atomique, ce qui oblige tous les items de la liste à avoir le même type. Les types créés ont la sémantique d une liste, la sémantique individuelle est perdue. Le principal inconvénient de la version actuelle de XML Schema est l impossibilité de définir le caractère de séparation des items de la liste. On doit donc définir les listes séparées par un caractère espace : <courses>entrées fruits viande légumes</courses> 11

ISO 11179-3 2.5 Exemple concret Déclarons le type "typelistedecourses" : <xs:simpletype name="typelistedecourses"> <xs:list itemtype="xs:string"/> </xs:simpletype> On peut mesurer la longueur d une liste par son nombre d items. Il est possible d appliquer des facettes sur les listes, cependant il faut respecter la définition de la liste en premier lieu, puis la contrainte qui lui est appliquée. Enfin, la recommandation interdit de définir des listes de listes. 2.4.3 Dérivation par union La dérivation par l union crée un type qui est l union des types membres. Par exemple, nous pouvons définir le type nombre, dont les instances pourront être à la fois un entier, un réel ou un double précision. Voici le code : <xs:simpletype name="typenombre"> <xs:union membertypes="xs:integer xs:string xs:double"/> </xs:simpletype> Il est également possible de cumuler plusieurs restrictions de différentes sortes ; on peut ainsi imaginer l union de 2 listes restreintes. Cependant les deux seules facettes supportées par le type union sont pattern et enumeration. 2.5 Exemple concret Ci-dessous 2 fichiers qui m ont permis de m exercer à la définition de XSD. Le fichier personne.xsd décrit l architecture du fichier xml, en déclarant les éléments à l endroit où ils apparaissent. Cependant cela rend la structure moins souple, et moins modulaire. personnes.xml <?xml version="1.0" encoding="iso-8859-1"?> <personnes xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:nonamespaceschemalocation= personne.xsd > <personne naissance="1969"> <identite> 12

ISO 11179-3 2.5 Exemple concret <prenom>linus</prenom> <nom>torvalds</nom> </identite> <liste puce="chiffre"> <profession>informaticien</profession> <loisir>construire un OS</loisir> </liste> </personne> <personne naissance="1912" mort="1954"> <identite> <prenom>alan</prenom> <nom>turing</nom> </identite> <liste puce="lettre"> <profession>informaticien</profession> <profession>mathématicien</profession> <profession>cryptographe</profession> </liste> </personne> <personne naissance="1973"> <identite> <prenom>nicolas</prenom> <nom>malandain</nom> </identite> <liste puce="chiffre"> <profession>maître de conférences</profession> <loisir>informatique</loisir> <loisir>roller</loisir> <loisir>aikido</loisir> </liste> </personne> <personne naissance="1970"> <identite> <prenom>nicolas</prenom> <nom>delestre</nom> </identite> <liste puce="chiffre"> <profession>motard</profession> <loisir>tricoter</loisir> </liste> </personne> <personne naissance="1970"> <identite> 13

ISO 11179-3 2.5 Exemple concret <prenom>alain</prenom> <nom>rakotomamonjy</nom> </identite> <liste puce="romain"> <profession>joueur de billard</profession> <loisir>se prendre des tôles à XBlast</loisir> </liste> </personne> </personnes> personne.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema"> <xs:element name="personnes"> <xs:complextype> <xs:sequence> <xs:element maxoccurs="unbounded" minoccurs="0" name="personne"> <xs:complextype> <xs:sequence> <xs:element name="identite"> <xs:complextype> <xs:sequence> <xs:element name="prenom" type="xs:string"/> <xs:element name="nom" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> <xs:element name="liste"> <xs:complextype> <xs:sequence> <xs:element name="profession" type="xs:string" minoccurs="1" maxoccurs="3"/> <xs:element name="loisir" type="xs:string" minoccurs="0" maxoccurs="unbounded"/> </xs:sequence> <xs:attribute name="puce" use="required"> <xs:simpletype> <xs:restriction base="xs:string"> <xs:enumeration value="chiffre"/> <xs:enumeration value="lettre"/> <xs:enumeration value="romain"/> </xs:restriction> </xs:simpletype> 14

ISO 11179-3 2.6 Utilisation pratique des XSD </xs:attribute> </xs:complextype> </xs:element> </xs:sequence> <xs:attribute name="naissance" type="xs:string" use="required"/> <xs:attribute name="mort" type="xs:string" use="optional"/> </xs:complextype> </xs:element> </xs:sequence> </xs:complextype> </xs:element> </xs:schema> 2.6 Utilisation pratique des XSD Comme nous l avons vu, le XML Schema a des capacités de description de données importantes, mais surtout extensibles. Il est donc important de savoir mettre une XSD à profit pour la génération des instances de documents XML. 2.6.1 Liens entre XML et XSD Il est essentiel d associer les fichiers XML à leur XSD, pour pouvoir vérifier la syntaxe des instances de documents. Il y a 2 principaux cas : lorsque l on connaît le namespace et lorsque l on n en n utilise aucun. Dans le cas où l on utilise pas de namespace, on utilise l attribut xsi :nonamespaceschemalocation. Cet attribut est porté par l élément racine du document XML. Le plus souvent celà est utilisé quand la XSD est contenue dans le même répertoire que le document instancié. <ISO11179-3 xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:nonamespaceschemalocation="example.xsd"> Voici un exemple avec un namespace : <ISO11179-3 xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://asi.insa-rouen.fr/~lfallet example.xsd"> L attribut xsi :schemalocation contient une paire de valeurs, la première étant l URI de l espace de noms recherché et la seconde l emplacement physique du schéma qui lui correspond. Cette informa- 15

ISO 11179-3 2.6 Utilisation pratique des XSD tion connue, le validateur (un éditeur, un validateur ou autre) peut lire le schéma et valider l instance du document. 2.6.2 Organisation physique des fichiers XSD Un fichier XSD, même sans être complexe, est relativement volumineux. De plus il se peut que l on désire réutiliser une partie d une XSD. Il faut alors fractionner le fichier ; une bonne répartition peut être de placer d un côté les définitions, et de l autre l architecture. Dans l architecture on n incluera que les définitions de types nécessaires. L inclusion d un schéma dans un autre se fait ainsi : <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema"> <xs:include schemalocation="administered_item_type.xsd"/>... </xs:schema> L effet de l inclusion d un schema est la fusion des 2 documents en un seul schéma global. Le schéma inclus n a pas besoin d être un schéma complet en lui-même. On peut ainsi déclarer les types dans un document, et l inclure dans un autre qui ne contiendra que la description de la structure. Attention, il n est pas possible d indiquer 2 définitions identiques, car il n y a pas de règle de priorité d une définition sur une autre, cela est donc considéré comme une erreur. Différences entre xs :include et xs :import Le premier permet d inclure des schéma pour le même espace de noms cible. Le second réalise l import d un schéma dans un autre espace de nom. Avec xs :include il n est pas possible de changer les définitions du schéma inclus. Pour cela, il faut utiliser xs :redefine. Ces fonctions sont la base de la création de bibliothèques de schémas. 16

ISO 11179-3 2.7 Outils 2.7 Outils 2.7.1 Editeur de XSD Veillez à choisir un éditeur qui prend en charge les XSD (ceci est indiqué dans les fonctionnalités du logiciel), la création et la validation de vos documents XML n en sera que plus facile. <oxygen/> Ce logiciel permet de gérer efficacement des documents XML, ainsi que les documents associés tels que XML Schéma (XSD), Schéma de RELAX NG, DTD et XSLT. Avec FOP ou XEP il sera facile de réaliser des transformation en PS ou PDF, par le biais d une XSLT-FO. Egalement disponible en plug-in pour Eclipse. http ://www.oxygenxml.com/ xmlspy Environnement de développement qui permet l édition et le débuggage des XSD, XSL... Il permet d obtenir une vue graphique du schema XML en cours de développement. http ://www.xmlspy.com/products_ide.html Eclipse Il existe des packages pour Eclipse, disponibles à cette adresse : http ://www.eclipse.org/xsd/ 2.7.2 Validateur XSV - Conseillé par le W3C, ce validateur est disponible en téléchargement et en ligne : http ://www.w3.org/2001/03/webdata/xsv La version pour Windows se trouve ici : ftp ://ftp.cogsci.ed.ac.uk/pub/xsv/xsv25.exe Pour Linux : ftp ://ftp.cogsci.ed.ac.uk/pub/xsv/xsv-2.5.tar.gz (Attention, Python 2.2 est requis). 17

3 La Norme ISO 11179-3 3.1 Présentation 3.1.1 ISO, AFNOR et IEC l ISO (International Standard Organisation) est un organisme de standardisation présent dans de nombreux pays. Son représentant en France est l AFNOR (Association Française de NORmalisation). L IEC (International Electrotechnical Commission) s occupe de définir des normes dans les domaines liés aux technologies électriques et électroniques. L ISO et l IEC, ainsi que des organismes nationaux collaborent à la rédaction de normes sur les nouvelles technologies telles que la norme ISO 11179. 3.1.2 But de la norme ISO/IEC 11179 Les données, notamment dans le domaine des bases de données, doivent être échangées de façon fiable et précise. Cet échange n est possible que si le propriétaire et les utilisateurs des données ont une définition commune de leur structure : les méta-données 4. La norme ISO/IEC 11179 définit un outil pour la gestion des méta-données et permet ainsi d améliorer le partage des données, leur intégration au sein de nouveau systèmes, une meilleure synchronisation des données, une meilleure intégrité, etc. La troisième partie de la norme, l ISO/IEC 11179-3 décrit la façon dont doivent être organisées les données de façon sémantique. Elle donne ainsi un modèle conceptuel qui décrit la façon dont l être humain réfléchit. Ce modèle ne décrit en aucune façon une méthode logique pour représenter les données dans un ordinateur. 3.2 Structure du modèle conceptuel Ce modèle est divisé en deux grandes parties : Un domaine conceptuel ; Un domaine de valeur : la représentation de ce modèle dans un domaine particulier. 4 Metadata en anglais 18

ISO 11179-3 3.2 Structure du modèle conceptuel FIG. 3 Structure générale du modèle conceptuel définit par l ISO/IEC 11179-3 3.2.1 Le domaine conceptuel (Conceptual Domain) C est dans cette première partie que sont définit les principes du modèle que l on va utiliser. Dans un premier temps, on y définit les concepts de données auxquels on va s intéresser. Ces concepts permettent de structurer les idées générales, et sont appelés "Data_Element_Concept" ou DEC (concepts de données). On y associe un domaine conceptuel qui donne pour le Data_Element_Concept auquel il est associé l ensemble des valeurs pouvant être prises par celui-ci (voir Fig :3 ). Ce domaine de valeurs peut être énuméré. C est le cas quand il est possible de dénombrer tous les éléments de ce domaine. Quand cela est impossible, le domaine est dit non énuméré. 3.2.2 Domaine de valeurs Le domaine conceptuel décrit les concepts, le domaine de valeur est la correspondance de ces concepts dans un domaine particulier. Ainsi chaque élément que l on définira dans le domaine de valeur correspond à un élément du domaine conceptuel. Ainsi à un Data_Element_Concept on peut associer un Data_Element. De la même façon, à chaque Conceptual_Domain on peut associer un Value_Domain qui décrit toutes les valeurs pouvant être prises par les Data_Element. On remarquera qu à chaque valeur du Value_Domain correspond une valeur du Conceptual_Domain. Ainsi à un domaine conceptuel énuméré il sera uniquement possible de faire correspondre un ou plusieurs domaines de valeurs énumérées. Il en va de même pour les do- 19

ISO 11179-3 3.3 Exemples d application de la norme maine conceptuels non-énumérés (voir Fig :3 ). Attention, chaque élément que l on peut trouver dans le domaine des valeurs correspond à un élément du domaine conceptuel. Par contre, pour tous les éléments du domaine conceptuel, il n y a pas forcément un élément dans le domaine de valeurs. Aussi, à un élément du domaine conceptuel peuvent correspondre plusieurs éléments dans le domaine de valeurs. 3.3 Exemples d application de la norme 3.3.1 ISO 3166 L ISO 3166 dans sa version de 1997 définit les pays avec les différents domaines de valeurs : les noms courts en anglais, les noms longs en anglais, les codes alphabétiques en deux lettres, les codes alphabétiques en trois lettres, les codes numériques en trois caractères, les noms courts en français, les noms longs en français. Chacun de ces domaines de valeurs est une représentation du domaine conceptuel des pays. Ainsi on peut définir le Data_Element_Concept "pays" qui définit le concept de pays. Comme on peut dénombrer et lister tous les pays du monde, on associe au Data_Element_Concept "pays" un domaine conceptuel énuméré : le Enumerated_Conceptual_Domain. On va maintenant décrire plus précisément ce domaine conceptuel. Chacune des valeurs constituant ce domaine peut être exprimée en utilisant l élément Value_Meaning, "sens de valeur", définit par la norme ISO 11179. Cet élément comprend un Value_Meaning_Identifier qui permet d identifier de manière unique l élément. On utilisera ici ceux définit par la norme ISO 3166. Le Value_Meaning possède aussi une Value_Meaning_Description qui donne une brève description des valeurs. A chaque Value_Meaning on peut associer une date de début et une date de fin. Dans notre cas, la norme 3166 étant valable depuis le 10 Janvier 1997 et étant toujours actuelle, on peut donc définir une Value_Begin_Date pour chaque Value_Meaning qui aura pour valeur la date d entrée en vigueur de la norme. Chacun des domaines de valeurs définit par la norme ISO 3166 peut être une application du concept de pays. Ainsi on peut définir comme Data_Element correspondant au Data_Element_Concept "pays" les éléments suivant : les noms courts en anglais, les noms longs en anglais, les codes alphabétiques en deux lettres, etc. Dans notre exemple nous ne traiterons que les noms courts de pays en anglais. Nous avons donc 20

ISO 11179-3 3.3 Exemples d application de la norme FIG. 4 Exemple : les pays et leur représentation "Short English Name" (nom courts en anglais) 21

ISO 11179-3 3.3 Exemples d application de la norme comme Data_Element "Short English Name" 5. Comme au Data_Element_Concept il est associé un Enumerated_Conceptual_Domain, nous associons au Data_Element un Enumerated_Value_Domain. De même, chaque Value_Meaning peut avoir un équivalent dans le domaine de valeur, une Permissible_Value. Ainsi le domaine de valeurs est composé de plusieurs Permissible_Value correspondant à une Value_Meaning (voir Fig : 4, page précédente). 3.3.2 ISO 6709 La norme ISO 6709 fournit une représentation standard de la latitude, longitude, et de l altitude pour la localisation des points géographiques. Nous allons, dans le cadre de notre exemple nous intéresser à la latitude. Nous prenons donc comme Data_Element_Concept la latitude. Nous aurions également pu choisir la longitude ou l altitude comme Data_Element. La latitude est la mesure de la distance angulaire entre un méridien nord ou sud et l équateur. La latitude peut donc prendre une infinité de valeurs. On associera alors au Data_Element_Concept un domaine de valeurs non énuméré. Pour exprimer la nature de ce domaine, on utilise simplement une description des valeurs possibles. FIG. 5 Exemple : la latitude et leur représentation sexagésimale 5 Noms courts en Anglais 22

ISO 11179-3 3.3 Exemples d application de la norme Nous allons appliquer ces concepts à la représentation sexagésimale de la latitude. Ainsi le Data_Element que nous allons choisir est la représentation sexagésimale de la latitude. Comme le domaine conceptuel auquel est associé le Data_Element_Concept est non-énuméré, le domaine de valeur correspondant l est aussi. De même, pour expliciter ce domaine de valeur, seule une description est nécessaire (voir Fig :5). Il est aussi possible de préciser, d une part les propriétés du Value_Domain duquel hérite le Non_Enumerated, d autre part de préciser l unité de mesure, le type, le nombre maximum de caractères. Pour plus de précision, voir le diagramme de classes en annexe (voir Fig :14). 23

4 Travail réalisé Avant de présenter en détail le travail effectué, nous allons expliciter certains de nos choix techniques. 4.1 Choix du XML Décrire des métadonnées nécessite l usage d un langage polyvalent, modifiable, possédant une puissance d expression suffisante. Le XML fait partie des langages qui savent s autodécrire (grâce aux DTD et XSD), et qui peuvent être complétés en créant une syntaxe propre. Le langage XML peut également subir des transformations (au moyen de feuilles XSLT), les-dites transformations provenant de XML également. Cela permet de modifier le langage tout en restant dans celui-ci. Le XML n est pas le seul 6 langage à posséder ces propriétés, mais il est grandement répandu et diffusé. Ce large emploi l amène à être compatible avec bon nombre de standard d autres domaines. Par exemple, il est possibilité de l interfacer avec de l UML. La majorité des schémas de normes étant décrits en UML, la conversion devient réalisable. Le fait que ce format soit portable est également un avantage. Le choix de XML Schema s inscrit dans la continuité du choix du XML. Plus les langages employés sont proches, meilleure est la solidité et la compréhension du système créé. De plus les XSD sont sur le point de remplacer les DTD. Il est donc important de ne pas créer un outil utilisant une technologie bientôt dépassée. L un des problèmes auquel nous nous sommes heurtés est la représentation des données en XML. En effet, celui-ci est un langage à balises, il est donc possible de placer les informations soit dans le nom de l élément, soit dans un attribut, soit en tant que contenu. Généralement, la création d élément permet l utilisation d un type qui n existe pas encore. Les contenus d éléments sont utilisés lorsqu il peut y avoir plusieurs mots, et leur ordre dépend de l architecture du document. Les attributs sont quand à eux utilisés pour l identification, le contrôle de valeurs ou en vue d un traitement ultérieur. Notre point de départ est un diagramme UML représentant les différents niveaux de la norme (conceptuel, puis représentation). Nous avons donc utilisé un élément propre à chaque classe du diagramme UML. Les attributs de la classe ont été placés dans les attributs des éléments, et le contenu est soit vide, soit la valeur de la notion de la classe. Concernant les noms d éléments ou attributs adoptés par la suite dans les documents, nous nous sommes conformés à la norme. Il est ainsi plus facile de passer de l un à l autre sans être perdu. Les types sont nommés du nom de l élément suivi d un underscore puis du mot Type, de cette manière : ElementNameAsNormISO_Type. 6 le SGML également 24

ISO 11179-3 4.2 Processus de transformation mis en place Un autre point concerne le nommage des éléments du domaine représentation. Comme indiqué dans la norme (voir Fig : 14), plusieurs Data_Element peuvent être associés à un même Data_Element_Concept. Pour faire une différence entre ces Data_Element, il ne faut pas utiliser le même élément. Nous avons donc accolé le data_identifier du Data_Element_Concept au nom du Data_Element, comme par exemple Data_Element_Country. 4.2 Processus de transformation mis en place L objectif est de fournir à l ISO un outil permettant de créer facilement des référentiels de norme. Lorsqu une entité déclarera posséder une représentation des metadonnées compatibles avec la norme, l ISO pourra vérifier la compatibilité grâce à cet outil. 4.2.1 Technologies à disposition L utilisation des XSD permet de définir des types et de les dériver. C est ainsi que l on a pu reproduire le diagramme de classes que contient la norme de cette manière : FIG. 6 Héritage des classes depuis la classe Administered_Item Cet héritage est incomplet, en ce sens qu il ne contient pas la totalité des classes de la norme. En effet il n y a (pour la partie haute) que la classe abstraite Administered_Item qui contient un 25

ISO 11179-3 4.2 Processus de transformation mis en place Administration_Record, et pas les Context, Classification_Scheme, Object_Class et Property. Ces éléments pourront être rajoutés plus tard, grâce à ce système de classes. Les classes (que nous appelons également types dérivés) codées sont les objets majeurs. Le reste des informations ne constitue pas le squelette de la norme, et nous aurait submergé par des détails. Nous avons également utilisé la technologie XSLT pour réaliser la transformation de la représentation conceptuelle en XML en un schéma XML pour la partie représentation. Ce fichier XSD structure le document des Value_Domain en fonction du domain conceptuel, il varie donc selon chaque fichier. La solution est de le générer en fonction du document décrivant les Data_Element_Concept. Une feuille XSL-FO permet de transformer la description du modèle conceptuel en tableau plus lisible que le XML. Le monde du XML contient suffisamment de formes de langages pour définir sa propre syntaxe, la rendre interactive et diffusable. Comme nous le verrons dans les Perspectives (section 4.3), le XML nous apportera encore des solutions pour la suite du projet. 4.2.2 Schéma des transformations Comme disait Napoléon Bonaparte, "un bon croquis vaut mieux qu un long discours". Le voici : FIG. 7 Processus de transformation Le processus que nous avons mis en place permet, à partir de la définition des Data_Element_Concept et des Conceptual_Domain, de définir les Data_Element et les Value_Domain. Pour se faire, on utilise une feuille XSD qui définit les types (ex. : Data_Element_Concept, Conceptual_Domain... ) selon la norme ISO 11179. Cette feuille XSD donne la structure globale d un fichier XML qui décrit un domaine conceptuel souhaité. La feuille XML est écrite en utilisant éventuellement un logiciel 26

ISO 11179-3 4.2 Processus de transformation mis en place comprenant les XML Schema et comportant la fonction validation. Cette feuille XML peut être alors utilisée pour générer un document PDF. Cela peut être réalisé grâce à une transformation XSL-FO. Ce document PDF comprend un résumé sous forme de tableau des éléments définis dans la feuille XML. Ce document PDF peut être alors utilisé par les organismes de normalisation. On peut ensuite obtenir la définition des Data_Element et Value_Domain pouvant être utilisés pour le domaine d application. En effet, ceux-ci sont directement liées aux Data_Element_Concept et aux Conceptual_Domain décrits dans la feuille XML obtenue précédemment. Cette définition est faite dans une feuille XSD générée grâce à une feuille de transformation XSLT. Le code XSD ainsi obtenu impose une forte relation entre les deux niveaux. Ainsi les noms des tags pouvant être utilisés dans la feuille XML décrivant le niveau des Data_Element et des Value_Domain découlent directement du contenu du niveau des Data_Element_Concept et des Conceptual_Domain. Chaque tag comporte une partie fixe rappelant à quel élément de la norme il se rapporte et une partie variable venant du niveau supérieur apportant la relation entre les deux niveaux. En reprenant l exemple sur la norme ISO 3166, on considère le Data_Element_Country. On peut le définir de la façon suivante : <Data_Element_Concept> <administered_item_administration_record registration_status="standard"...> <administered_item_identifier data_identifier="country" version=""> On obtiendra dans la XSD résultant de la transformation XSLT le code suivant : <xs:element name="data_element_country"> Finalement, on pourra écrire dans le XML suivant la feuille XSD obtenue : <Data_Element_Country data_element_identifier="englishshortname"> Vous pouvez trouver l ensemble du code généré pour cet exemple ainsi que pour l exemple sur la norme ISO 6709 dans le CDRom associé à ce rapport. 27

ISO 11179-3 4.2 Processus de transformation mis en place Un autre exemple a été réalisé, celui de la LOM. Il a été entièrement réalisé à partir du processus établi en annexe, qui permet de créer un domaine conceptuel puis représentation. Cet exemple nous a permis de valider notre modèle (en supplément de la norme, qui contient tous les cas possibles). Parmi les fichiers du CDRom se trouvent les 2 fichiers XML de la LOM ainsi que le PDF. Nous possédions le modèle suivant : FIG. 8 Learning Object Metamodel 4.2.3 Problème(s) rencontré(s) Comme nous l avons vu précédemment, la génération du PDF sur le domaine conceptuel se fait directement à partir du fichier XML grâce à une feuille XSL-FO. Il ne peut en être de même pour générer le document PDF décrivant le domaine de valeur. En effet, les noms des tags présents dans le fichier XML décrivant ce niveau sont des noms variables. On ne peut utiliser une feuille de transformation XSL-FO identique à celle utilisée précédemment. Une solution vient du fait que le langage de transformation utilisé (XSL-FO) est lui même du XML et donc peut être généré à partir d un autre fichier XML grâce à une feuille de transformation XSLT. On peut donc envisager le processus suivant : 28

ISO 11179-3 4.2 Processus de transformation mis en place FIG. 9 Processus de transformation XSL-FO amélioré Ainsi nous générons la feuille de transformation XSL-FO qui permet, à partir du fichier XML décrivant le domaine de valeurs, d obtenir un fichier PDF faisant un résumé de ce niveau. Tous les éléments nécessaires pourront être pris en compte dans cette transformation : les noms des tags sont obtenus à partir du XML du niveau précédent grâce à la transformation XSLT ; les valeurs entrées par l utilisateur dans le domaine d application sont pris en compte grâce au processus traditionnel de transformation XSL-FO. Double héritage et aggrégation Un problème s est posé à cause de l héritage. Ce problème ne remet pas du tout en cause l utilisation de la dérivation de types, qui est à la fois la manière la plus correcte de procéder (comparée aux diagrammes de la norme) mais aussi la plus propre pour la compréhension et l évolution des types. C est juste une des difficultés à implémenter ce modèle de bout en bout. Voici le problème, exposé de manière symbolique puis dans le contexte. Alpha et Beta sont des classes abstraites. Alpha est composé de Beta. A est une instance de Alpha, et contient donc B, instance de Beta. 29

ISO 11179-3 4.2 Processus de transformation mis en place FIG. 10 Héritage et aggrégation Le problème est le suivant : A dérivant de Alpha, il connait l élément Beta. Comment lui fixer le nom de l élément par B et non par Alpha? La figure suivant illustre le problème dans notre contexte : FIG. 11 Arborescence du type Data_Element Voici le code associé à ce problème, c est à dire la XSD générée automatiquement : <xs:element name="enumerated_value_domain_country"> <xs:complextype> <xs:complexcontent> <xs:extension base="enumerated_value_domain_type"> <xs:sequence> <xs:element minoccurs="0" maxoccurs="1" name="permissible_value_1001" type="permissible_value"/> 30

ISO 11179-3 4.3 Perspectives techniques Cependant si on laisse l héritage au niveau des types, il n est pas possible d utiliser l élément "Permissible_Value_1001" mais seulement l élément "Permissible_Value". Pour le moment nous n avons pas trouvé de solution viable. Celle qui a été adoptée est la suivante : FIG. 12 Arborescence modifiée du type Data_Element Merci de m indiquer la solution si vous l avez. Je n ai pu trouver d aide sur la liste xml-tech, et je me demande si ce problème n approche pas une des limites des XSD. 4.3 Perspectives techniques Nous nous sommes intéressés dans ce projet à une partie seulement de la norme ISO, la partie 11179-3. Nous en avons implémenté la majeure partie, même s il reste à définir les Object_Class et Property. Les Object_Class représentent un ensemble d idées et de concepts. Les Property représentent une caractéristique commune à tous les membres d un Object_Class. Cette manière de penser (à base de concepts, idées, comportements et attributs) est très proche des diagrammes de classes. Il est donc raisonnable de penser qu un diagramme de classes UML peut exprimer ces concepts, leurs relations, à la manière des Object_Class. Il faudrait pouvoir mettre cette relation à profit. La plupart des logiciels actuels qui permettent de réaliser des diagrammes de classe UML permettent d enregistrer ceux-ci sous forme de fichier XML. On peut envisager une transformation automatique qui permettrait de passer d un fichier UML généré par un de ces logiciels grâce au langage UXF 7 en un fichier XML utilisant les Object_Class et les Property. 7 UML exchange Format, voir http ://www.yy.ics.keio.ac.jp/ suzuki/project/uxf/ 31

ISO 11179-3 4.3 Perspectives techniques On peut ensuite générer à partir de ce fichier XML, le fichier XML décrivant les Data_Element_Concept. On obtient donc, en associant les processus précédemment définis, le processus général de transformation suivant : FIG. 13 Processus de transformation possible On a alors un processus complètement automatisé qui permet, à partir d un diagramme de classes UML d obtenir une définition de méta-données conforme à la norme ISO 11179. Un document à étudier pour la suite du projet pourrait être celui-ci : http ://pueblo.lbl.gov/ olken/mendel/x3l8/xmlannex/annex.htm. C est une proposition d annexe pour la partie 3 de la norme ISO 11179, son titre est "Annex E : XML Encoding for Metadata Registry Contents". 32

5 Conclusion Cette étude n est pas complète, mais elle n en avait pas l intention. Un prélude est toujours nécessaire à ce type de projet, pour déterminer les meilleures solutions à adopter. Nous avons donc recherché les outils et technologies nécessaires pour mettre en place ce système XML. Ce n est pas encore une application du fait qu elle nécessite des transformations manuelles, contrairement à si nous avions utilisé Cocoon. Nous avons donc déterminé les points clés avec l aide très appréciée de M. Delestre, sans qui nous n aurions pu comprendre les subtilités de cette norme et l interprétation à en tirer. La définition de l architecture a permis de savoir quels étaient les fichiers nécessaires et le mode opératoire associé. Du point de vue des connaissances acquises, les XSD sont un point majeur, suffisamment souligné dans la partie de ce rapport qui lui est consacrée. L appréhension de la norme est également un point intéressant ; ce type de document est organisé de manière redondante, c est à dire qu il est possible de lire les descriptions textuelles, les schémas, pour comprendre le sujet traité, mais également de consulter les précisions propres à un point du sujet. Il faut apprendre à jongler entre les différentes sections pour trouver tous les éléments nécessaires. J espère que les perspectives de la suite du projet tenteront des personnes pour continuer le travail commencé. Peut être serait-il judicieux, après avoir pensé la norme de la manière citée, de confronté notre travail aux recherches lancées sur le sujet par d autres personnes. 33

6 Bibliographie Documentation W3C XML Schema Part 0 : Primer (http ://www.w3.org/tr/xmlschema-0/) XML Schema Part 1 : Structures (http ://www.w3.org/tr/xmlschema-1/) XML Schema Part 2 : Datatypes (http ://www.w3.org/tr/xmlschema-2/) Le document XML Schema permettant de valider d autres documents XML Schema : http ://www.w3.org/2001/xmlschema.xsd Tutoriels XSD Liste XML Tech pour parler XML, XSL, XSD : http ://xmlfr.org/listes/xml-tech/ Une multitude de langages expliqués : http ://www.laltruiste.com/ http ://www.xml.com/pub/a/2000/11/29/schemas/part1.html http ://www.w3schools.com/schema/ Tutoriels FO http ://www.renderx.com/tutorial.html FO : http ://www.w3.org/tr/xsl/slice6.html Outils Liste complète d outils : http ://www.w3.org/xml/schema <oxygen/> : http ://www.oxygenxml.org/ XSV 2.5-2, validateur pour XSD : http ://www.w3.org/2001/03/webdata/xsv FOP, transformateur FO PDF : http ://xml.apache.org/fop/ Ouvrages XML Schéma, d Eric van der Vlist Collection O Reilly Disponible à la bibliothèque de l INSA de Rouen Anecdote : Eric van der Vlist répond souvent en personne aux messages envoyés sur la liste XML- Tech. Il écrit en ce moment un livre sur Relax NG, une nouvelle technologie de schéma XML. 34

Table des figures 1 Intérêt d un traducteur commun entre diverses représentations............ 3 2 Graphe de hiérarchie des types de données prédéfinis................. 10 3 Structure générale du modèle conceptuel définit par l ISO/IEC 11179-3....... 19 4 Exemple : les pays et leur représentation "Short English Name" (nom courts en anglais) 21 5 Exemple : la latitude et leur représentation sexagésimale............... 22 6 Héritage des classes depuis la classe Administered_Item............... 25 7 Processus de transformation.............................. 26 8 Learning Object Metamodel.............................. 28 9 Processus de transformation XSL-FO amélioré.................... 29 10 Héritage et aggrégation................................. 30 11 Arborescence du type Data_Element.......................... 30 12 Arborescence modifiée du type Data_Element..................... 31 13 Processus de transformation possible.......................... 32 14 Consolidated metamodel (extracted from ISO 11179-3)................ 37 15 Fichiers du projet.................................... 38 35

7 Annexes Avertissement : l ISO n approuve pas ni ne sponsorise notre rapport. Toutes les références qui y sont faites ne sont pas contrôlées par l ISO. Nous n avons pas non plus eu le droit d utiliser le logo 8, qui est une marque déposée. 7.1 Répartition du travail Travail effectué par Céline CAPRON : étude de la norme ; création de diagrammes UML exemples traitant des normes ISO 3166 et 6709 ; création des fichiers XML correspondant aux diagrammes ; transformation XSL-FO ; rédaction du rapport (parties norme et travail réalisé) ; Travail effectué par Laurent FALLET : étude de la technologie XML Schema ; création des feuilles XSD puis de l héritage ; création de la feuille XSLT ; rédaction du rapport (logo, parties XML Schema et travail réalisé) ; Les fichiers du projet (XSD, XSLT, XSLFO et autres fichiers exemples) n ont pas été inclus en annexe. En effet nous ne pensons pas que le code soit intéressant sans le voir fonctionner, en l utilisant réellement. Un CDRom contenant les fichiers est inclus dans le rapport en version papier, nous le demander si jamais il a été égaré. Si vous avez obtenu ce rapport au format électronique, les sources doivent être incluses. 8 suite à une demande à logo@iso.org 36

ISO 11179-3 7.2 Diagrammes 7.2 Diagrammes FIG. 14 Consolidated metamodel (extracted from ISO 11179-3) 37

ISO 11179-3 7.3 Contenu du CD 7.3 Contenu du CD Normalement un CD est inclus dans le rapport. Celui-ci contient les sources des fichiers utilitaires (XSD, XSLT), des exemples (ISO 3166, 6709 et LOM). En voici un schéma, qui donne un aperçu de l utilisation de ces fichiers : FIG. 15 Fichiers du projet La légende associée est la suivante : fichier en caractères non accentués : fichier définitif fournis fichier en caractères gras : fichier à créer soi-même fichier en caractères italiques : fichier créé automatiquement non fournis 38

ISO 11179-3 7.3 Contenu du CD flèche droite : validation d un fichier XML par un XML Schema flèche courbe continue : transformation d un fichier XML par une feuille XSL-FO en PDF flèche courbe pointillée : transformation d un fichier XML par une feuille XSLT en XSD L utilisation de ces fichiers est simple : 1. transférez les fichiers dans un répertoire de travail, en veillant à conserver le répertoire "types" et son contenu ; 2. utilisez un éditeur décrit dans la partie 2.7.1 ou 6 ; 3. création du domaine conceptuel : ouvrez l éditeur, créez un nouveau fichier XML nommé "whatyouwantcd.xml" ayant pour Schema XML le fichier "iso11179-3.xsd" ; 4. remplissez les champs, puis vérifiez la validité de votre fichier. Astuce pour les dates : celles-ci sont au format YYYY-MM-DD ; 5. appliquez la transformation du fichier "create_vd-xsd_from_cd-xml.xsl" sur votre fichier "whatyouwantcd.xml" en donnant le nom "whatyouwantvd.xsd" au fichier résultant ; 6. création du domaine représentation : créez un nouveau fichier XML nommé "whatyouwantvd.xml" ayant pour Schema XML le fichier "whatyouwantvd.xsd" ; 7. remplissez les champs, puis vérifiez la validité de votre fichier. Astuce pour les unit_of_measure_precision : indiquez une valeur entière ; 8. vous pouvez également créer un fichier PDF du domaine conceptuel en appliquant la transformation du fichier "CD_to_fo.xsl" sur le fichier "whatyouwantcd.xml" ; La transformation en PDF nécessite FOP, disponible à l adresse indiquée dans les liens de la section 6. En souhaitant que cet outil vous sera utile, n hésitez pas à l améliorer, et nous faire part de vos commentaires. Réalisé avec L A TEX 39