P
'
t
i
t
e
C
h
a
t
t
e
 
spacer~ ACCORDING TO MY CALCULATIONS, THE PROBLEM DOESN'T EXIST Articles | Connexion
 
~L'API SAX pour XML

 Présentation

De nombreux parsers utilisent une API événementielle extrêmement simple intitulée Simple API For XML. Contrairement au Document Object Model, cette API se destine exclusivement à la lecture de documents XML.
 Sommaire


 Introduction

La definition de SAX est l'oeuvre de Peter Murray-Rust, David Megginson et Tim Bray. Le premier travaillait alors sur JUMBO un navigateur XML, le second sur le parser Lax et le dernier sur le parser AElfred. La version finale de l'API SAX 1.0 apparu le 11 May 1998. Si SAX 1.0 reste la version la plus utilisée de cette API, la version 2.0 commence à percer. Le parser Xerces 2.0 de la fondation Apache offre notamment un support pour cette API. L'API SAX emploie le package org.xml.sax. A l'instar des recommendations DOM du W3C, SAX se présente sous la forme d'interfaces.


 Une API conSAXcrée

La Simple API for XML se révèle intéressante à plus d'un titre. Premièrement, elle ne contient que très peu de classes et de méthodes. Ensuite, son fonctionnement même se veut intuitif. SAX repose sur un système d'événements. Ainsi, lorsqu'un parser lit un fichier XML, émet des informations en direction d'un ou plusieurs "gestionnaires". Ces gestionnaires sont créés par les applications. Par exemple, lorsque le parser rencontre une balise, la méthode startElement() du gestionnaire de document se voit invoquée. L'API SAX 1.0 propose quatre gestionnaires différents : DocumentHandler, ErrorHandler, DTDHandler et EntityResolver.

Cependant, l'utilisation de SAX se revèle parfois ardue. Le fait de recevoir les informations au "goutte à goutte", dans l'ordre de lecture, rend parfois compliqué la génération de structures objets complexes. Créer une arborescence objet liée au document, un menu par exemple, s'avère un peu moins naturelle qu'avec DOM. Néanmoins, la localisation d'une poignée d'informations dans un document de grande taille se veut plus efficace avec SAX. La recherche d'une balise donnée dans un document XML de plusieurs dizaines de méga-octets ne demandera au maximum qu'une seule lecture complète du document en SAX.

Avec DOM, un équivalent objet sera créé en mémoire : cela nécessite beaucoup de temps et encombre fortement la mémoire. En règle générale, si le programmeur n'a pas besoin de conserver le document en mémoire, il devrait utiliser SAX pour des raisons de performances.

Le passage à la version 2.0 des interfaces SAX a engendré la désuétude de plusieurs classes. Inversement, de nombreuses interfaces sont apparues. Ainsi, le gestionnaire DocumentHandler n'existe plus. Son remplaçant se nomme ContentHandler.



Les différences entre SAX 1.0 et SAX 2.0

Le code suivant correspond à une implémentation de SAX affichant la liste de toutes les balises d'un document :

class DisplayTags implements org.xml.sax.ContentHandler
{
  public void startElement(String namespaceURI, String localName,
                           String qName, Attributes atts)
  {
    System.out.println('<' + localName + '>');
  }
  // ...
}
       
      
JextCopier dans Jext | Jext | Plugin Codegeek
La multitude de méthodes offertes par la version 2 de l'API laisse le loisir de gérer toute entité décrite dans un document XML. Si cette API fut créée pour le langage Java, d'autres implémentations existent. On retrouve ainsi SAX au sein du parser MSXML 3 de Microsoft, au cour des distributions Python 2.0 ou encore dans la librairie Xerces-C.

Le site Internet de David Megginson (http://www.megginson.com/SAX) représentait jusqu'à peu le site officiel. Depuis la version 2.0 de SAX, SourceForge accueille le projet SAX sur ses serveurs (http://sax.sourceforge.net). Ce site Internet propose l'historique de l'API et offre de nombreuses ressources à son sujet.



par Romain Guy
romain.guy@jext.org
http://www.jext.org
Dernière mise à jour : 14/10/2006



 
#ProgX©2005 Mathieu GINOD - Romain GUY - Erik LOUISE