Spécifications liées à XML

Transcription

1 Spécifications liées à XML : Index Spécifications liées à XML #Standards de base - SGML (p. 2) - XML (p. 5) - EXI (p. 8) - Unicode XML (p. 9) #Définition de modèles - NameSpace (p. 11)- Schema (p. 14)- DTD (p. 19)- DSDL (p. 22)- RELAX NG (p. 24) #Modélisation conceptuelle - UML (p. 25) - XMI (p. 26) #Représentation et fragmentation #Représentation - Canonical (p. 27) - Infoset (p. 29) #Fragmentation - XML Catalogs (p. 32) - Fragment Interchange (p. 34) - XInclude (p. 36) #Utilisation des documents XML #Construction # Identification des contenus - XML Language (p. 38) - XPointer (p. 40) #Accès aux contenus - XLink (p. 42) - XPath (p. 44) #Exploitation #Traitements - DOM (p. 47) - SAX (p. 51) - XProc (p. 53) - XSLT (p. 54) #Présentation - DSSSL (p. 58) - XSL (p. 60) #Accès aux contenus - XML Query (p. 64) Tirème SARL - Glossaire.??

2 Spécifications liées à XML : SGML SGML, Langage normalisé de balisage généralisé Rédaction : Pierre Attar Comme XML, SGML est un langage de codage de données dont l'objectif est de permettre, dans un échange entre systèmes informatiques, de transférer, en même temps, des données textuelles et leurs structures. SGML était très utilisé avant qu'xml n'existe : c'est d'ailleurs à partir de ce langage (et en tenant compte de ses différentes utilisations) qu'a été élaboré le standard XML. On a dit beaucoup de choses sur SGML : que le langage était lourd, que les implémentations étaient difficiles, etc. De fait, ce n'était pas la technologie qui était lourde, mais les applications elles-mêmes. En effet, s'il est nécessaire de manipuler un manuel de maintenance aéronautique de quelques centaines de méga-octets, avec des arbres d'une profondeur allant jusqu'à des dizaines de niveaux, la technologie n'y fait rien (qu'elle soit XML ou SGML) : les manipulations sont de toutes les façons complexes! C'est ce dont est en train de se rendre compte la communauté XML, qui comprend que ce standard sera utilisé pour différentes classes d'applications : depuis l'échange de messages entre applications, avec des informations de l'ordre du kilo-octet jusqu'à des documents beaucoup plus lourds et beaucoup plus sémantiques, comme le sont un dictionnaire ou un ouvrage juridique. En termes de technologie, la lourdeur de SGML est certainement liée à ses DTD qui mélangeaient deux type d'information : la notion de modèle de donnée et le format de codage des documents conformes à ce modèle. Par ailleurs, le langage lui-même proposait beaucoup de facilités de saisie simplifiées des noms d'élément : toute chose difficiles à prendre en compte dans les outils de traitement. D'un point de vue technique donc, la grande avancée conceptuelle de XML est donc de différencier définition de modèle et format de codage des documents. C'est en cela que XML supprime des lourdeurs de SGML. L'avenir de SGML? D'un point de vue technique, ce format peut sans problème être remplacé par XML : tout ce qui est nécessaire à SGML existe à peu près dans XML. D'un point de vue pratique, les utilisateurs de SGML y gagneront en diversité d'outils utilisables et apprécieront à son juste avantage la prise en compte par XML d'unicode XML. D'un point de vue plus stratégique, beaucoup se posent la question de passer de SGML à XML, en raison des organismes de normalisation qui s'en occupent. Pour SGML, c'est l'iso qui assure la normalisation, avec ses processus de maturation d'une norme et ses représentations nationales assurant la qualité des normes ; en ce qui concerne la normalisation de XML, c'est le travail du W3C, un Consortium qui n'est représentatif que de Tirème SARL - Glossaire. Langage normalisé de balisage généralisé, p. 2/66

3 Spécifications liées à XML : SGML lui-même et qui, comme son nom l'indique, ne s'intéresse qu'au point de vue du Web. Cet argument devrait rapidement être balayé par la volonté commune des deux organismes de promouvoir XML au sein des normes documentaires de l'iso. Objectifs L'objectif de SGML était de définir un format neutre de rétention d'information chez un photocomposeur. ce format neutre devait permettre aux éditeurs de mieux faire jouer la concurrence et d'autoriser un éditeur à renégocier ses contrats avec les photocomposeurs pour, par exmeple, pouvoir transférer ses documents chez celui qui proposerait le meilleur prix. Par la suite, et comme pour XML, l'objectif de SGML fut de définir un format neutre de codage de document permettant de mettre en place des notions de réutilisation de la même information pour différentes publications, sur différnets médias. Aujourd'hui, l'objectif de SGML est le même que celui de XML et cette norme est appelée à être remplacée par XML. D'un point de vue pratique, tout document SGML peut être transformé de façon totalement automatisée en document XML. Les DTD de SGML devront subir quelques modifications qui les rendront certainement parfois plus laxiste. En effet, XML ne permet pas de prendre en compte les mécanismes d"inclusion et d'exclusion" propres à SGML. Il permet aussi un typage des attributs plus restreint. Cette dernière limite est maintenat bien levée avec la standardisation des Schema. Principes À la différence d'xml, un document SGML doit toujours être valide au regard d'une DTD. Les concepteurs, en raison de leur orientation documentaire, s'intéressaient beaucoup à la notion de validation électronique et automatique. Cette validation au regard d'une DTD permet de s'assurer que l'information est saisie conformément au modèle et que l'on peut donc lui appliquer les traitements automatisés sans avoir à valider la structure du document au préalable. A noter que cela reste vrai pour XML mais que cette dernière recommandation supprime l'obligation de validation pour lecture car des processus d'assurrance qualité peuvent remplacer cette validation à toutes les étapes d'un processus informatique. Dans les DTD, une des erreurs de jeunesse de SGML était de définir, en même temps que le modèle, les variations possibles du format de codage des documents eux-mêmes : options de minimisation des balises et, si nécessaire, options de redéfinition des balises elles-mêmes. Du fait de la standardisation d'unicode XML et des nouvelles capacités des ordinateurs actuels, toutes ces options ont été supprimées, pour arriver à l'obligation de "document bien formé", notion qui était, de fait, la sortie standard de tous les éditeurs SGML. Enfin, d'autres mécanismes peu utilisés existaient, comme ceux d'inclusion et d'exclusion. Il n'ont pas été jugés utiles dans XML, car apportant de la complexité aux traitements sans pour autant faciliter la vie du rédacteur. Recommandations(s) Traitement de l'information - Systèmes bureautiques - Langage normalisé de balisage généralisé Standard ISO, version 8879:1986, du Tirème SARL - Glossaire. Langage normalisé de balisage généralisé, p. 3/66

4 Spécifications liées à XML : SGML Document sur CSNUMBER=16387 Information processing - Text and office systems - Standard Generalized Markup Language (SGML) Standard ISO, version 8879:1986, du Document sur CSNUMBER=16387 Tirème SARL - Glossaire. Langage normalisé de balisage généralisé, p. 4/66

5 Spécifications liées à XML : XML XML, Langage de balisage très extensible Rédaction : Pierre Attar Recommandation(s) liée(s) : Canonical - XInclude - Infoset - Fragment Interchange - XML Base - DTD - XML Language XML est un langage de codage de données dont l'objectif est, dans un échange entre systèmes informatiques, de transférer, en même temps, des données et leurs structures. Permettant de coder n'importe quel type de donnée, depuis l'échange EDI jusqu'aux documents les plus complexes en passant par les échanges de données inter-applications, son potentiel est de devenir le standard universel et multilingue d'échange d'informations. Appliqué aux documents textuels, il permet d'identifier, de façon logique, la structure et l'organisation de l'information textuelle. Objectifs XML est un format textuel très flexible dérivé de SGML. Initialement conçu pour relever les défis de l'édition électronique de grande puissance, XML joue également un rôle de plus en plus important dans l'échange d'une grande variété de données, que ce soit sur le Web ou pour n'importe quel échange inter-applicatif. XML permettra, comme le souligne le W3C : l'édition électronique internationalisée, de façon indépendante des logiciels et des systèmes ; aux industries de définir des protocoles, indépendants des logiciels et des systèmes, pour l'échange des données (particulièrement les données du commerce électronique) ; de fournir de l'information aux agents utilisateurs sous une forme qui permette un traitement automatique après réception, par exemple pour toutes les applications de téléphonie mobile ; de faciliter le développement logiciel dès lors qu'il s'agit de manipuler l'information spécialisée et répartie ; de faciliter les traitements de données avec des logiciels peu coûteux ; à ce titre, l'avenir d'xml et d'un certain nombre de ses recommandations associées (XSLT, XPath, Infoset, etc.) est de devenir partie intégrante des couches hautes des systèmes d'exploitation ; aux utilisateurs du Web d'afficher l'information reçue avec la feuille de styles qu'ils souhaitent ; de faciliter la fourniture de Métadonnées (données descriptives de documents) qui aide à trouver de l'information. Tirème SARL - Glossaire. Langage de balisage très extensible, p. 5/66

6 Spécifications liées à XML : XML Principes Un document XML se compose, d'une part, de texte, et, d'autre part, d'informations de structure. Les informations de structure servent le plus souvent à délimiter du texte, pour en identifier la sémantique. Ainsi, <métier>consultant</métier> permet de dire que la chaîne de caractères "Consultant" doit être comprise comme étant une définition de métier. Il est possible de délimiter des chaînes de caractères ; il est aussi possible de délimiter tout ensemble d'informations mélangeant texte et structure. Par exemple, dans le document suivant : <métier> <nom> Consultant </nom> <descr> Le consultant travaille pour des consultés qui... </descr> </métier> La notion de métier introduit, d'une part, un nom de métier et, d'autre part, une description de métier. C'est l'appartenance hiérarchique qui définit que tout cela parle bien du même métier : elle permet de spécialiser des description : un nom de métier et une description de métier. Pour compléter cette description, il est parfois nécessaire de valuer la signification d'un objet. Par exemple, <auteur affiliation="rennes2">jean Dupont</auteur>, permet d'identifier un chaîne de caractères comme étant un auteur et, en plus, de décrire cet auteur, par valuation, comme appartenant à l'université de Rennes II. Les balises (<mabalise>... </mabalise>) délimitent des objets typés ; les attributs (<mabalise type="standard">) définissent des valuations d'objets. Un document XML est alors un arbre d'objets typés et valués. Pour finir, un document XML doit définir le jeu de caractères qu'il utilise, ainsi que la version de la recommandation XML. Du coup, l'exemple précédent s'écrira : <?xml version="1.0" encoding="utf-8"?> <métier>... </métier> Ce document est parfaitement décrit, il représente, au sens de la recommandation, un document "bien formé" (wellformed). Si nécessaire, un modèle documentaire peut lui être adjoint (voir DTD). Celui-ci définira les contraintes associées à ce document : le document devra alors être "valide", au regard de ce modèle. Définis de façon électronique, les applicatifs de type parsers seront capables de valider, de façon automatisée, la conformité d'un document à sa classe, à son modèle. L'avantage? Il sera possible d'appliquer des processus automatiques sur une classe de documents (les algorithmes étant écrits au regard de la classe et non pas au regard de chaque instance de document). Les différents aspects de la recommandation XML La recommandation XML s'intéresse à des notions fort différentes : un langage de codage, basé sur Unicode XML, de documents, avec des éléments, des attributs, un jeu de caractères, etc. ; un langage de définition de modèles documentaires, avec les DTD ; un langage d'expression d'inclusions de fichiers, avec les internal et external subset des DTD ; Tirème SARL - Glossaire. Langage de balisage très extensible, p. 6/66

7 Spécifications liées à XML : XML l'expression d'informations applicatives, comme les deux attributs xml:lang et xml:space, dont le rôle est, respectivement, d'indiquer la langue de rédaction d'un fragment de contenu et la façon de traiter les caractères d'espacement d'un contenu ; un langage de prise en compte extrêmement limité des espaces de noms. Le fait de mettre tous ces aspects dans une même recommandation a un aspect politique important, car cela oblige à prendre tout en compte sans différenciation. D'un point de vue technique, cela peut parfois poser des problèmes de compréhension : par exemple, pourquoi prendre en compte seulement les notions de langue et pas celles d'uri? Cela peut aussi poser des problèmes d'architecture d'application, dès lors que, par exemple, un Schema permet d'exprimer la même chose, et davantage qu'une DTD... sauf les notions d'inclusions de données spécifiées de façon indépendante des documents eux-mêmes, au travers des entités générales. Recommandations(s) Le langage de balisage extensible (XML) 1.1 Recommandation, version 1.1, du Document sur Extensible Markup Language (XML) 1.1 (Second Edition) Recommandation, version 1.1, du Document sur Tirème SARL - Glossaire. Langage de balisage très extensible, p. 7/66

8 Spécifications liées à XML : EXI EXI, Efficient XML Interchange (EXI) Rédaction : Pierre Attar Recommandation(s) liée(s) : XML - Infoset «EXI is a very compact representation for the Extensible Markup Language (XML) Information Set that is intended to simultaneously optimize performance and the utilization of computational resources. The EXI format uses a hybrid approach drawn from the information and formal language theories, plus practical techniques verified by measurements, for entropy encoding XML information. Using a relatively simple algorithm, which is amenable to fast and compact implementation, and a small set of datatype representations, it reliably produces efficient encodings of XML event streams.» Source. EXI, version 1.0 Objectifs Information descriptive non finalisée ; n'hésitez pas à nous contacter pour rédiger et/ou maintenir cette information à jour. Recommandations(s) EXI Recommandation, version 1.0, du Document sur Tirème SARL - Glossaire. Efficient XML Interchange (EXI), p. 8/66

9 Spécifications liées à XML : Unicode XML Unicode XML, Unicode in XML and other Markup Languages Unicode XML propose un jeu de caractères "universel". Cet objectif est extrêmement important sur Internet, où des textes dans toutes les langues, voir multilangues, cohabitent. Actuellement, et dans sa troisième version, Unicode couvre la plupart des séquences de caractères utilisées dans le monde. Il contient également les caractères spéciaux pour l'interopérabilité avec des jeux de caractères plus anciens, ainsi que les caractères de commande usuels. XML utilise Unicode XML, selon ses propres recommandations (voir ). L'avantage est alors de détenir un véritable langage universel, au moment où les échanges de données sont de plus en plus universel, surtout sur l'internet. Si, grâce à Unicode XML, les caractères échangés sont non ambigus, cela ne veut pas pour autant dire que l'affichage de ces caractères est toujours possible... On se rappellera qu'il existe une différence fondamentale entre la définition d'un caractère et sa représentation (souvent appelée police de caractère ou plus précisément glyphe). Objectifs Information descriptive non finalisée ; n'hésitez pas à nous contacter pour rédiger et/ou maintenir cette information à jour. Recommandations(s) Unicode Recommandation, version 4.1.0, du Document sur enumeratedversions.html#latest Unicode dans XML et les autres langages de balisage. Rapport technique Unicode n 20 Note, version , du Document sur Unicode in XML and other Markup Languages - Unicode Technical Report 20 Note, version , du Document sur Un modèle de caractères pour le Web 1.0 : les principes de base Recommandation, version 1.0, du Document sur Character Model for the World Wide Web 1.0 Tirème SARL - Glossaire. Unicode in XML and other Markup Languages, p. 9/66

10 Spécifications liées à XML : Unicode XML Recommandation, version 1.0, du Document sur Tirème SARL - Glossaire. Unicode in XML and other Markup Languages, p. 10/66

11 Spécifications liées à XML : NameSpace NameSpace, Espace de nom Rédaction : Pierre Attar Recommandation(s) liée(s) : DTD - Schema Les espaces de noms d'xml permettent de qualifier de manière unique des éléments et des attributs. On sait alors à quel domaine de définition se rapporte un objet et comment il doit être interprété, selon sa spécification. Le seul fait d'utiliser l'espace de noms xml pour un attribut lang (voir XML Language) permet, par exemple, de définir la langue de codage d'un document (ou d'une portion de document), ainsi que la façon dont l'attribut se propage sur un sous-arbre. Par ailleurs, différencier des espaces de noms permet de faire coopérer, dans un même document, des objets ayant le même nom, mais une signification différente, souvent liée à un modèle de contenu différent. Par exemple, il devient possible, avec les espaces de noms, de faire coopérer, dans un même document, des OASIS Tables et HTML : les deux spécifications utilisent toutes les deux un élément table de plus haut niveau qui sera, par exemple, codé oasis:table et html:table. Cette spécification est une avancée importante car, à partir du moment où beaucoup de formats s'expriment selon XML (voir SVG, par exemple), les risques de "collision de noms" deviennent plus importants et cette spécification prend toute son importance. Le seul regret, dans l'attente des Schema et de leur implémentation dans les outils, est que cette spécification ne vienne qu'au-dessus de XML dans le cadre d'une architecture en couches et que, donc, elle ne soit pas prise en compte dans les DTD. Objectifs L'objectif des espaces de noms est de donner aux éléments et aux attributs des noms uniques, sur Internet. Cette identification permet d'avoir une connaissance mutuelle d'objets, entre plusieurs DTD, sans pour autant qu'il y ait contradiction entre l'interprétation des éléments et, surtout, leurs contenus. L'utilité des espaces de noms est de pouvoir avancer sur les notions de documents composites, quelle que soit la nature des contenus des documents. Par exemple, supposons un document qui contienne ses propres paragraphes (nommés P) et qui doive par ailleurs comporter des fragments de contenus HTML. HTML définissant ses propres paragraphes (aussi nommés P), il peut y avoir contradiction entre les deux définitions. La Tirème SARL - Glossaire. Espace de nom, p. 11/66

12 Spécifications liées à XML : NameSpace notion d'espace de noms lève cette contradiction et permet aux deux éléments de coopérer. L'un, par exemple celui issu du modèle HTML, sera préfixé par son espace de noms : html:p. Cette solution des espaces de noms est très intéressante, dès lors que l'on s'intéresse aux processus de traitements d'un document XML. En effet, grâce aux espaces de noms, il est possible d'avoir des traitements factorisés et dans l'exemple, de faire confiance à un système de consultation HTML, afin d'interpréter directement les objets de l'espace de noms HTML. Il devient alors possible de redéfinir des contextes de traitement, sans pour autant être obligé de modifier tous les attributs des objets de ce contexte. Différents exemples, dans différents domaines, permettent de mieux comprendre l'utilité des espaces de noms : pour le W3C, les espaces de noms servent à faire coopérer ses différentes recommandations ; par exemple, à pouvoir avoir une feuille de styles utilisant en même temps XSLT, HTML et XSL, sans risques de collision de noms ; pour le monde documentaire, si on utilise des modèles de fragments complexes, comme ceux définis pour les graphiques vectoriels (SVG), pour les notations typographiques mathématiques (MathML) ou, encore, pour les tableaux (OASIS Tables), la notion de factorisation de traitement prend toute sa valeur, car afficher un graphique, un tableau ou une équation n'est pas une opération triviale. L'intérêt est donc de pouvoir partager une variété vaste d'outils ; cette factorisation de compréhension et, donc, de traitements s'applique ensuite à tous les domaines. Par exemple, dans les applications EDI, il est intéressant de pouvoir construire une base de données qui contienne les éléments nécessaires à un EDI particulier, ces éléments coopérant avec d'autres, plus localisés à des process internes d'entreprise. Il en va de même, et de façon plus générale, dans le monde du commerce électronique ; enfin, tous les portails s'occupant de syndication de données sont intéressés par les espaces de noms. Cela leur permet, d'une part, de savoir d'où viennent les données qu'ils présentent, et, d'autre part, de se reposer sur le site source pour connaître les moyens de les traiter (par exemple, pour les afficher). Ainsi, un site commercial sera capable d'avoir des documents mixtes contenant une information prix, selon le modèle du portail, et une information commerciale, directement issue du modèle de l'entreprise source, utilisant les outils de cette entreprise pour l'affichage. Principes On peut définir un espace de noms sur n'importe quel élément d'un document : son champs d'utilisation est alors celui du sous-arbre délimité par l'élément. Pour ce faire, il suffit d'ajouter à l'élément, un attribut identifiant l'espace. Par exemple, <monélément xmlns:mutuxml=" DTDProjet" version="1.0"> définit un espace de noms dénommé cette déclaration définit aussi que tous les éléments de cet espace de noms seront préfixés par mutuxml. Ainsi, il sera possible d'écrire : <monélément xmlns:mutuxml=" <p>un paragraphe... de l'espace de noms par défaut</p> <mutuxml:p>un paragraphe... de l'espace de noms mutuxml</p> </monélément>... où deux éléments p cohabitent, appartenant à deux espaces de noms distincts. Dans cet exemple, la seule donnée identifiant l'espace de noms est l'uri! Si, par exemple, un autre document définit un espace de noms avec : xmlns:mutualisationxml=" le Tirème SARL - Glossaire. Espace de nom, p. 12/66

13 Spécifications liées à XML : NameSpace paragraphe <mutuxml:p> de l'exemple ci-devant est bien le même type d'objet que <mutualisationxml:p>, de cette nouvelle définition. Le préfixe est donc peu signifiant, sauf dans le champ de codage syntaxique défini par l'élément sur lequel l'espace est défini. Pour finir, il est fondamental de noter qu'un espace de noms n'a qu'une valeur lexicale : il sert a "désambiguiser" des noms d'objets (éléments ou attributs). En effet, la recommandation n'oblige pas à lier des mots d'un espace de noms à un modèle, qu'il soit sous forme de DTD ou de Schema. Ceci est en outre intéressant, car cela peut s'appliquer aussi aux documents "bien formés". Ceci est gênant dès lors qu'une application utilise des modèles documentaires sous forme de DTD, car il existe peu de choses définies quant à l'intégration de modèles liés à un espace de noms. Recommandations(s) Les espaces de nommage dans XML 1.1 Recommandation, version , du Document sur Namespaces in XML Recommandation, version 1.1 (Third Edition), du Document sur Namespaces in XML 1.1 Requirements Projet en cours, version 1.1, du Document sur Uniform Resource Names (URN) Namespace Definition Mechanisms Projet en cours, version , du Document sur Tirème SARL - Glossaire. Espace de nom, p. 13/66

14 Spécifications liées à XML : Schema Schema, Schéma Rédaction : Pierre Attar Recommandation(s) liée(s) : DSDL - DTD - Infoset - RELAX NG - XML - XML Base - XMI - XPath - WSDL Partant du principe que les DTD issues de la Recommandation XML ne permettaient pas de contraindre suffisamment les données et les structures, partant également du principe qu'il n'y avait aucune raison pour que les modèles ne soient pas codés sous forme XML, Schema propose une méthode de réalisation de modèles, alternative aux DTD. Cette spécification, plus moderne de conception que les DTD, permet d'écrire des modèles de façon plus efficace. De fait, et dans son utilisation, cette spécification supplante maintenant l'utilisation des DTD et, hors environnement contractuel spécifique, il reste peu d'endroits où de nouveaux projets utilisent des DTD. L'avenir de cette spécification? Trouver une intégration harmonieuse avec la spécification DSDL (RELAX NG) qui a un champ de recouvrement important (voir par exemple la dernière version de DocBook qui préfère se reposer sur RELAX NG plutôt que d'utiliser les DTD ou les Schema. Objectifs L'objectif des Schema est de définir des contraintes sur des classes de documents conformes à un même modèle. À la différence des DTD, qui ne définissaient que les relations entre les différents composants d'un document, les Schema peuvent typer les données et, par là-même, en documenter leur sens et, donc, leur utilisation. L'objectif n'est pas d'avoir un langage extensible permettant d'exprimer n'importe quelle contrainte : seules, les contraintes consensuelles sont exprimables. Celles-ci doivent pouvoir être validées par un parser et être mises en jeu pour assister à la création d'information, surtout dans les éditeurs. Enfin, les Schema ne s'intéressent pas à la validation d'un document XML (d'un fichier) en tant que tel. Un outil validant se basera sur la représentation en arbre d'objets typés et valués, désérialisée selon le standard Infoset. Cette volonté permet de rendre le processus de validation indépendant d'une syntaxe de codage quelconque d'un document. Principes Les spécifications sur les Schema sont divisées en deux parties : une sur les structures et une sur les types de données. Pour mieux comprendre ces deux recommandations, une introduction est aussi proposée. Tirème SARL - Glossaire. Schéma, p. 14/66

15 Spécifications liées à XML : Schema D'un point de vue structurel, un Schema se définit comme étant l'assemblage, sous forme d'arbre XML, d'un ensemble de composants. Il en existe 12, dont les principaux sont : composants de définition de types, les simples ou les complexes : ils permettent de typer des éléments pour leur affecter un modèle de contenu. Il en va de même pour les attributs. Ainsi, une adresse de livraison et une adresse de facturation relèveront toutes deux d'un même type adresse. C'est en utilisant les types simples que seront définis, dans la partie "datatypes" (), des types de base comme les chaînes de caractères, les nombres, les URI ou encore toutes sortes de dates. Une définition de "type" peut être réalisée en restriction ou en extension d'une définition existante. Par exemple, le type adresse précédent peut être restreint à des adresses françaises, en jouant sur la définition de la valeur du code pays. Une limite du mécanisme d'extension est que l'on ne peut rajouter des éléments qu'à la fin d'un type pré-existant et que l'on ne peut pas les modifier. D'un point de vue programmation, les notions de types de données permettent de se reposer sur ces types de données pour effectuer des traitements partagés à différents éléments du même type. Ceci simplifie beaucoup les méthodes de programmation, tout en nécessitant d'avoir toujours accès au modèle, en même temps que l'on effectue les traitements. composants de déclaration : éléments, attributs et notations Ces composants permettent de déclarer, comme avec les DTD, des éléments, avec leurs modèles de contenus, et ainsi que des attributs. Pour ce faire, et dans le but de factorisation précédemment expliqué, les déclarations peuvent se reposer sur des composants de définition de type. composants groupes : pour la factorisation d'informations de modèles de contenus ou d'attributs. Ces composants permettent de définir des modèles qui seront souvent réutilisés, soit pour définir des composants de déclaration, soit pour définir des composants de définition de types. Dans les DTD traditionnelles, ces groupes étaient formalisés par des entités paramètres, qui permettaient, par exemple, de définir tous les composants blocks (paragraphes, listes, remarques, etc.) nécessaires lors de la définition de modèles de contenus. D'un point de vue typage de données, la spécification propose un ensemble important de types et une façon d'étendre ces types, pour une application donnée, à des choses plus complexes. Finalement, un Schema est un modèle d'information défini sous forme électronique (comme l'était une DTD), mais avec des outils de modélisation plus puissants. Dans la sphère XML, le Schema pourra être utilisé comme outil de validation interactif de données, lors de la création de celles-ci, dans un éditeur, voire, plus tard, dans des XForms, sur Internet. Des limites? En lisant les listes de discussion, on peut trouver beaucoup de limitations exprimées sur ces possibilités de validation. Par exemple, d'aucuns parlent du fait de ne pas pouvoir valider un modèle de contenu en fonction d'une valeur d'attribut d'un élément englobant. C'est toute l'ambiguïté de l'utilisation des Schema qui est alors posée : est-ce un langage de programmation permettant d'exprimer des contraintes de validation ou estce un langage de définition de modèles? En avancant dans le sens de l'utilisation de modèles pour des activités d'ingéniérie, et grâce aux nouvelles possibilités de typage, on peut avoir plusieurs DTD et Schema, fonctionnant sur une même classe de documents et, par des définitions de typage, déclencher dessus des processus applicatifs ad hoc. C'est ce qu'avaient fort bien compris les concepteurs de l'icadd [sur internet : pour rendre accessibles les documents aux non-voyants. Dans leurs spécifications [sur internet : Tirème SARL - Glossaire. Schéma, p. 15/66

16 Spécifications liées à XML : Schema cover/gen-apps.html#icadd], ils expliquent comment, en jouant seulement sur les attributs d'une DTD, on peut ajouter automatiquement de l'information aux documents, au moment de leur parsing, pour le plus grand profit des non-voyants qui pourront parcourir n'importe quel type de documents en se basant sur ces repères. Informations connexes Liste des types définis dans les schémas. Catégorie Type Signification Modèles de contenus Attributs Chaînes de caractères string Chaîne O O Name Nom XML O O QName Nom XML qualifié O O NCName Nom XML non qualifié O O Nombres decimal Décimal O O boolean Valeur booléenne O O float 16bit floating point number O O double 32bit floating point number O O integer Infinite accuracy integer O O nonpositiveinteger Infinite accuracy integer less than 0 O O negativeinteger Infinite accuracy integer less than 0 O O long 64bit integer O O int 32bit integer O O short 16bit integer O O byte 8bit integer O O nonnegativeintegerinfinite accuracy integer more than 0 O O positiveinteger Infinite accuracy integer more than 1 O O unsignedlong Unsigned 64bit integer O O unsignedint Unsigned 32bit integer O O Tirème SARL - Glossaire. Schéma, p. 16/66

17 Spécifications liées à XML : Schema Catégorie Type Signification Modèles de contenus Attributs unsignedshort Unsigned 16bit integer O O unsignedbyte Unsigned 8bit integer O O Temps timeinstant Date+Time O O timeduration Progress time O O recurringinstant O O date Date O O time Time O O XML1.0 compatibilité ID XML1.0 ID - O IDREF XML1.0 IDREF - O ENTITY XML1.0 ENTITY - O NOTATION XML1.0 NOTATION - O IDREFS XML1.0 IDREFS - O ENTITIES XML 1.0 ENTITIES NMTOKEN XML 1.0 NMTOKEN NMTOKENS XML 1.0 NMTOKENS - O - O - O Autres. binary Binary O O urireference URI O O language Language O O Recommandations(s) XML Schema Part 1: Structures Recommandation, version Version 1.1, du Document sur XML Schema Part 2: Datatypes Recommandation, version Version 1.1, du Document sur XML Schema Part 0: Primer Recommandation, version Second Edition, du Document sur XML Schema tome 1 : Structures Recommandation, version , du Document sur XML Schema tome 0 : Introduction Tirème SARL - Glossaire. Schéma, p. 17/66

18 Spécifications liées à XML : Schema Recommandation, version , du Document sur Associating Schemas with XML documents 1.0 (First Edition) Projet en cours, version 1.0 ed. 3, du 9 Octobre 2012 Document sur Schema-Related Markup in Documents Being Validated Recommandation, version , du Document sur XML Schema: Formal Description Projet en cours, version , du Document sur XML Schema: Component Designators Projet en cours, version , du Document sur Requirements for XML Schema 1.1 Projet en cours, version 1.1, du Document sur Semantic Annotations for WSDL and XML Schema Recommandation, version , du Document sur Tirème SARL - Glossaire. Schéma, p. 18/66

19 Spécifications liées à XML : DTD DTD, Définition de type de document Rédaction : Pierre Attar Recommandation(s) liée(s) : DSDL - RELAX NG - Schema - XML - XMI La notion de DTD est partie intégrante de la spécification XML, héritière de SGML, mais délestée de beaucoup de fonctionnalités aujourd'hui superflues. Pour des parsers "validants", la notion de DTD dans XML permet de définir un modèle de données qui servira ensuite à valider, de façon électronique, toutes les instances supposées être conformes au modèle. Pour des parsers "non validants", la notion de DTD sert simplement à fournir un réservoir permettant de décrire où sont des fichiers qui doivent être inclus dans les documents XML au travers d'entités générales. Le modèle lui-même permet de spécifier une hiérarchisation d'objets typés et valués selon des attributs. Il permet encore, au travers des entités paramètres, de modulariser l'écriture des DTD. Ce modèle est largement implémenté par tous les outils de création et de modification de documents issus du monde SGML. Objectifs L'objectif d'une DTD est de pouvoir définir un modèle de données formel, sous forme électronique, afin que les outils puissent valider, de façon automatisée, la conformité d'une classe de documents XML à ce modèle. Cette activité est nécessaire pour tous les processus de traitement de l'information XML, qui doivent pouvoir présupposer de ce qui est contenu dans un document. Elle est aussi extrêmement utile pour les processus d'édition interactive de documents XML qui, s'autoadaptant à une DTD, pourront aider l'utilisateur dans ses activités de création et de modification de structure et dans ses activités de validation. Par ailleurs, l'objectif d'une DTD est de pouvoir définir tout ce qui est nécessaire comme ressources à tous les documents d'une classe donnée. Si un document XML doit inclure des fragments externes, ceux-ci seront définis et identifiés de façon formelle au sein de la DTD, afin de pouvoir ensuite être appelés au sein des documents (mécanisme des entités parsées générales ). Tirème SARL - Glossaire. Définition de type de document, p. 19/66

20 Spécifications liées à XML : DTD Si le modèle devait recenser tous les fragments appelables dans un document, le fichier issu de ce modèle deviendrait extrêmement imposant et surtout très difficile à maintenir. Du coup, les concepteurs de la recommandation autorisent l'utilisation de DTD, complétées de déclarations n'affectant qu'un seul document : on parle alors des entités parsées générales de l'internal Entity. Principes Modèles de documents Une DTD permet de définir une organisation d'éléments entre eux et des typages de ces éléments via des notions d'attribut (de valuation). Plus précisément, une DTD définit un modèle d'organisation hiérarchique de documents XML en utilisant : des éléments, organisés hiérarchiquement. Pour ce faire, un modèle de contenu est défini pour chaque élément. Le modèle de contenu peut faire appel aux notions d'organisation d'éléments entre eux (séquence, choix ou agrégat), en utilisant des indicateurs d'occurrence (optionabilité, répétabilité). Il peut se réduire aussi à de simples caractères. Lorsqu'il définit un regroupement de caractères et d'éléments, on parle alors de contenus mixtes (mixed contents). Dans ce dernier cas, des règles très strictes sont définies ; des attributs, qui permettent de valuer un élément. Les attributs sont typés ou énumérés. Ils peuvent avoir une valeur fixe par défaut ou laissée au libre choix des outils de traitement ; d'autres informations qui peuvent être ajoutées aux éléments et aux attributs, telles les notations, les entités paramètres ou générales, etc. La syntaxe utilisée pour écrire des DTD est une syntaxe ad hoc. Par exemple, déclarer un élément article contenant une en-tête et un corps s'écrira : <!ELEMENT article (tete, corps) > Cette syntaxe est concise et simple, mais présente le grand désavantage de ne pas être celle utilisée pour écrire des documents XML et, donc, de ne pas pouvoir être analysée par des outils XML standard. C'est une des raisons qui amène à la définition des nouveaux modèles Schema. DTD et entités Les DTD permettent aussi de définir des entités qui implémentent le mécanisme d'inclusion cher à tous les langages de programmation. Générale et parsée, l'entité définit des fragments XML que le parser doit inclure lors de la validation d'un document (que ce soit pour vérifier s'il est "bien formé" ou s'il est valide au regard de son modèle) ; le contenu du fragment appelé doit lui-même être un arbre bien formé. Si elle est paramètre, l'entité définit des fragments de DTD à intégrer lors du parsing de la DTD elle-même. L'entité peut être externe au document. Par exemple : <!ENTITY fichier "-//MUTU-XML//Un fichier externe//fr" " définit une entité générale (un fragment XML bien formé), qui se nomme -//MUTU-XML// Un fichier externe//fr et qui se trouve à l'adresse fragment.xml. L'entité peut être interne. Par exemple : <!ENTITY xml "extended Markup Language"> Tirème SARL - Glossaire. Définition de type de document, p. 20/66

21 Spécifications liées à XML : DTD définit un fragment XML directement dans la déclaration interne liée au document. Ce mécanisme d'inclusion est extrêmement utile pour toutes les opérations de modularisation et de réutilisation. Il souffre cependant d'une lacune, qui est l'obligation de définir dans le document, d'une part, un nom logique et, d'autre part, une localisation physique. Cette lacune existait aussi dans les premiers temps de SGML et était fort contraignante, dès lors que des documents étaient échangés et que les organisations de fichiers n'étaient pas les mêmes chez l'émetteur et le récepteur d'un document. (Par exemple, un développeur de site Web utilisera souvent des adresses basées sur ses propres disques locaux, voire basées sur son site de test. Lorsqu'il publiera l'information, les adresses seront alors basées sur le site réel.) Recommandations(s) Extensible Markup Language (XML) 1.1 (Second Edition) Recommandation, version 1.1, du Document sur Tirème SARL - Glossaire. Définition de type de document, p. 21/66

22 Spécifications liées à XML : DSDL DSDL, Document Schema Definition Languages Rédaction : Pierre Attar Recommandation(s) liée(s) : DTD - RELAX NG - Schema - XMI «The objective of developing ISO/IEC Document Schema Definition Languages (DSDL) is to create a framework within which multiple validation tasks of different types can be applied to an XML document in order to achieve more complete validation results than just the application of a single technology.» DSDL.ORG [sur internet : Objectifs Information descriptive non finalisée ; n'hésitez pas à nous contacter pour rédiger et/ou maintenir cette information à jour. Recommandations(s) Document Schema Definition Languages (DSDL) Part 1: Overview Recommandation, version ISO/IEC CD , du Document sur CSNUMBER=37606&scopelist=ALL Document Schema Definition Languages (DSDL) Part 2: Regular-grammar-based validation -- RELAX NG Recommandation, version ISO/IEC :2003, du Document sur CSNUMBER=37605&scopelist=ALL Document Schema Definition Languages (DSDL) Part 3: Rule-based validation -- Schematron Recommandation, version ISO/IEC CD , du Document sur CSNUMBER=40833&scopelist=ALL Document Schema Definition Languages (DSDL) Part 4: Namespace-based Validation Dispatching Language -- NVDL Recommandation, version ISO/IEC FCD , du Document sur CSNUMBER=38615&scopelist=ALL Tirème SARL - Glossaire. Document Schema Definition Languages, p. 22/66

23 Spécifications liées à XML : DSDL Document Schema Definition Languages (DSDL) Part 5: Extensible Datatypes Recommandation, version ISO/IEC WD , du Document sur CSNUMBER=41006&scopelist=ALL Document Schema Definition Languages (DSDL) Part 6: Path-based integrity constraints Recommandation, version ISO/IEC WD , du Document sur CSNUMBER=41007&scopelist=ALL Document Schema Definition Languages (DSDL) Part 7: Character repertoire validation Recommandation, version ISO/IEC WD , du Document sur CSNUMBER=41008&scopelist=ALL Document Schema Definition Languages (DSDL) Part 8: Declarative document manipulation Recommandation, version ISO/IEC WD , du Document sur CSNUMBER=40836&scopelist=ALL Document Schema Definition Languages (DSDL) Part 9: Datatype- and namespace-aware DTDs Recommandation, version ISO/IEC WD , du Document sur CSNUMBER=41009&scopelist=ALL Document Schema Definition Languages (DSDL) Part 10: Validation Framework Recommandation, version ISO/IEC WD , du Document sur CSNUMBER=41011&scopelist=ALL Compact Syntax Recommandation, version ISO/IEC :2003/FPDAmd 1, du Document sur CSNUMBER=40774&scopelist=ALL Document Schema Definition Languages (DSDL) DSSSL library for complex compositions Recommandation, version ISO/IEC TR 19758:2003, du Document sur CSNUMBER=33896&scopelist=ALL RELAX NG Specification Recommandation, version , du Document sur Tirème SARL - Glossaire. Document Schema Definition Languages, p. 23/66

24 Spécifications liées à XML : RELAX NG RELAX NG, Regular Language description for XML NG Recommandation(s) liée(s) : DSDL - DTD - Schema - XMI RELAX NG est maintenant partie intégrante de DSDL : deuxième section. Voir cette entrée pour toutes les informations sur RELAX NG. Objectifs Voir DSDL. Recommandations(s) RELAX NG Specification Recommandation, version , du Document sur Tirème SARL - Glossaire. Regular Language description for XML NG, p. 24/66

25 Spécifications liées à XML : UML UML, Unified Modeling language Rédaction : Pierre Attar Recommandation(s) liée(s) : XMI «The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems.» Source. Unified Modeling Language (UML), version 1.5 Objectifs Information descriptive non finalisée ; n'hésitez pas à nous contacter pour rédiger et/ou maintenir cette information à jour. Recommandations(s) Unified Modeling Language (UML) Recommandation, version 1.5, du Document sur UML 2.0 Infrastructure Specification Recommandation, version 2.0, du Document sur UML 2.0 Superstructure Specification Recommandation, version 2.0, du Document sur UML 2.0 Diagram Interchange Specification Recommandation, version 2.0, du Document sur UML 2.0 OCL Specification Recommandation, version 2.0, du Document sur Tirème SARL - Glossaire. Unified Modeling language, p. 25/66

26 Spécifications liées à XML : XMI XMI, XML Metadata Interchange Rédaction : Pierre Attar Recommandation(s) liée(s) : UML - DTD - Schema - RELAX NG - DSDL «XMI is a widely used interchange format for sharing objects using XML. Sharing objects in XML is a comprehensive solution that build on sharing data with XML. XMI is applicable to a wide variety of objects: analysis (UML), software (Java, C++), components (EJB, IDL, Corba Component Model), and databases (CWM). Over 30 companies have XMI implementations.» Source. XML Metadata Interchange Specification, version 2.0 Objectifs Information descriptive non finalisée ; n'hésitez pas à nous contacter pour rédiger et/ou maintenir cette information à jour. Recommandations(s) XML Metadata Interchange Specification Recommandation, version 2.0, du Document sur Tirème SARL - Glossaire. XML Metadata Interchange, p. 26/66

27 Spécifications liées à XML : Canonical Canonical, XML Canonical Rédaction : Pierre Attar Cette spécification décrit ce que doit faire un "canoniseur" XML pour produire une représentation physique (la forme canonique) d'un document XML, qui ne change pas quelles que soient les variations syntaxiques de l'entrée XML. Avec cette spécification, si un document XML est changé par une application, mais si sa forme canonique XML n'a pas changé, le document changé et le document initial peuvent être considérés comme équivalents par les applications les utilisant. Cette spécification est mineure dans l'ensemble de celles issues du W3C. Elle sera certainement utilisée dans des ingénieries logicielles très spécifiques, dès lors qu'il sera nécessaire de s'intéresser à des versions de documents. Objectifs L'objectif de cette spécification est de pouvoir s'appuyer sur une forme XML canonique pour définir l'équivalence de deux documents XML, de façon indépendante des variations syntaxiques qui peuvent avoir été introduites, comme des variations de codage de caractères (on se souviendra que XML accepte différents codages), d'ordre de définition d'attributs, de syntaxe d'écriture des éléments empty, etc. Cette notion d'équivalence est nécessaire, dès lors que l'on introduit, par exemple, des notions de signature de document (XML-Signature) ou dès lors que l'on s'intéresse, dans XPath, à des positions relatives d'objets les uns par rapport aux autres. Cette spécification est mineure : son utilité n'est définie que pour des environnements applicatifs extrêmement précis. Elle n'a pas de volonté de devenir une des recommandations de base du W3C, comme peuvent l'être XPath ou XSLT. Principes Un "canoniseur" peut générer un document XML "bien formé" ; il peut aussi générer une partie de document. Dans ce dernier cas, la spécification de ce qui doit être canonisé est réalisée en utilisant une expression issue du langage XPath. D'un point de vue fonctionnel, le codage de caractères du document généré est le codage UTF-8. Basée sur le modèle de donnée de XPath, le reste de la spécification s'intéresse surtout à des notions d'ordonnancement d'objets (les attributs, par exemple) et à des notions de normalisation d'attributs et de "retour-chariot". Tirème SARL - Glossaire. XML Canonical, p. 27/66

28 Spécifications liées à XML : Canonical Canonical définit la spécification d'un outil, de ce qu'il doit interpréter dans un document et ce qu'il doit générer. Cette spécification n'a pas pour objectif d'établir une méthode définissant l'équivalence de deux documents XML dont les formes canoniques sont identiques : elle se contente de donner aux applicatifs les moyens de le faire. Recommandations(s) XML canonique Recommandation, version 1.0, du Document sur Canonical XML Recommandation, version 1.1, du Document sur XML Canonicalization Requirements Note, version , du Document sur La canonisation XML exclusive Recommandation, version 1.0, du Document sur Exclusive XML Canonicalization Recommandation, version 1.0, du Document sur Tirème SARL - Glossaire. XML Canonical, p. 28/66