<XML Pôt Pourri/>

<XML Pôt Pourri/> Arnaud Sahuguet University of Pennsylvania – Tropea Inc. Penn DatabaseResearch Group

Au Menu • XML aujourd’hui • Les DTDs : une mauvaise bonne idée • La relève : XML-Schema et le Schematron • La boîte à outils XML • W4F • Avertissement 1: cet exposé est un survol qui ne prétend pas entrer dans les détails. L’auditeur est renvoyé aux documents de référence pour de plus amples informations. • Avertissement 2 : les opinions présentées dans cet exposé n’engagent que leur auteur.

XML Aujourd’hui • XML est utilise pour • Messages (XML-RPC) • Contenu textuel (HTML, WML) • Données (FinXML, BioML) • Documents (DocBook) • Sérialisation de composants logiciels (Java Beans) • recettes de cuisines Bref, tout et n’importe quoi!

XML pour pallier les carences HTML • En utilisant XML, les fournisseurs de contenu peuvent distinguer fond et forme. Contenu XML XSL HTML(Web-TV) Wireless Markup Language HTML (accessiblity) HTML http://www.wapforum.org/docs/technical/wml-30-apr-98.pdf

XML-RPC • XML-RPC est un protocole RPC qui fonctionne au-dessus de TCP-IP (alternative à CORBA) • Un message XML-RPC is une requête HTTP POST. Le corps de la requête est écrit en XML. La procédure est exécuteé sur le serveur et le résultat est renvoyé sous forme XML. • Les paramètres peuvent être des scalaires, des chaînes de caractères, des nombres, des dates, etc.; il peut s’agir aussi de structures plus complexes (tuple, liste, etc.). • XML-RPC hérite de tous les avantages liés à HTTP tels que SSL.

XML-RPC : un aperçu POST /RPC2 HTTP/1.0 User-Agent: Frontier/5.1.2 (WinNT) Host: betty.userland.com Content-Type: text/xml Content-length: 181 <?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall> HTTP/1.1 200 OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 17 Jul 1998 19:55:08 GMT Server: UserLand Frontier/5.1.2-WinNT <?xml version="1.0"?> <methodResponse> <params> <param> <value><string>South Dakota</string></value> </param> </params> </methodResponse>

Les p’tites annonces à la sauce XML • But: “établir un standard qui permette aux annonceurs de fournir et aux éditeurs de partager et structurer de l’information qui puisse être publiée sous un format qui soit indépendent du medium.” • Avantages • format indépendent • terminologie unique • Dans ce cas, la DTD est utilisée comme une ontologie. En voici un aperçu :

D’autres applications intéressantes • EDI • E-commerce • Informatique Médicale (Electronic Patient Record) • Signature de documents XML (cryptographie) • XML et Java beans • XML utilisé pour la sérialisation de composants Java • beans insérés dans des documents XML (contenu dynamique, réactif) • J’en passe, et des meilleures ...

Beacoup de bruit pour rien ? • XML est l’ASCII du 21ème siècle • Facile à lire et à comprendre pour l’humain • Facile à lire pour la machine • Souplesse de structure • Un parseur unique pour tous les documents XML • Mais XML, c’est peut-être aussi une sémantique ? “XML = HTML with an attitude”

Toute la vérité sur les DTDs

Qu’est-ce qu’une DTD[ISO 8879] A document type definition specifies: • the generic identifiers (GIs) of elements that are permissible in a document of this type • for each GI, the possible attributes, their range of values and defaults • for each GI, the structure of its contents, including: • which element can occur and in what order • whether text characters can occur • whether non character data can occur • The purpose of a DTD is to permit to determine whether the mark-up for an individual document is correct and also to supply markup that is missing, because it can be inferred unambiguously from other mark-up present.

En gros ça veut dire ... … que le but d’une DTD est double : • permettre la validation d’un document • aider un parseur à parser un document Je ne suis pas sûr que ce soit ce qui nous intéresse.

DTD (suite) • A DTD contient • des déclarations délements • des déclarations d’attributes • des entity references • des entity parameters • des notations • des processing instruction (<? …. ?>) • Elements sont définis via des content-model [?+*,] • Attributes peuvent être CDATA, NMTOKEN • Attributes sont facultatifs ou obligatoires (IMPLIED,FIXED)

Un petit exemple <!NOTATION jpg PUBLIC ‘-//JPG’> <!ENTITY folder SYSTEM “folder.jpg” NDATA jpg> <!ENTITY bookmark SYSTEM “bookmark.jpg” NDATA jpg> <!ENTITY % local.node.att ""> <!ENTITY % local.url.att ""> <!ENTITY % local.nodes.mix ""> <!ENTITY % node.att "id ID #IMPLIED added CDATA #IMPLIED %local.node.att;"> <!ENTITY % url.att "href CDATA #REQUIRED visited CDATA #IMPLIED modified CDATA #IMPLIED %local.url.att;"> <!ENTITY % nodes.mix "bookmark|folder|alias|separator %local.nodes.mix;"> <!ELEMENT xbel (title?, info?, desc?, (%nodes.mix;)*)> <!ATTLIST xbel %node.att; version CDATA #FIXED "1.0"> <!ELEMENT title (#PCDATA)> <!ELEMENT info (metadata+)> <!ELEMENT metadata EMPTY> <!ATTLIST metadata owner CDATA #REQUIRED> <!ELEMENT folder (title?, info?, desc?, (%nodes.mix;)*)> <!ATTLIST folder %node.att; folded (yes|no) #FIXED 'yes' > <!ELEMENT bookmark (title?, info?, desc?)> <!ATTLIST bookmark %node.att; %url.att;> <!ELEMENT desc (#PCDATA)> <!ELEMENT separator EMPTY> <!ELEMENT alias EMPTY> <!ATTLIST alias ref IDREF #REQUIRED>

DTDs : le sondage • La genèse du sondage • Peter Buneman intéressé par le non-déterminisme des content-model • Arnaud intéressé par les propriétés des DTDs qui sont vraiment utilisées en pratique (cf. W4F un peu plus tard) • Méthodologie • la cueillette (xml.org) • le nettoyage (à la main) • la normalisation (expansion des entities) • la distillation (qques scripts et programmes Java) • la visualisation

1. DTDs souvent incorrectes • La majorité des DTDs sont incorrectes • elements qui manquent • erreurs de syntaxe • incompatibilté dans la déclaration des attributes Cést apparemment du au fait que : (1) les gens ne comprennent pas les DTDs et (2) le standard est flou sur ce qui est obligatoire et ce qui ne l’est pas. Mais si les DTDs sont incorrectes, cela vaut-il la peine de valider les documents ? • Une DTD n’est pas toujours représentée par un graphe connexe : racines multiples, utilisation de ANY

2. DTDs : le système D • Codage des tuples : • <a,b,c> est souvent représenté par (a|b|c)*, du fait de l’absence de l’opérateur & • La syntaxe correcte : • SGML: ( a & b & c ) • XML: (a,b,c) | (a,c,b) | (b,c,a) | (b,a,c) | (c,b,a) | (c,a,b) • Héritage : • Abus de l’opérateur | • Parameter entities pour représenter la notion d’héritage (syntactique)

3. DTDs : la mauvaise graisse • Attribut comme NMTOKEN • IDREF • Notations • Processing instructions Personne ne les utilise parce que personne ne comprend à quoi ils servent.

DTDs : zoom • FinXML DTD

DTDs : ce qui ne va pas • trop orientées document • DTDs créées à l’origine pour le traitement de texte • trop simples et trop compliquées à la fois • trop limitées pour représenter des structures complexes • aucun typage pour IDREF • pas de notion de tuple • pas de notion de typage, de sous-typage et d’héritage • ambiguité au niveau des content-models • trop de façon différentes de représenter la même chose • noms globaux et pas locaux • pas de mécanismes pour gérer les versions, permettre l’extension et l’évolution

Les questions auxquellles le sondage ne peut pas répondre • Les gens utilisent-ils les DTDs ? • well-formed vs valid documents • Comment les DTDs sont-elles instanciées en pratique ? • que signifie +, *, etc.

Analogie XML / Langage de programmation validation entity reference entity parameter ANY IDREF DTD conditional section key entities namespace type-checking constants macros void* void* header file #ifdef standard library namespace Ce qu’il manque : inférence de type, polymorphisme, modules, etc.

Analogy XML/ProgLang (suite) XML Functional Object Oriented ========================================= | variant, union type abstract class , record with order ordered inheritance & record inheritance ? option null +/* list list

Solutions immédiates • Suppression de ANY • DTD = graphe connexe avec une unique racine • Support pour “&” • Nécessité de valider les DTDs • Et on oublie • notations • conditional sections • ID, IDREF

Wait a minute • Il ne sert à rien de se prendre la tête avec les DTDs puisque de toutes façons, leurs jours sont comptés : • la plupart des vendeurs sont DTD-agnostic • Microsoft utilise qqchose d’autres • de nouveaux standards arrivent, dont le but avoué est de remplacer les DTDs (XML-Schema par exemple)

CdC pour les Nlles DTDs • validation de documents • information structurelle pour stockage optimal sur disque • compression par exemple • optimisation d’expressions de chemins • documentation • mécanisme d’extension et de versioning • parsing efficace • etc.

XML Schema • le nom est très mal choisi, mais c’est comme ça • mission : remplacer les DTDs • soutenu par les principaux acteurs • décrit la structure d’un document XML via une syntaxe XML • plus expressif que les DTDs • types atomiques (entier, chaine, date, caractère, etc.) • sémantique plus précise que le content-model • mécanisme pour restreindre et étendre les schemas • représentation de constraintes (key et foreign key) • la version finale de 1.0 devrait être disponible à l’heure où je vous parle.

XML Schema • Comme pour les DTDs, il sera intéressant de voir comment et pour quoi ils sont utilisés. • XML-Schema = data-types + schema • XML Schema met l’accent sur le fait que XML va être utilisé pour transmettre des données entre programmes. Plus de place pour l’être humain. • Danger : mettre trop d’information dans le Schema • Quelques aspects très intéressants : • dérivation de type • restriction de type (pb de subsumption d’expressions régulières) • contraintes

XML Schema • Contraintes • key + foreign-key pour la version 1.0 • des contraintes plus générales (inclusion, etc.) à l’avenir • les contraintes sont exprimées par des expressions de chemin XPath • qques problèmes intéressants de décidabilité

XML-Schema : un exemple • Pour plus de détails, www.w3c.org

Une autre approche • XML Schema et DTDs sont plutôt top-down : un document XML se décrit en partant de la racine.Le problème est qu’il faut définir la structure de tous les composants du document • Dans certains cas, il est plus simple de définir une structure locale, avec une approche bottom-up.Un bon moyen est de définir des contraintes sur la structure du document.

Schematron (Rick Jelliffe) • Principe: encoder la structure en utilisant des contraintes de chemin sur l’arbre du document (via XPath) • On oublie l’approche grammaire et on pense motif d’arbre • Sémantique • on trouve un contexte de noeud d’arbre dans le document • on vérifie localement les contraintes • Détails • dans l’ esprit de XSL-T (motifs, règles). Implémentation via XSL-T. • repose sur des chemins XPath • Avantage • la définition d’un “schema” peut être +/- fine (granularité) • permet l’évolution du schema

Exemple  <!ELEMENT schema ( title?, pattern+ )> <!ELEMENT assert ( #PCDATA )> <!ELEMENT pattern ( rule+ )> <!ELEMENT report ( #PCDATA)> <!ELEMENT rule ( assert | report )+> <!ELEMENT title ( #PCDATA )> <!ATTLIST schema ns CDATA #IMPLIED > <!ATTLIST assert test CDATA #REQUIRED > <!ATTLIST pattern name CDATA #REQUIRED see CDATA #IMPLIED > <!ATTLIST report test CDATA #REQUIRED> <!ATTLIST rule context CDATA #REQUIRED > <schema> <title>Demonstration Patterns for the Schematron Itself</title> <pattern name="The Open Schematron DTD 1.0"> <rule context="schema"> <assert test="pattern">A schema element should contain at least one pattern elements.</assert> </rule> <rule context="pattern"> <assert test="rule">A pattern element should contain at least one rule elements.</assert> <assert test="@name">A pattern element should have an attribute called name.</assert> </rule> <rule context="rule"> <assert test="assert | report ">A rule element should contain at least one assert or report elements.</assert> <assert test="@context">A rule element should have an attribute called context. This should be an XPath for selecting nodes to make assertions and reports about.</assert> </rule> <rule context="assert"> <assert test="@test">An assert element should have an attribute called test. This should be an XSLT expression.</assert> </rule> <rule context="report"> <assert test="@test">A report element should have an attribute called test. This should be an XSLT expression.</assert> </rule> </pattern> </schema>

Exemple (suite) <schema> <pattern name="The Closed Schematron DTD 1.0a"> <rule context="schema"> <assert test="count(*) = count(pattern | title)">Unexpected element(s) found: a schema element should contain only pattern elements.</assert> <assert test="pattern">A schema element should contain at least one pattern element.</assert> <report test="phase">The element phase is only used in the 1.2 DTD</report> </rule> <rule context="pattern"> <assert test="count(*) = count(rule)">Unexpected element(s) found: A pattern element should contain only rule elements.</assert> <assert test="rule">A pattern element should contain at least one rule elements.</assert> <assert test="@name">A pattern element should have an attribute called name.</assert> </rule> <rule context="rule"> <assert test="count(*) = count(assert | report ) ">Unexpected element(s) found: a rule element should contain only assert and report elements.</assert> <assert test="assert | report ">A rule elemement should contain at least one assert or report elements.</assert> <assert test="@context">A rule element should have an attribute called context. This should be an XPath for selecting nodes to make assertions and reports about.</assert> <report test="key">The element key is only used in the 1.2 DTD</report> </rule> <rule context="assert"> <assert test="@test">An assert element should have an attribute called test. This should be an XSLT expression.</assert> <report test="name">The element name is only used in the 1.1 DTD</report> </rule> <rule context="report"> <assert test="@test">A report element should have an attribute called test. This should be an XSLT expression.</assert> <report test="name">The element name is only used in the 1.1 DTD</report> </rule> </pattern> </schema>

Schematron vs XML-Schema • Top-down vs Bottom-up • L’approche Schematron permet de définir la structure du document au fur et à mesure -- comme pour stylesheet.On peut faire pareil avec XML-Schema en utilisant les mécanismes de restriction et déxtension. • Un inconvénient du Schematron est que les règles sont éparpillées alors que XML-Schema groupe les structures. • Le Schematron permet de définir pratiquement n’importe quel type de contraintes (on peut typer les IDREFs par exemple. Laissé en exercice :-)

Ze Big Picture (par Rick Jelliffe)

Boîte à outils pour XML

De quoi a-t-on besoin ? • Stockage de XML • relationnel, oo, représentation canonique, DOM persistent • compression (XMILL Penn/AT&T) • Langage de requête • top/down • à base de règles (XSL-T) • compatible avec une approche “données” ET une approche “document” (text algebra) • Conversion • depuis/vers relationnel, oo, html • Détection de changement (à la Unix diff) • XML-Diff (Penn)

XSL-T  <xsl:template match="*"> <xsl:copy> <xsl:apply-templates/> </xsl:copy> </xsl:template>  <xsl:template match="@*"> <xsl:copy/> </xsl:template>

XSL-T  <xsl:template match="MOVIE"> <xsl:element name="FILM"> <xsl:apply-templates select="@*|node()"/> </xsl:element> </xsl:template>  <xsl:template match="ACTORS"> <xsl:element name="ACTEURS"> <xsl:apply-templates select="@*|node()"/> </xsl:element> </xsl:template>  <xsl:template match="ACTOR"> <xsl:element name="ACTEUR"> <xsl:apply-templates select="@*|node()"/> </xsl:element> </xsl:template>  <xsl:template match="FirsName"> <xsl:element name="Prenom"> <xsl:apply-templates select="@*|node()"/> </xsl:element> </xsl:template>  <xsl:template match="LastName"> <xsl:element name="Nom"> <xsl:apply-templates select="@*|node()"/> </xsl:element> </xsl:template>  <xsl:template match="MOVIE/@TITLE"> <xsl:attribute name="TITRE"> <xsl:value-of select="."/> </xsl:attribute> </xsl:template>  <xsl:template match="MOVIE/@YEAR"> <xsl:attribute name="ANNEE"> <xsl:value-of select="."/> </xsl:attribute> </xsl:template>

World Wide Web Wrapper Factory (W4F) : » If you please – Draw me a wrapper...« »If you please - draw me a wrapper...« When a mystery is too overpowering, one dare not disobey. Absurd as it might seem to me, a thousand miles from any human habitation and in danger of death, I took out of my pocket a sheet of paper and my fountain-pen. But then I remembered how my studies had been concentrated on geography, history, arithmetic, and grammar, and I told the little chap (a little crossly, too) that I did not know how to draw. He answered me: »That doesn't matter. Draw me a wrapper...« Arnaud Sahuguet Penn Database Research Group, University of Pennsylvania Fabien Azavant École Nationale Supérieure des Télécommunications

W4F : motivation • Le Web Oueb est un formidable outil de communication • des millions d’utilisateurs (entreprises, ONGs, le Congrès US) • coût d’entrées minime • publication facile (texte, son, image, video) • navigateurs gratuits • Mais comment faire pour • filtrer des centaines de résultats AltaVista • comparer des douzaines de produits sur catalogue • aggréger des informations depuis des sources multiples • Nouveaux défis • automatisaton • interopérabilité (Web awareness) • application-friendliness

Web “wrappers” • Rendre le contenu des sources d’information accessible de façon transparente aux applications, via des wrappers. • Un Web wrapper doit: • rapatrier l’information • extraire l’information • structurer and exporter l’information • Le problème • HTML : la forme, pas le fond • HTML : un joyeux bordel • Comment offrir une façon élégante et expressive pour extraire de l’information et la transformer en XML ? • Faites place à la World Wide Web Wrapper Factory... The one from the Web, not the one from the specs.

Retrievalwizard Retrieval Agent NSL NSL Mapper NSL L’ architecture W4F Retrieval Rules WorldWideWeb Mapping to Java objects ExtractionWizard Mappingwizard HTML page String The Java objects can now be used by any Java application. String[] Parser Actor[] Extraction Rules Mapping Rules Mapping to XML title NSL ExtractionEngine <MOVIE> <TITLE>Casablanca</TITLE> <GENRE>Drama, War, Romance</GENRE><CAST> <ACTOR>Humphrey Bogart</ACTOR> <ACTOR>Ingrid Bergman</ACTOR> ... genre NSL cast NSL DOM tree XML document

La lorgnette XML

Le wrapper en entier EXTRACTION_RULES html.body.center.table[i:*] ( .tr[0].td[0].b[0].txt // name # .tr[0].td[0].b[0]->pcdata[1].txt, match /[(](.*?):/ // trading place # .tr[0].td[0].b[0]->pcdata[1].txt, match /:(.*?)[)]/ // ticker # .tr[1].td[0].b[0].txt // last trade # .tr[1].td[3].pcdata[1].txt // volume # .tr[1].td[1].txt, match /[(](.*?)[)]/ // change % # .tr[2].td[0].txt, match /Range(.*)/, split /-/ // Day range # .tr[3].td[0].txt, match /Range(.*)/, split /-/ // Year range ) where html.body.center.table[i].tr[0].td[0].getAttr(colspan) = "7"; XML_MAPPING .Portfolio*.Stock ( .Full_Name^ # .Market^ # .Ticker^ # .Last # .Volume # .Change # .Day_Range ( .Min # .Max ) # .Year_Range ( .Min # .Max ) ); RETRIEVAL_RULESMETHOD: GET;URL: "http://finance.yahoo.com/q?s=AOL+YHOO+IBM+CSCO+LU+EBAY+TXN+EGRP+NOK&d=t";

W4F : la démo

Notre expérience avec W4F • Des wrappers pour • MedLine, Yahoo!, Internet Movie Database, CIA World Factbook, IBM Patent Server, AltaVista, Stock Market Quotes, E-commerce (CDs), etc. • Des applications Oueb • XML gateways, TV-Agent, French White pages, etc. • Intégration d’information • wrappers avec K2, le système de médiation de Penn • wrappers directement accessibles depuis XML-QL

Notre contribution • Points clés • spécification entièrement déclarative et concise • 3 couches logicielles indépendentes • langage de haut niveau pour l’extraction (2 façon de naviguer, conditions, regex, fork) • langage de haut niveau pour le mapping • composants logiciels prêts à l’emploi, légers (<5Ko) • outils visuels pour aider à la création des wrappers • Avantages • productivité accrue (qques minutes) • robuste • maintenance facilitée • intégration dans d’autres applications Java

&lt;XML Pôt Pourri/&gt;

&lt;XML Pôt Pourri/&gt;

Presentation Transcript

<XML Pôt Pourri/>

<XML Pôt Pourri/>