• Aucun résultat trouvé

R EPRESENTATION ET DECOMPOSITION DES FICHIERS XML : LES API S DOM ET SAX

Dans le document Etude exploratoire XML/SVG (Page 38-41)

3. TECHNOLOGIES UTILISEES

3.2 R EPRESENTATION ET DECOMPOSITION DES FICHIERS XML : LES API S DOM ET SAX

Pour qu’une application puisse utiliser un document XML, il est nécessaire qu’elle puisse le

décomposer et en construire une représentation interne. Ces opérations sont réalisées grâce à des « parseurs »

XML. On en distingue deux types, qui diffèrent par leur mode de fonctionnement : les parseurs basés sur l’API

DOM et ceux qui sont basés sur l’API SAX.

3.2.1 Présentation de DOM

Le modèle DOM (Document Object Model) est utilisé pour représenter un document XML de manière

hiérarchique, sous forme d’arbre (voir section 2.4.1). L’application peut alors accéder arbitrairement à n’importe

quel élément en parcourant cet arbre. Ce modèle DOM a déjà fait l’objet de plusieurs recommandations du

W3C. Celle du modèle DOM niveau 2 date du 13 Novembre 2000 et peut être consultée à l’adresse suivante :

http://www.w3.org/TR/DOM-Level-2-Core/ : Recommandation du W3C pour DOM niveau 2

http://www.w3.org/TR/DOM-Level-3-Core/ : Working Draft pour DOM niveau 3 (14 Janvier 2002)

Les parseurs DOM (Document Object Model) traitent l’ensemble du document XML, et en construisent

une représentation sous forme d’arbre. Ces parseurs sont adaptés lorsque l’on doit accéder à des éléments de

l’arbre de manière aléatoire (navigation dans le document). De plus, le modèle DOM est implémenté par les

navigateurs Web et permet ainsi de parcourir les documents pour les applications Web. Il devient par contre

inutilisable lorsque le nombre d’éléments devient trop important. Il est implémenté par quasiment toutes les

applications qui manipulent des données XML. Par exemple, Adobe SVG Viewer construit une représentation

du document SVG en utilisant le modèle DOM.

3.2.2 Présentation de SAX

SAX (Simple A

PI

for X

ML

) est une API utilisée également pour décomposer des documents XML. A

l’origine, elle était conçue uniquement pour Java, mais d’autres implémentations ont fait leur apparition depuis.

La version actuelle est SAX 2.0, mais il faut noter que cette API ne fait pas l’objet d’une recommandation du

W3C. Son développement est donc un peu plus anarchique, mais on trouve tout de même plusieurs

implémentations stables de cette API. La page officielle est la suivante :

http://www.saxproject.org/ : Page officielle de SAX (Simple A

PI

for X

ML

)

Les parseurs qui implémentent l’API SAX décomposent le document XML au fur et à mesure de la

lecture, sans construire de représentation de l’ensemble du document. La programmation se fait de manière

événementielle, c’est à dire que l’application traite des événements qui lui sont envoyés par le parseur (par

exemple lorsqu’il rencontre une certaine balise). Chaque type d’événement reconnu sera traité par une fonction

spécifique de l’application. Ces parseurs sont particulièrement adaptés pour les documents volumineux car ils ne

chargent pas l’ensemble de ceux-ci en mémoire, et sont donc peu gourmands en ressources.

3.2.3 Comparaison de DOM et SAX

Avantages Inconvénients

DOM

+ Possibilité d’accès aléatoire à n’importe

quel élément

+ Très utilisé

+ Recommandation du W3C

- Inadapté pour les documents

volumineux

SAX

+ Peu gourmand en ressources

- Pas de représentation de

l’ensemble du document

Les deux modèles DOM et SAX sont très différents, par leur implémentation et leurs utilisations. Nous

ne pouvons pas préconiser l’utilisation d’un modèle plutôt que l’autre, car tout dépend de l’application. En

général, lorsqu’il s’agit de transformer un document volumineux ou d’en extraire des informations en une seule

fois, SAX est plus adapté. Lorsqu’on a besoin d’une représentation interne pour manipuler les différents

éléments ou accéder à leur contenu de manière aléatoire, l’utilisation de DOM est recommandée. Les

applications utilisant XML ont souvent recours aux deux modèles parallèlement.

3.2.4 JAXP et les différentes implémentations de parseurs

JAXP (Java A

PI

for X

ML

Processing) est une API développée par Sun pour le traitement de documents

XML par DOM, SAX ou XSLT. En définissant une interface commune pour ces traitements, JAXP permet au

développeur de choisir quel processeur utiliser sans changement de code. Comme leur nom l’indique, les

processeurs JAXP ne fonctionnent qu’en environnement Java. Voici la liste des plus répandus :

-

Parseurs JAXP :

" Apache Crimson (anciennement Sun Project X) : parseur XML supportant SAX et DOM

" Apache Xerces 1 (anciennement IBM XML4J) : parseur XML supportant SAX et DOM

" Apache Xerces 2 : parseur XML entièrement réécrit supportant SAX et DOM

" GNU JAXP : parseur XML supportant SAX2 et DOM niveau 2

-

Processeurs XSLT JAXP :

" Apache Xalan-J XSLT : Processeur XSLT

" Saxon XSLT : Processeur XSLT

La fondation Apache est un des acteurs majeurs des technologies XML et Java. Elle propose

notamment avec Xalan et Xerces un moyen simple et efficace d’effectuer des traitements XSLT sur des

documents XML. De plus, il est très facile d’intégrer Xalan et Xerces à un serveur Apache Tomcat, ce qui

permet de déclencher ces traitements par une Servlet. Pour la maquette « client léger », nous utilisons Xalan 2 et

Xerces 2. Nous préconisons d’utiliser ces librairies car elles sont peu coûteuses et fiables.

Pour les implémentations non-Java de parseurs, on distingue principalement MSXML de Microsoft qui

est maintenant disponible dans sa version 4.0. Il offre des parseurs SAX et DOM et un processeur XSLT

performants. Le principal avantage de MSXML est qu’il est intégré à Internet Explorer. C’est donc grâce à lui

que nous avons réalisé la maquette « application locale ».

Avantages Inconvénients

Parseurs et

processeurs

JAXP

+ Indépendants de la plate-forme utilisée

+ On peut choisir l’implémentation que

l’on souhaite utiliser

+ Facilement intégrable à des applications

Java

-

Uniquement utilisable avec Java

MSXML

+ Performance

+ Intégration possible avec VB ou ASP

+ Intégré à Internet Explorer

- Pas portable

-

Pas d’intégration avec Java

Dans le document Etude exploratoire XML/SVG (Page 38-41)