API simple pour XML

SAX ( Simple API for XML ) est un algorithme en ligne piloté par les événements pour l'analyse lexicale et syntaxique des documents XML , avec une API développée par la liste de diffusion XML-DEV. SAX fournit un mécanisme de lecture des données d'un document XML qui constitue une alternative à celui fourni par le modèle d'objet de document (DOM). Alors que le DOM opère sur le document dans son ensemble (en créant l' arbre syntaxique abstrait complet d'un document XML pour la commodité de l'utilisateur), les analyseurs SAX opèrent sur chaque partie du document XML de manière séquentielle, en émettant des événements d'analyse tout en effectuant un seul passage dans le flux d'entrée.

Contrairement à DOM , il n'existe pas de spécification formelle pour SAX. L' implémentation Java de SAX est considérée comme normative . SAX traite les documents indépendamment de l'état, contrairement à DOM qui est utilisé pour le traitement dépendant de l'état des documents XML.

Un analyseur SAX n'a ​​besoin que de signaler chaque événement d'analyse au fur et à mesure qu'il se produit, et supprime normalement presque toutes ces informations une fois signalées (il conserve cependant certaines choses, par exemple une liste de tous les éléments qui n'ont pas encore été fermés, afin de détecter des erreurs ultérieures telles que des balises de fin dans le mauvais ordre). Ainsi, la mémoire minimale requise pour un analyseur SAX est proportionnelle à la profondeur maximale du fichier XML (c'est-à-dire de l'arbre XML) et aux données maximales impliquées dans un seul événement XML (comme le nom et les attributs d'une seule balise de début, ou le contenu d'une instruction de traitement, etc.).

Cette quantité de mémoire est généralement considérée comme négligeable. Un analyseur DOM, au contraire, doit d'abord créer une représentation arborescente de l'ensemble du document en mémoire, utilisant ainsi une mémoire qui augmente avec la longueur totale du document. Cela prend beaucoup de temps et d'espace pour les documents volumineux (l'allocation de mémoire et la construction de la structure de données prennent du temps). L'avantage compensatoire, bien sûr, est qu'une fois chargée, n'importe quelle partie du document est accessible dans n'importe quel ordre.

En raison de la nature événementielle de SAX, le traitement des documents est généralement beaucoup plus rapide que les analyseurs de type DOM, à condition que le traitement puisse être effectué en une seule passe de bout en bout. De nombreuses tâches, telles que l'indexation, la conversion vers d'autres formats, le formatage très simple, etc., peuvent être effectuées de cette manière. D'autres tâches, telles que le tri, la réorganisation des sections, le passage d'un lien à sa cible, la recherche d'informations sur un élément pour aider à traiter un élément ultérieur, etc., nécessitent d'accéder à la structure du document dans des ordres complexes et seront beaucoup plus rapides avec DOM qu'avec plusieurs passes SAX.

Certaines implémentations ne correspondent pas parfaitement à l'une ou l'autre de ces catégories : une approche DOM peut conserver ses données persistantes sur disque, intelligemment organisées pour plus de rapidité (des éditeurs tels que SoftQuad Author/Editor et des navigateurs/indexeurs de documents volumineux tels que DynaText le font) ; tandis qu'une approche SAX peut mettre en cache intelligemment les informations pour une utilisation ultérieure (tout analyseur SAX de validation conserve plus d'informations que celles décrites ci-dessus). De telles implémentations brouillent les compromis DOM/SAX, mais sont souvent très efficaces en pratique.

En raison de la nature du DOM, la lecture en continu à partir du disque nécessite des techniques telles que l'évaluation paresseuse , les caches, la mémoire virtuelle , les structures de données persistantes ou d'autres techniques (une de ces techniques est décrite dans le brevet américain 5557722). Le traitement de documents XML plus volumineux que la mémoire principale est parfois considéré comme impossible car certains analyseurs DOM ne le permettent pas. Cependant, il n'est pas moins possible que de trier un ensemble de données plus volumineux que la mémoire principale en utilisant l'espace disque comme mémoire pour contourner cette limitation.

Le modèle piloté par événements de SAX est utile pour l’analyse XML, mais il présente certains inconvénients.

Pratiquement tout type de validation XML nécessite un accès complet au document. L'exemple le plus trivial est celui d'un attribut déclaré dans la DTD comme étant de type IDREF, qui nécessite qu'un seul élément du document utilise la même valeur pour un attribut ID. Pour valider cela dans un analyseur SAX, il faut garder une trace de tous les attributs ID (l'un d'entre eux peut finir par être référencé par un attribut IDREF à la toute fin) ainsi que de chaque attribut IDREF jusqu'à ce qu'il soit résolu. De même, pour valider que chaque élément possède une séquence acceptable d'éléments enfants, les informations sur les éléments enfants qui ont été vus pour chaque parent doivent être conservées jusqu'à la fermeture du parent.

De plus, certains types de traitement XML nécessitent simplement d'avoir accès à l'intégralité du document. XSLT et XPath , par exemple, doivent pouvoir accéder à n'importe quel nœud à tout moment dans l'arbre XML analysé. Les éditeurs et les navigateurs doivent également pouvoir afficher, modifier et éventuellement revalider à tout moment. Bien qu'un analyseur SAX puisse être utilisé pour construire un tel arbre dans un premier temps, SAX n'offre aucune aide pour un tel traitement dans son ensemble.

Un analyseur qui implémente SAX (c'est-à-dire un analyseur SAX ) fonctionne comme un analyseur de flux, avec une API pilotée par les événements . L'utilisateur définit un certain nombre de méthodes de rappel qui seront appelées lorsque des événements se produisent pendant l'analyse. Les événements SAX incluent (entre autres) :

• Nœuds de texte XML
• Début et fin des éléments XML
• Instructions de traitement XML
• Commentaires XML

Certains événements correspondent à des objets XML qui sont facilement renvoyés en une seule fois, comme les commentaires. Cependant, les éléments XML peuvent contenir de nombreux autres objets XML, et SAX les représente donc comme le fait XML lui-même : par un événement au début et un autre à la fin. À proprement parler, l'interface SAX ne traite pas d' éléments , mais d' événements qui correspondent en grande partie à des balises . L'analyse SAX est unidirectionnelle ; les données précédemment analysées ne peuvent pas être relues sans recommencer l'opération d'analyse.

Il existe de nombreuses implémentations de type SAX. En pratique, les détails varient, mais le modèle global est le même. Par exemple, les attributs XML sont généralement fournis sous forme d'arguments de nom et de valeur transmis aux événements d'élément, mais peuvent également être fournis sous forme d'événements séparés, ou via une table de hachage ou une collection similaire de tous les attributs. D'autre part, certaines implémentations fournissent des rappels « Init » et « Fin » pour le tout début et la toute fin de l'analyse ; d'autres non. Les noms exacts des types d'événements donnés varient également légèrement entre les implémentations.

Étant donné le document XML suivant :

<?xml version="1.0" encoding="UTF-8"?> 
<DocumentElement param= "value" > <FirstElement> ¶ Du texte </FirstElement> <?some_pi some_attr="some_value"?> <SecondElement param2= "something" > Pré-texte <Inline> Texte en ligne </Inline> Post-texte. </SecondElement> </DocumentElement>

Ce document XML, lorsqu'il est transmis via un analyseur SAX, générera une séquence d'événements comme la suivante :

• Début de l'élément XML, nommé DocumentElement , avec un paramètre d'attribut égal à « valeur »
• Début de l'élément XML, nommé FirstElement
• Nœud de texte XML, avec des données égales à « Un texte » (remarque : certains espaces blancs peuvent être modifiés)
• Fin de l'élément XML, nommé FirstElement
• Événement d'instruction de traitement, avec la cible some_pi et les données some_attr="some_value" (le contenu après la cible est simplement du texte ; cependant, il est très courant d'imiter la syntaxe des attributs XML, comme dans cet exemple)
• Début de l'élément XML, nommé SecondElement , avec un attribut param2 égal à « quelque chose »
• Nœud de texte XML, avec des données égales à « Pré-texte »
• Début de l'élément XML, nommé Inline
• Nœud de texte XML, avec des données égales à « Texte en ligne »
• Fin de l'élément XML, nommé Inline
• Nœud de texte XML, avec des données égales à « Post-texte ».
• Fin de l'élément XML, nommé SecondElement
• Fin de l'élément XML, nommé DocumentElement

Notez que la première ligne de l'exemple ci-dessus est la déclaration XML et non une instruction de traitement ; en tant que telle, elle ne sera pas signalée comme un événement d'instruction de traitement (bien que certaines implémentations SAX fournissent un événement distinct uniquement pour la déclaration XML).

Le résultat ci-dessus peut varier : la spécification SAX stipule délibérément qu'une section donnée de texte peut être signalée sous forme de plusieurs événements de texte séquentiels. De nombreux analyseurs, par exemple, renvoient des événements de texte distincts pour les références de caractères numériques. Ainsi, dans l'exemple ci-dessus, un analyseur SAX peut générer une série d'événements différente, dont une partie peut inclure :

• Début de l'élément XML, nommé FirstElement
• Nœud de texte XML, avec des données égales à « ¶ » (le caractère Unicode U+00b6)
• Nœud de texte XML, avec des données égales à « Un texte »
• Fin de l'élément XML, nommé FirstElement