SAX ( Simple API for XML ) es un algoritmo en línea basado en eventos para analizar y analizar documentos XML , con una API desarrollada por la lista de correo XML-DEV. [1] SAX proporciona un mecanismo para leer datos de un documento XML que es una alternativa a la proporcionada por el Modelo de objetos de documento (DOM). Mientras que el DOM opera sobre el documento como un todo (construyendo el árbol de sintaxis abstracta completo de un documento XML para comodidad del usuario), los analizadores SAX operan sobre cada parte del documento XML secuencialmente, emitiendo eventos de análisis mientras realizan una sola pasada a través del flujo de entrada.
A diferencia de DOM , no existe una especificación formal para SAX. La implementación de SAX en Java se considera normativa . [2] SAX procesa documentos de forma independiente del estado, a diferencia de DOM, que se utiliza para el procesamiento dependiente del estado de documentos XML. [3]
Un analizador SAX solo necesita informar cada evento de análisis a medida que ocurre y normalmente descarta casi toda esa información una vez informada (sin embargo, conserva algunas cosas, por ejemplo, una lista de todos los elementos que aún no se han cerrado, para detectar errores posteriores, como etiquetas finales en el orden incorrecto). Por lo tanto, la memoria mínima requerida para un analizador SAX es proporcional a la profundidad máxima del archivo XML (es decir, del árbol XML) y la cantidad máxima de datos involucrados en un solo evento XML (como el nombre y los atributos de una sola etiqueta de inicio o el contenido de una instrucción de procesamiento, etc.).
Esta cantidad de memoria suele considerarse insignificante. Por el contrario, un analizador DOM tiene que construir una representación en forma de árbol de todo el documento en la memoria para empezar, por lo que utiliza una memoria que aumenta con la longitud total del documento. Esto requiere un tiempo y un espacio considerables para documentos grandes (la asignación de memoria y la construcción de la estructura de datos requieren tiempo). La ventaja compensatoria, por supuesto, es que una vez cargada, se puede acceder a cualquier parte del documento en cualquier orden.
Debido a la naturaleza basada en eventos de SAX, el procesamiento de documentos es generalmente mucho más rápido que con los analizadores de estilo DOM, siempre que el procesamiento se pueda realizar en una pasada de principio a fin. Muchas tareas, como la indexación, la conversión a otros formatos, el formato muy simple y similares, se pueden realizar de esa manera. Otras tareas, como ordenar, reorganizar secciones, llegar desde un enlace a su destino, buscar información sobre un elemento para ayudar a procesar uno posterior y similares, requieren acceder a la estructura del documento en órdenes complejos y serán mucho más rápidas con DOM que con múltiples pasadas de SAX.
Algunas implementaciones no encajan perfectamente en ninguna de las dos categorías: un enfoque DOM puede mantener sus datos persistentes en el disco, organizados inteligentemente para lograr velocidad (editores como SoftQuad Author/Editor y navegadores/indexadores de documentos grandes como DynaText lo hacen); mientras que un enfoque SAX puede almacenar en caché inteligentemente la información para su uso posterior (cualquier analizador SAX que valide conserva más información que la descrita anteriormente). Estas implementaciones desdibujan las disyuntivas entre DOM y SAX, pero a menudo son muy efectivas en la práctica.
Debido a la naturaleza del DOM, la lectura en tiempo real desde el disco requiere técnicas como la evaluación diferida , cachés, memoria virtual , estructuras de datos persistentes u otras técnicas (una de estas técnicas se describe en la patente estadounidense 5557722). El procesamiento de documentos XML más grandes que la memoria principal a veces se considera imposible porque algunos analizadores DOM no lo permiten. Sin embargo, no es menos posible que ordenar un conjunto de datos más grande que la memoria principal utilizando el espacio del disco como memoria para eludir esta limitación. [4]
El modelo basado en eventos de SAX es útil para el análisis de XML, pero tiene ciertas desventajas.
Prácticamente cualquier tipo de validación XML requiere acceso al documento completo. El ejemplo más trivial es que un atributo declarado en la DTD como de tipo IDREF requiere que haya solo un elemento en el documento que use el mismo valor para un atributo ID. Para validar esto en un analizador SAX, se debe realizar un seguimiento de todos los atributos ID (cualquiera de ellos puede terminar siendo referenciado por un atributo IDREF al final); así como de cada atributo IDREF hasta que se resuelva. De manera similar, para validar que cada elemento tiene una secuencia aceptable de elementos secundarios, se debe mantener la información sobre qué elementos secundarios se han visto para cada elemento principal hasta que se cierre el elemento principal.
Además, algunos tipos de procesamiento XML simplemente requieren tener acceso a todo el documento. XSLT y XPath , por ejemplo, necesitan poder acceder a cualquier nodo en cualquier momento en el árbol XML analizado. Los editores y navegadores también necesitan poder mostrar, modificar y quizás revalidar en cualquier momento. Si bien un analizador SAX puede usarse para construir dicho árbol inicialmente, SAX no proporciona ayuda para dicho procesamiento en su totalidad.
Un analizador que implementa SAX (es decir, un analizador SAX ) funciona como un analizador de flujo, con una API basada en eventos . [1] El usuario define una serie de métodos de devolución de llamada que se llamarán cuando se produzcan eventos durante el análisis. Los eventos SAX incluyen (entre otros):
Algunos eventos corresponden a objetos XML que se pueden devolver fácilmente todos a la vez, como los comentarios. Sin embargo, los elementos XML pueden contener muchos otros objetos XML, por lo que SAX los representa como lo hace el propio XML: mediante un evento al principio y otro al final. En términos propios, la interfaz SAX no se ocupa de elementos , sino de eventos que corresponden en gran medida a etiquetas . El análisis de SAX es unidireccional; los datos analizados previamente no se pueden volver a leer sin iniciar de nuevo la operación de análisis.
Existen muchas implementaciones similares a SAX. En la práctica, los detalles varían, pero el modelo general es el mismo. Por ejemplo, los atributos XML se proporcionan normalmente como argumentos de nombre y valor que se pasan a los eventos de elementos, pero también se pueden proporcionar como eventos separados o mediante una tabla hash o una colección similar de todos los atributos. Por otra parte, algunas implementaciones proporcionan devoluciones de llamadas "Init" y "Fin" para el inicio y el final del análisis; otras no. Los nombres exactos de determinados tipos de eventos también varían ligeramente entre implementaciones.
Dado el siguiente documento XML:
<?xml version="1.0" encoding="UTF-8"?> <DocumentElement param= "value" > <FirstElement> ¶ Algún texto </FirstElement> <?some_pi some_attr="some_value"?> <SecondElement param2= "something" > Pre-Texto <Inline> Texto en línea </Inline> Post-texto. </SecondElement> </DocumentElement> Este documento XML, al pasar por un analizador SAX, generará una secuencia de eventos como la siguiente:
Tenga en cuenta que la primera línea del ejemplo anterior es la Declaración XML y no una instrucción de procesamiento; como tal, no se informará como un evento de instrucción de procesamiento (aunque algunas implementaciones de SAX proporcionan un evento separado solo para la declaración XML).
El resultado anterior puede variar: la especificación SAX establece deliberadamente que una sección de texto determinada puede ser informada como múltiples eventos de texto secuenciales. Muchos analizadores, por ejemplo, devuelven eventos de texto separados para referencias de caracteres numéricos. Por lo tanto, en el ejemplo anterior, un analizador SAX puede generar una serie diferente de eventos, parte de los cuales podrían incluir:
Abreviatura de Simple API for XML, una API basada en eventos que, como alternativa a DOM, permite a alguien acceder al contenido de un documento XML. SAX era originalmente una API solo para Java. La versión actual admite varios entornos de lenguaje de programación distintos de Java. SAX fue desarrollado por los miembros de la lista de correo XML-DEV.
Nota: En pocas palabras, SAX está orientado al procesamiento independiente del estado, donde el manejo de un elemento no depende de los elementos anteriores. StAX, por otro lado, está orientado al procesamiento dependiente del estado. Para una comparación más detallada, consulte SAX y StAX en Estándares básicos y Cuándo usar SAX.
Aunque estas pruebas no lo demuestran, los analizadores SAX suelen ser más rápidos para documentos muy grandes en los que el modelo DOM alcanza la memoria virtual o consume toda la memoria disponible.