"bookmark|folder|alias|separator %local.nodes.mix;">

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 : – 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 (syntactique) pour représenter la notion d’héritage

3. DTDs : la mauvaise graisse

• Attribut comme NMTOKEN • IDREF • Notations • Processing instructions Personne ne les utilise parce que personne ne comprend à quoi ils servent.

• FinXML DTD

DTDs : zoom

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-model

s • 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 record ordered inheritance inheritance ?

+/* option list null 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

> A schema element should contain at least one pattern elements.

A pattern element should contain at least one rule elements.

A pattern element should have an attribute called name.

A rule element should contain at least one assert or report elements.

A rule element should have an attribute called context.

This should be an XPath for selecting nodes to make assertions and reports about.

An assert element should have an attribute called test. This should be an XSLT expression.

A report element should have an attribute called test. This should be an XSLT expression.

Exemple (suite)

Unexpected element(s) found: a schema element should contain only pattern elements. A schema element should contain at least one pattern element. The element phase is only used in the 1.2 DTD Unexpected element(s) found: A pattern element should contain only rule elements. A pattern element should contain at least one rule elements. A pattern element should have an attribute called name. Unexpected element(s) found: a rule element should contain only assert and report elements. A rule elemement should contain at least one assert or report elements.

@context

">A rule element should have an attribute called context.

This should be an XPath for selecting nodes to make assertions and reports about. The element key is only used in the 1.2 DTD

assert

">

@test

">An assert element should have an attribute called test.

This should be an XSLT expression. The element name is only used in the 1.1 DTD

report

"> A report element should have an attribute called test.

This should be an XSLT expression. The element name is only used in the 1.1 DTD

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-T

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 The one from the Web, not the one from the specs.

– 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...

World Wide Web

Retrieval Rules Retrieval Agent

L’ architecture W4F

Retrieval wizard HTML page Extraction Wizard Mapping wizard Parser Extraction Rules DOM tree

NSL

Extraction

NSL

Engine

NSL

title genre cast Mapping Rules

NSL NSL NSL

Mapper

Mapping to Java objects String String[] Actor[] The Java objects can now be used by any Java application.

Mapping to XML

Drama, War, Romance

Humphrey Bogart

Ingrid Bergman

...

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_RULES

METHOD: 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

W4F

• Prototype académique + publications – db.cis.upenn.edu/W4F • Distribution commerciale – www.tropea-inc.com

Conclusion

• XML = cible mouvante • L’industrie aura le dernier mot • Première vague d’outils XML : pas grand chose de révolutionnaire • Seconde vague : à nous de l’inventer

Conclusion (suite)

• Les problèmes à regarder de près : – conversion de texte structuré vers XML (langage naturel) – nettoyage, normalisation de l’information – détection de changement (avec de la sémantique) – suivi de l’information (remonter à la source) • Les trucs à suivre : – le saint Graal : “ the XML data model ” – l’optimisation transparente (relationnel, XML, OO, etc.) – W3C