Tesis(draft)
Anuncio
TESIS DOCTORAL
Contribución al análisis XML para la mejora
en las prestaciones de memoria. Aplicación
a dispositivos móviles.
AUTOR
Antonio Jesús Sierra Collado
Ingeniero de Telecomunicación
DIRECTOR
Luis de la Cruz Llopis
Dr. Ingeniero de Telecomunicación
Marzo 2006
Departament d'Enginyeria Telemàtica
UNIVERSISTAT POLITÈCNICA DE CATALUNYA
TESIS DOCTORAL
Contribución al análisis XML para la mejora
en las prestaciones de memoria. Aplicación
a dispositivos móviles.
TRIBUNAL CALIFICADOR
Presidente:
Vocales:
Secretario:
Vocales Suplentes:
CALIFICACIÓN
Dedicado a las Marías (mi mujer y mi hija)
Capítulo 1. Introducción.
7
Prefacio y agradecimientos
Las telecomunicaciones constituyen un elemento clave de la Sociedad de la
Información, facilitando el acceso e intercambio de datos entre personas, máquinas,
sistemas e instituciones. No es posible entender el actual progreso socioeconómico, sin
tener presente el despliegue de redes de comunicaciones cada vez más sofisticadas
(fijas, de cable, satélite, móviles, etc.) que, además, dan lugar a un fenómeno de tanta
trascendencia social como es la comunicación ubicua que caracteriza la sociedad
moderna, con Internet como soporte.
Ahora entramos en el comienzo de una nueva era, la Computación Ubicua, en la
que una persona puede actuar sobre una multitud de dispositivos programables. Dada su
abundancia, es necesario que puedan ser manejados con el mínimo esfuerzo, siendo en
la mayor parte de los casos la interactividad entre el sujeto y la máquina absolutamente
transparente.
Para alcanzar este reto, la Web, como soporte omnipresente, necesita que los
formatos y protocolos tengan especificaciones compatibles unas con otras, y permitir
que cualquier hardware y software utilizado pueda acceder para trabajar de forma
cooperativa. El W3C (Word Wide Web Consortium) diseña y promueve la
interoperabilidad de formatos abiertos (no propietarios) y protocolos, para evitar la
fragmentación que el mercado sufrió en decadas precedentes. Desde 1994, el W3C ha
generado más de 90 estándares Web, llamados "recomendaciones W3C". Estos
estándares, representan un despliegue de especificaciones estables en beneficio de todo
el sector industrial.
La recomendación del W3C, Extensible Markup Language (XML), es un formato
de convergencia para el intecambio de datos, tanto en Internet, como en otras
aplicaciones, que permiten estructurar documentos o flujos de caracteres, identificando
estructuras y otras unidades en los datos, para manejar datos portables, con
independencia del propósito y naturaleza de la información. A partir de la simplicidad
del marcado se pueden especificar protocolos, formatos, lenguajes, ... El lenguaje de
marcas XML es un formato de texto simple y muy flexible derivado de Standard
Generalized Markup Language (SGML), que se diseñó para enfrentarse al desafío de la
publicación electrónica a gran escala. XML juega un papel vital en el intercambio de
una gran variedad de datos tanto en la Web como fuera de ella. XML es una sintaxis
universal para describir y estructurar datos con independencia de la aplicación lógica.
La optimización de las herramientas para el manejo de contenidos basados en los
lenguajes de marcas, son un reto constante a fín de poder llevar los contenidos Web a
cualquier sitio, en cualquier momento y sobre cualquier plataforma de ejecución, en las
mejores condiciones y con la mayor eficiencia. La capacidad de importar y exportar
datos en formato neutro para el intercambio de datos entre aplicaciones, neutro para la
comercialización, y estándar para la industria, hace que los Lenguajes de Marcas puedan
dar soporte de una forma flexibilidad y eficiente a las tecnologías electrónicas (etechnologies).
Quiero agradecer a Luis J. de la Cruz, por la revisión de este documento, así como
los anteriores directores Joan García y Francisco Rico.
Mi agradecimiento y reconocimiento a Sam Wilmott, este trabajo en gran medida
está estructurado así por él, y a los organizadores de "Extreme Markup Language" por
su apoyo.
Mi agradecimiento a Sergio Cruces, por sus consejos sobre exposiciones.
Mi agradecimiento a mi mujer María Carrión por su apoyo.
Índice
Índice de figuras
VII
Índice de tablas
XI
Resumen
XIII
Abstract
XV
CAPÍTULO 1. Introducción
1
1
Preliminares.
1
2
Motivación y entorno
3
3
Objetivos.
6
4
Contenido y organización de la memoria.
7
CAPÍTULO 2. Análisis de la información XML
9
1
Introducción.
2
Codificación de caracteres. Formatos de Transformación
3
4
9
11
2.1 Generalidades
11
2.2 ISO/IEC 10646
12
2.3 Unicode
13
2.4 UTF-32
13
2.5 UTF-8
13
2.6 UTF-16
14
Java 2 Platform, Micro Edition (Java ME)
15
3.1 Introducción
15
3.2 KVM
16
3.3 APIs
16
3.4 APIs Opcionales
17
3.5 JSR-185
18
Análisis de XML
19
4.1 Introducción
19
4.2 Modelos de análisis
20
Contribución al análisis XML para la mejora en las prestaciones de memoria
II
4.3 Modelo de Objeto de un Documento: DOM
4.3.1 Introducción
22
4.3.2 Diagrama UML
22
4.3.3 Ejemplo con DOM
24
4.3.4 Modelo Productor/Consumidor en DOM
26
4.4 Análisis con Push
5
6
22
27
4.4.1 Introducción
27
4.4.2 Diagrama UML para SAX
28
4.4.3 Ejemplo con Push
30
4.4.4 Modelo Productor/Consumidor en Push
32
4.5 Análisis con Pull
32
4.5.1 Introducción
32
4.5.2 Diagrama UML para Pull
33
4.5.3 Ejemplos con Pull
35
4.5.4 Modelo Productor y Consumidor en Pull
37
Selección del modelo de análisis
38
5.1 Introducción
38
5.2 Pros
38
5.2 Contras
39
5.3 Mejor uso
40
Codificación de texto. Implementaciones.
40
6.1 Introducción
40
6.2 DocBook
42
6.3 UBL (Universal Business Language)
42
6.4 Analizadores. Trabajos relacionados.
43
6.5 Validación de documentos XML.
51
6.6 Taxonomía de los analizadores en la Java ME.
52
6.6.1 Introducción
52
6.6.2 NanoXML
52
6.6.3 kXML2
53
6.6.4 MinML
54
6.6.5 XMLtp
54
Índice
7
III
6.6.6 TinyXML
55
6.6.7 Xparse-J
55
6.6.8 JSR-280
55
Qué hace diferentes a los analizadores.
56
7.1 Consideraciones generales
56
7.2 Forma en la que los datos son devueltos
56
7.3 La información que es devuelta al cliente
58
7.4 Relación entre el analizador y el cliente
59
8 Conclusiones
CAPÍTULO 3. Modelo Propuesto
59
63
1
Introducción
63
2
El nuevo modelo
65
2.1 Pull-everything
65
2.2 Análisis in-situ
68
2.3 Funcionamiento del nuevo modelo
71
2.4 Soporte de las nuevas operaciones
73
2.5 El modelo productor y consumidor
74
2.6 Ejemplo de utilización
75
3
Aplicación del Modelo propuesto a Java ME.
76
3.1 Introducción
76
3.2 Subconjunto mínimo para la implementación
78
3.3 Los datos XML
78
3.3.1 Detección del Esquema de codificación
79
3.3.2 Tamaño de la Estructura
79
3.3.3 ¿Qué estructura?
79
3.4 Documentos XML “bien formados” (well-formed)
80
3.5 Estructura para la implementación de “bien formado” en FCM
81
3.6 Otra posible representación para dar soporte en FCM
81
3.7 Cómo estrurar la información con el uso de referencias
82
3.8 La Interfaz XMLFCMConstants
83
3.9 Otras características de la implementación
84
IV Contribución al análisis XML para la mejora en las prestaciones de memoria
3.10 Dependencia del estado.
4
Conclusiones.
CAPÍTULO 4. Análisis Comparativo del Rendimiento del Modelo
86
90
93
1
Introducción
93
2
Entorno para realizar medidas
94
3
Funcionamiento de la implementación de FCM
94
4
3.1 Introducción
94
3.2 Inicialización de objetos
95
3.3
Lectura de los datos
95
3.4
Fase de análisis
95
Comparación del funcioncionamiento con otros analizadores
96
4.1
Xparse-J 1.0
96
4.2
TAMparser
96
4.3
kXML
97
4.4
Medidas con ficheros de tamaño 1728 bytes
97
4.5
Funcionamiento de los distintos modelos
98
4.5
Medidas con ficheros de tamaño 24458 bytes
99
4.6
Codificación soportada por los distintos analizadores
102
5
Características de Funcionamiento de los Modelos
103
6
FCM en la J2SE
103
7
Otras medidas sobre la J2SE
104
7.1
Programas para la generación de documentos XML
105
7.2
Resultados
107
8
7.2.1 Profundidad del archivo
108
7.2.2 Número de atributos
110
Conclusiones
112
CAPÍTULO 5. Conclusiones y Líneas Futuras
113
1
Conclusiones
113
2
Líneas de Avance
116
Índice
Apéndice A. Autodetección de la Codificación de Caracteres
V
119
1
Detección de la codificación
119
2
Prioridades para la información externa de la codificación
121
Apéndice B. UTF-I16S
123
1
Introducción
123
2
Formato de Transformación de UTF-I16S
123
3
Codificación de UCS-4 en UTF-I16S
124
4
Decodificación de UTF-I16S
124
5
Implementación de UTF-I16S en Java
124
Apéndice C. DTD
127
1
Introducción
127
2
Document Type Definitions: Fundamentos
127
3
Lenguajes de Modelado Alternativos
128
Apéndice D. XML Schema
131
1
Introducción
131
2
Fundamentos
131
3
Características de XML Schema
131
4
Definición
132
5
Procesadores de Schema
132
6
Tipos de Datos
132
7
Elemento raíz
133
8
XML Schema frente a DTD
133
Apéndice E. Espacio de Nombres en XML
135
1
Introducción
135
2
Sintaxis
136
VI Contribución al análisis XML para la mejora en las prestaciones de memoria
3
Declaración de espacios de nombres
137
4
Qué son y qué no son los espacios de nombres
138
Apéndice F. Servicios Web XML
141
1
Introducción
141
2
SOAP
141
3
WSDL
142
4
UDDI
142
Apéndice G. Otras Medidas
145
1
Introducción
145
2
Número de objetos
145
Referencias
147
1. Introducción
147
2. Libros
147
3. Revistas, Congresos
153
4. Referencias del autor
160
5. Recomendaciones W3C
163
6. Especificaciones Java
167
6.1 XML
167
6.2 J2ME
169
6.3 Otras Especificaciones Java
171
7. The Internet Engineering Task Force (RFC y draft)
171
8. Unicode
173
9. ISO: International Organization for Standardization
174
10. OASIS
177
11. Software
178
12. Referencias Web
180
13. Otras recomendaciones XML
188
14. Otras recomendaciones y especificaciones
189
Acrónimos
191
Índice de figuras
Plataformas Java.
3
Escenario.
6
Componentes de un dispositivo móvil.
16
Ejemplo de fichero xml.
21
Representación gráfica de un documento XML.
21
Jerarquía de Interfaces del Nivel 2 de DOM.
23
Interfaz Node.
24
Representación gráfica de un árbol DOM.
25
Funcionamiento de la API DOM.
25
Modelo Productor/consumidor en DOM.
27
SAX entrega un documento a una aplicación como una secuencia de eventos.
28
SAX entrega un documento a una aplicación como una secuencia de eventos.
28
Interfaces de SAX 2.0.
29
Interfaz ContentHandler.
30
Funcionamiento de la API SAX.
30
Configuración de la API SAX.
31
Modelo Productor/consumidor en Push.
32
Funcionamiento del modelo Pull.
33
Pull (API para StAX).
34
Interfaz XMLStreamReader.
35
Funcionamiento del modelo Pull al estilo iterador.
36
Funcionamiento del modelo Pull siguiendo el modelo cursor.
36
Modelo Productor/consumidor en Pull.
38
Transferencia del control a través de la invocación de métodos.
46
VII Contribución al análisis XML para la mejora en las prestaciones de memoria
I
Transferencia de control en corutinas.
47
Ejecución de un analizador SAX como una corutina.
48
Ejecución de un analizador SAX como una corutinas.
49
Taxonomía de las APIs XML.
50
Temporización de las APIs XML en Java según Slominski y Haustein.
51
Funcionamiento del modelo Pull-everything de FCM.
72
Funcionamiento del analizador FCM.
73
Funcionamiento del analizador FCM.
74
Productor/Consumidor en FCM.
75
Ejemplo de ejecución en FCM.
76
Estructura que puede dar soporte a un documento bien formado.
80
Estructura alternativa para dar soporte a un documento bien formado.
81
Estructura elegida para dar soporte a un documento bien formado en FCM.
82
Referencias de un elemento.
82
Uso de referencias para representar un elemento.
83
Elementos de la interfaz XMLFCMConstants.
84
Clases de la implementación.
85
Diagrama UML de FCM.
86
Métodos para todos los estados.
87
Métodos para todos los estados START_ELEMENT, END_ELEMENT,
START_DOCUMENT y END_DOCUMENT.
88
Métodos para todos los estados ATTRIBUTE, NAMESPACE,
PROCESSING_INSTRUCTION, ENTITY_REFERENCE y DTD.
89
Métodos para todos los estados SPACE, COMMENT, CDATA y CHARACTERS.
89
Otros métodos parcialmente especificados.
90
Índice de figuras
IX
Funcionamiento del analizador FCM en el WTK..
94
Medidas de los analizadores con un fichero de 1728 bytes.
98
Xparse-J 1.0 con ficheros de 1728 bytes.
98
TAMparser con ficheros de 1728 bytes.
99
kXML con ficheros de 1728 bytes.
99
FCM con ficheros de 1728 bytes.
99
Medidas de los analizadores con un fichero de 24458 bytes.
100
FCM con ficheros de 24458 bytes.
100
Funcionamiento de kXML con ficheros de 24458 bytes.
101
Funcionamiento de TAMparser con ficheros de 24458 bytes.
101
Funcionamiento de Xparse-J 1.0 con ficheros de 24458 bytes.
101
Captura del fichero descargado.
102
Medidas sobre la J2SE.
104
Programa para generar archivos de medidas para la profundidad.
106
Programa para generar archivos de medidas para los atributos.
107
Nombre y tamaño de los ficheros.
108
Medidas de prueba0.xml.
109
Medidas de prueba1.xml.
109
Medidas de prueba2.xml.
109
Medidas de prueba3.xml.
109
Nombre y tamaño de los ficheros.
110
Medidas de atributos0.xml.
111
Medidas de atributos1.xml.
111
Medidas de atributos2.xml.
111
Medidas de atributos3.xml.
111
X
Contribución al análisis XML para la mejora en las prestaciones de memoria
Interfaz UTFI16S.
125
Método intToUtfi16s.
125
Ejemplo de DTD.
128
XML asociado a la DTD.
128
Fragmento de DTD.
132
Ejemplo de XML Schema.
132
Elemento raíz en XSD.
133
Sintaxis de los nombres cualificados.
137
Número de objetos utilizados en ficheros de 1728 bytes.
145
Número de objetos utilizados en ficheros de 24458 bytes.
146
Índice de tablas
Estructura de un carácter UCS-4.
13
Formato de los octetos en una secuencia UTF-8.
14
Requisitos de procesador y memoria para la nueva generación de móviles.
16
Configuraciones en Java ME.
17
Perfiles en Java ME.
17
Paquetes opcionales de Java ME.
18
Pros de los modelos de análisis.
39
Contras de los modelos de anaálisis.
39
Mejor caso para usar el modelos.
40
Analizadores XML de pequeño tamaño.
52
Licencias de los analizadores XML.
52
Resultados numéricos para el fichero de 1728 bytes.
97
Resultados para el fichero de 24458 bytes.
99
Formatos de codificación soportados por los analizadores.
102
Comparación de las características de los modelos.
103
Medidas sobre la J2SE.
104
Medidas sobre la J2SE para prueba0.xml.
108
Medidas sobre la J2SE para prueba1.xml.
108
Medidas sobre la J2SE para prueba2.xml.
108
Medidas sobre la J2SE para prueba3.xml.
108
Medidas sobre la J2SE para atributos0.xml.
110
Medidas sobre la J2SE para atributos1.xml.
110
Medidas sobre la J2SE para atributos2.xml.
110
Medidas sobre la J2SE para atributos3.xml.
110
Byte Order Mark para los distintos formatos de codificación.
120
Secuencia de los primeros bytes para archivos XML sin el uso de BOM.
120
Mapeo de UCS-4 en unidades de 16 bits según UTF-I16S.
123
Códigos para el cambio de página en UTF-I16S.
124
Resumen
El World Wide Web Consortium, publicó la recomendación eXtensible Markup
Language (XML) que permite estructurar mediante marcas, los documentos o flujos de
caracteres, a fin de identificar estructuras u otras unidades en los datos. Mediante el uso
de las marcas de XML se permite tener portabilidad en los datos, con independencia del
propósito y naturaleza de la información.
La implementación de herramientas basadas en los lenguajes de marcas deben
adaptarse a los recursos disponibles para poder ejecutarlos de forma apropiada, y éstos
son limitados en plataformas tales como la plataforma Java para dispositivos móviles,
Java ME. La implementación de las herramientas software para la extracción de
contenidos XML pueden estar condicionadas por las interfaces de programación de la
aplicación (API). Estas interfaces pueden estar basados en eventos o en árboles y
condicionan el funcionamiento en memoria.
Los modelos de análisis XML basados en árboles se consideran demasiado pesados
e intensivos en el uso de memoria. Los modelos de análisis XML basados en eventos se
consideran eficientes en el uso de la memoria pero sólo analizan la información en una
única dirección, hacia delante.
Esta Tesis Doctoral aborda el problema de llevar la tecnología XML a plataformas
con recursos limitados. Con este objetivo, se propone una nueva forma de analizar la
información XML, que minimiza los recursos de memoria utilizados en el proceso de
análisis del documento, permitiendo además el acceso a toda su información.
El nuevo modelo de análisis de documentos XML no sólo permite el movimiento
hacia adelante, en el proceso de generación de los eventos producidos en el análisis de
los datos XML como los modelos Push y Pull, sino que permite gestionar información
previamente analizada. La extensión del modelo Pull a todo el documento XML,
denominada Pull-everything, proporcionando un manejo más eficiente de la información
a analizar.
Para llevar a cabo esta propuesta, se ha implementado una interfaz del nuevo
modelo en la plataforma Java ME. La implementación necesita:
Una representación de la información del documento XML que permita
un acceso eficiente.
Las operaciones que proporcionen las nuevas opciones que ofrece el
nuevo modelo.
La primera tarea se aborda proponiendo una representación serializada de toda la
información XML con soporte para esquemas de codificación basados en 8, 16 y 32 bits
sobre la plataforma Java para dispositivos móviles (Java ME). Los datos se analizan en
el lugar donde se encuentra, es decir, se realiza un análisis “in-situ”.
XIV Contribución al análisis XML para la mejora en las prestaciones de memoria
La segunda operación se realiza extendiendo la interfaz basada en eventos Pull, que
usa métodos específicos para realizar las operaciones de movimiento del cursor hacia
atrás.
Free Cursor Mobility (FCM) es una implementación del nuevo modelo para la
plataforma Java sobre dispositivos móviles (Java ME), ocupándose de las nuevas
operaciones que permite extender la interfaz Pull a Pull-everything, tales como
setCursorToFather(), y setCursorToPreviousSibling().
FCM toma como referencia la implementación StAX (JSR-173), añadiendo las
operaciones que ofrecen una mayor flexibilidad en el análisis de la información del
documento XML.
Mantener una representación serializada de todo el documento para realizar análisis
“in-situ” permite un uso de la memoria menos disperso, facilitando la implementación
de las nuevas operaciones. Este es por ejemplo el caso de la operación que representa el
método skipWithourParseChild(), que permite saltar subsecciones del
documento en la dirección habitual de los modelos basados en eventos sin la creación de
objetos.
Las interfaces basadas en eventos presentan un buen comportamiento de la memoria
utilizada para el análisis de la información XML, aunque no permiten acceder a la
información previamente analizada. Pull-everything extiende los eventos a todo el
documento, mediante el movimiento hacia atrás del lugar de donde se extrae la
información (cursor) en la representación serializada, permitiendo así realizar un
análisis selectivo.
Abstract
Extensible Markup Language (XML), as defined by the World Wide Web Consortium
in 1998, is a method of marking up a document or character stream to identify structural
or other units within the data. XML, and provides a way to mark up contents to give
portability independently nature and purpose of information.
For implementing tools based on markup languages we must conform to resources
available to can be executed properly, and these are limited in platform such as mobiles
devices, Java ME. Software tools follow the criteria established by applications
programming interfaces (API), which conforms different XML parsing models, to give
XML contents. Two kinds of interfaces are available for parsing XML, tree-based
interfaces and event-based interfaces.
A tree-based XML interfaces can be to heavy and intensive in memory. Event-based
interfaces are considered efficient in memory but only manage information forward.
This PhD approaches the problem to handle XML technology to resourcesconstraint platforms. With this idea, we propose a new model for XML parsing, to
optimise memory used, allowing access to all XML information.
The new XML parsing model allows not only forward parsing to generate events,
such a Push o Pull, unless allows information previously read. Extending the pull
interface to entity side events and giving the client full control over external entity
resolution using a pull model puts fewer constraints on the client and widens the range
of application of an XML parser.
To carry out this proposal, we are implemented an interface of new model over the
Java Platform, Micro Edition (Java ME). A implementation of this new model require:
o A representation of all XML information to realize an efficient access to
XML document.
o The new operations that provide new options that can offer the new model.
First point is approached maintain a serialized representation of all entire XML
document to give support for encoding based on 8, 16 and 32 bits over the Java
Platform, Micro Edition (Java ME). In-situ XML parsers, as much as possible, indicate
where data was found in the parsed XML document.
Second point is approached extending the pull interface. We require new methods
to move back cursor.
Free Cursor Mobility (FCM) is a implementation of the new model for the Java
Platform, Micro Edition (Java ME), that extend Pull interface with
setCursorToFather(), and setCursorToPreviousSibling(), to conform Pull-everything.
The implementation has been realized appends to StAX implementation (JSR-173) the
new model's capabilities.
XVI
Contribución al análisis XML para la mejora en las prestaciones de memoria
"In-situ" XML parsing leaves the XML data in the original location or device from
where it was provided to the XML parser, rather than copying it into the XML parser.
An in-situ parser passes data to its client by referring to the original data rather than by
providing the client with the parser's copy.
An event-based interface has a good performance in memory, but not allows access
information previously read. Pull-everything extends events to all XML information to
allow access information previously read.
CAPÍTULO 1.
Introducción
Este capítulo realiza una introducción a las tecnologías utilizadas a fín de poder mostrar
de forma guiada y justificada la motivación y los objetivos de la Tesis Doctoral. En
primer lugar se realiza una introducción y una justificación a los lenguajes de marcas. A
continuación se introduce Java como lenguaje para implementar herramientas de
tratamiento y análisis de la información. Se presentan los modelos de análisis existentes
y el contexto en el que se realizará la implementación y las pruebas presentadas en este
trabajo. Finalmente se da una panorámica de este documento.
1 Preliminares.
Los lenguajes de marcas (Markup Languages) permiten estructurar los documentos o
flujos de caracteres, identificando estructuras y otras unidades en los datos, para manejar
datos portables, con independencia del propósito y naturaleza de la información.
Tradicionalmente, los lenguajes de marcas se han utilizado para dar soporte a la
publicación de texto. En 1986, el Internacional Standards Organisation (ISO) publica el
Standard Generalizad Markup Language (SGML), estandarizando un formato neutral e
independiente de la plataforma y fabricantes. SGML es un lenguaje de marcas que
recoge la sintaxis, una lista de palabras clave y parámetros para especificar el formato
del documento mediante la definición de un tipo de documento (Document Type
Definition) o DTD. Las DTDs determinan los elementos válidos en un documento. Las
distintas organizaciones e industrias especifican plantillas DTD para definir manuales
técnicos, referencias de libros, artículos para revistas, patentes, ... Sin embargo, SGML
es un estándar grande y complejo, con muchas características opcionales, algunas de
ellas raramente utilizadas.
Para la publicación e intercambio de información en Internet se necesitan
soluciones de publicación y edición más sencillas. En 1991 se añadió la posibilidad de
2
Contribución al análisis XML para la mejora en las prestaciones de memoria
enlazar documentos en Internet. Cada documento Web se codifica en HyperText
Markup Language (HTML). Este lenguaje de marcas soporta la funcionalidad de enlace
de hipertexto, además de otros formatos de cabecera, párrafos, listas y tablas.
Sin embargo HTML carece de la capacidad de tener marcas autodescritas y
personalizadas. La evolución fue una combinación de la simplicidad de HTML y la
potencia de SGML, apareciendo el eXtensible Markup Language (XML) el 10 de
Febrero de 1998. XML superficialmente es parecido a HTML, pero incorpora
características del núcleo de SGML. XML es un formato que permite el intercambio de
datos entre sistemas y bases de datos, y se ha adoptado como tecnología de publicación
en la Web.
En la actualidad, la aparición de nuevos servicios sobre Internet han hecho aparecer
nuevas tecnologías basadas en los lenguajes de marcas. Las e-technologies (como ecommerce, e-business, e-government, e-science, e-health, e-learning, …) habitualmente
utilizan como intercambio documentos basados en los lenguajes de marcas. Internet es
hoy en día el mejor soporte para el transporte de la información. Los puntos clave para
la concepción de estos modelos de intercambio son la ejecución de aplicaciones en
cualquier lugar y en cualquier momento sobre cualquier plataforma.
Por otra parte, las telecomunicaciones inalámbricas han tenido un fuerte
crecimiento durante los últimos años. Esto ha provocado que se hayan convertido en una
de las áreas de mayor desarrollo en todo el mundo, con un gran número de tecnologías y
sistemas asociados.
La heterogeneidad es un hecho en todos los ámbitos, en el mundo de los
dispositivos de consumo existen diferentes CPUs y arquitecturas de sistemas.
Inicialmente en el mundo de los ordenadores las diferentes arquitecturas hardware
(WinTel y Macintosh) seccionaron el mercado basándose en detalles de bajo nivel. Pero
hay muchas más barreras que dificultan la interoperabilidad, y sin embargo los sistemas
evolucionan hacia la ejecución en un entorno donde los recursos están distribuidos. La
ejecución en entornos distribuidos es principalmente necesaria en dispositivos con
capacidad de procesamiento y memoria limitada, como son las plataformas embebidas,
y los dispositivos móviles.
La aparición de gran variedad de aplicaciones para móviles de carácter tanto
competitivas como complementarias han llevado a la industria de móviles a centrarse en
Java como plataforma principal de soporte para ellas. En contraposición a las
arquitecturas basadas en el hardware, Java propone una Máquina Virtual software, JVM
(Java Virtual Machine) [JVM], sobre la que se pueden ejecutar sus instrucciones de
código binario (o bytecode). Es un gran paso hacia la portabilidad, utilizándose un
código intermedio y una plataforma software donde poder ejecutarlo, y estableciéndose
de este modo con firmeza la premisa WORA ("Write Once, Run Anywhere").
Capítulo 1. Introducción.
3
La KVM (K Virtual Machine) [KVM 05] es la Máquina Virtual de Java para los
dispositivos de consumo con recursos limitados, tales como teléfonos celulares. Esta
Máquina Virtual representa una de las plataformas Java conocida como Java 2, Micro
Edition, o Java ME (anteriormente J2ME) [J2ME], y fue implementada entre otros por
Antero Taivalsaari [Taivalsaari 04], en el rediseño de la J2EE/J2SE. La arquitectura de
la Java ME contiene perfiles y configuraciones, tales como CDC (Connected Device
Configuration) y CLDC (Connected, Limited Device Configuration). En la Figura 1.1 se
muestran las tres plataformas de Java: J2EE, J2SE y J2ME (renombrada como Java
ME). La plataforma Java 2, Enterprise Edition (J2EE) es fruto de la colaboración de Sun
con los líderes del sector del software empresarial (IBM, Apple, Bea Systems, Oracle,
Inprise, Hewlett-Packard, Novell, etc.) para definir una plataforma robusta y flexible
orientada a cubrir las necesidades empresariales en e-business. Java 2 Platform,
Standard Edition (J2SE), es un subconjunto de J2EE. La plataforma Java 2, Micro
Edition, es una colección de APIs en Java orientadas a productos de consumo como
PDAs, teléfonos móviles y otros electrodomésticos, que contiene las configuraciones
CLDC y CDC.
Figura 1.1: Plataformas Java.
La KVM es independiente de la tecnología de red. Es válida para dispositivos de la
segunda, de la 2.5, y de la tercera generación.
El presente trabajo contribuirá a la mejora en el funcionamiento y la ejecución de
aplicaciones basadas en XML, utilizando como entorno de referencia la plataforma
J2ME. Para ello, se propondrá un modelo de análisis de la información XML que será
implementado, validado y evaluado.
2 Motivación y entorno
El intercambio de información entre distintas plataformas, así como la posibilidad de
integración y composición hacen que la adopción de estándares, como XML, sean
claves para asegurar la interoperabilidad entre diferentes sistemas. El uso de
aplicaciones basadas en XML supone una ventaja, al determinar mediante marcas, la
información y propósito de la misma, pudiéndola mantener de forma eficiente en
documentos para su almacenamiento o intercambio. Con este propósito son
4
Contribución al análisis XML para la mejora en las prestaciones de memoria
indispensables herramientas software para la extracción de la información contenida en
ellos. Los analizadores procesan la información extraída de un documento XML y la
ofrecen a la aplicación para su procesamiento y gestión.
No todas las herramientas de análisis deben de estar escritas en el lenguaje de
programación Java. Sin embargo, el tratamiento y orientación de la información
proporcionada por los lenguajes de marcas, hacen que el uso de la portabilidad del
lenguaje de programación Java, sea una buena elección para la implementación de
analizadores que extraigan la información de los documentos XML.
A diferencia de lo que sucede en la J2SE, la plataforma Java para dispositivos
inalámbricos (Java ME) no es una única especificación o implementación software, sino
que consiste en una colección de tecnologías y especificaciones que están diseñadas por
partes. Esta plataforma toma como referencia a JWTI (JavaTM Technology for the
Wireless Industry) [JSR-185] con el fin de establecer unos criterios para mejorar la
compatibilidad e interoperabilidad, minimizando la fragmentación que se pueda
producir debido al alto volumen de dispositivos. En esta especificación se establecen
recomendaciones del tamaño de las aplicaciones, que son muy severas en cuanto a la
memoria que pueden utilizar. Estas restricciones han provocado que se utilicen
herramientas, como los ofuscadores [Proguard] [Retroguard], que se usan en esta
plataforma con el objetivo de disminuir el tamaño del fichero de la aplicación.
La implementación de aplicaciones basadas en XML sobre la plataforma J2ME
tiene características específicas para esta plataforma. Un denominador común que
siempre está presente es la cantidad de memoria necesaria, tanto por el tamaño de la
aplicación en sí, como por la memoria que utiliza durante la ejecución del programa. La
memoria es un criterio de diseño de cualquier aplicación sobre plataformas con recursos
limitados, y por tanto los analizadores XML que se utilizan en esta plataforma debe
tenerlos en cuenta. Aplicaciones utilizadas en otras plataformas no tienen un tamaño
apropiado para esta plataforma.
Las interfaces de programación de la aplicación (API) proporcionan métodos
estándar para que un analizador proporcione la información contenida en un documento
XML, y puede condicionar un funcionamiento diferente, no solo en el tamaño de la
aplicación sino en la memoria utilizada durante su ejecución, por lo que han debido ser
adaptadas a plataformas con recursos limitados. Estas interfaces pueden ser de dos tipos,
las basadas en árboles o las basadas en eventos. Los analizadores XML basados en
árboles leen un documento XML entero y construyen una representación interna en
memoria, donde cada nodo del árbol representa un trozo del documento original. De
esta forma se permite a una aplicación navegar y manipular los datos analizados de una
forma fácil y rápida.
Capítulo 1. Introducción.
5
El Modelo de Objeto del Documento (DOM) propuesto por el W3C, es una interfaz
basada en árboles para el análisis XML. Un analizador DOM puede ser intensivo en el
uso de recursos ya que mantiene el documento entero en memoria. Este es un grave
inconveniente en algunas plataformas, y especialmente en la plataforma Java ME en la
cual se centra este trabajo.
Por otra parte, los analizadores XML basados en eventos entregan los eventos
generados por el analizador en el proceso de lectura del documento XML directamente a
la aplicación. Los analizadores basados en eventos leen la información apuntada por el
cursor en la información XML para generar los distintos eventos, y dependiendo del tipo
de información leída generarán eventos. Un analizador basado en eventos es más rápido
en ejecución y consumen menos recursos que un analizador basado en árboles.
Los modelos de análisis basados en eventos son Push y Pull. Un analizador Push
llama a los métodos del cliente con los eventos XML. Un analizador Pull devuelve los
eventos XML al cliente secuencialmente bajo petición. Simple API for XML (SAX) es
la única interfaz XML para el modelo Push; Streaming API for XML (StAX) es la más
conocida interfaz del modelo Pull.
Los analizadores basados en eventos leen la información apuntada por el cursor en
los documentos XML (o en alguna representación del documento). En función de dicha
información generan los distintos eventos, pero el analizador no gestiona la información
previamente leída. Presentan un buen comportamiento en cuanto a la memoria utilizada
para el análisis de la información XML, pero al contrario que los analizadores basados
en árboles no permiten acceder a la información previamente analizada.
Sería deseable por tanto, utilizar un modelo de análisis para los documentos XML
que, basándose en el buen comportamiento en memoria que presenta los analizadores
basados en eventos, permitiese además el acceso a la información previamente
analizada, y el análisis de la información de forma selectiva bajo demanda de la
aplicación para optimizar los recursos del entorno en el que se ejecuta.
Resumiendo, para que se puedan utilizar en plataformas con recursos limitados
aplicaciones basadas en XML se necesitan analizadores ligeros en cuanto al uso de los
recursos en el proceso de análisis, pudiendo acceder a toda la información que
proporciona el documento. Los analizadores utilizados en plataformas como J2SE/J2EE
no son válidos para Java ME, su tamaño es inapropiado, y la readaptación del mismo
código no es eficiente, ya que no es un código que se haya pensado inicialmente para
esta plataforma y suele tener en cuenta otros aspectos diferentes a los que se necesitan
en el entorno en el que se está considerando.
En Java ME, los analizadores soportan normalmente un subconjunto estricto de
funcionalidades disponibles para otras plataformas. El tamaño de la aplicación debe ser
menor. Java ME para los sevicios Web XML, JSR-172, [JSR-172] no proporciona
6
Contribución al análisis XML para la mejora en las prestaciones de memoria
soporte para DOM. DOM se considera demasiado “pesado”, en términos de tamaño de
la implementación y de la memoria utilizada.
Los dispositivos inalámbricos con plataforma J2ME permiten el acceso a Internet.
De esta forma se pueden ejecutar aplicaciones basadas en XML para el intercambio de
información en entornos distribuidos y cooperativos. El entorno de trabajo al que se
dirige este trabajo está formado en su configuración más sencilla por un dispositivo
móvil que contiene una máquina virtual Java para dichos dispositivo (KVM), y en el
que se quiere dar capacidad de análisis de los documentos XML, con objeto de dar
soporte a aplicaciones basadas en XML, tales como servicios Web realizando peticiones
mediante el uso de SOAP (Simple Object Access Protocol). Este esquema puede
observarse en la Figura 1.2. La motivación principal para ello consiste en dar
flexibilidad en el análisis de documentos XML con un eficiente consumo de la memoria
utilizada, y manteniendo la posibilidad de acceso a todo el documento XML.
Figura 1.2: Escenario.
3 Objetivos.
El objetivo principal de esta propuesta es contribuir a la mejora en la implementación de
aplicaciones basadas en XML sobre la plataforma Java para móviles, Java ME. Para ello
se proponen un nuevo modelo de análisis de documentos XML, basado el movimiento
libre del cursor a lo largo de la representación serializada de los datos XML, en el marco
de los dispositivos limitados en memoria. Para ello se proponen las siguientes metas
parciales:
o Analizar los modelos existentes en el análisis de documentos XML.
o Especificar un modelo que permita realizar un consumo mínimo de la
memoria utilizada en el proceso de análisis de los documentos XML,
pudiendo acceder desde el analizador a toda la información del documento.
Para ello será necesario:
o Implementar una representación del documento XML de forma que
se pueda acceder a toda la información que contenga. Para ello será
necesario proponer una nueva representación serializada de todo el
documento XML con soporte para esquemas de codificación basados
Capítulo 1. Introducción.
7
en 8, 16 y 32 bits sobre una plataforma Java para dispositivos
móviles (Java ME).
o Implementar los métodos que proporcionen las nuevas operaciones
que ofrece el nuevo modelo, basándose en el modelo de análisis Pull
de documentos XML, mediante el uso de los métodos del iterador
que utiliza StAX (JSR-173). Se deberán añadir nuevas operaciones
que ofrezcan una mayor flexibilidad en el análisis de la información
del documento XML, con el movimiento del cursor hacia atrás en la
representación serializada del documento XML, por una parte, y con
el análisis selectivo de subsecciones por otra.
o Validación y evaluación del modelo. Para ello se ha realizado una
implementación para la plataforma Java para móviles.
4 Contenido y organización de la memoria.
El resto de la memoria está organizada como se describe a continuación. El capítulo 2
introduce los conceptos generales de XML, codificación y lenguaje de programación
sobre el que se enmarca la propuesta. Este capítulo presenta el proceso y los modelos de
análisis de un documento XML. Establece una clasificación para marcar las diferencias
que hay entre los distintos modelos de análisis y se realiza una valoración con pros,
contras y el mejor para los modelos existentes. Se detallan trabajos previos y una amplia
clasificación de los analizadores sobre las plataformas de Java.
El capítulo 3 presenta el nuevo modelo de análisis de los documentos XML.
Explica la extensión del modelo Pull, presenta el modelo productor y consumidor, y las
nuevas operaciones soportadas. Este capítulo muestra el uso de la implementación del
prototipo realizado, Free Cursor Mobility, en el lenguaje de programación Java.
Posteriormente se incluye una implementación del modelo realizado sobre la plataforma
Java para dispositivos móviles. Se detalla la estructura utilizada para la comprobación
de que el documento esté bien formado y se presenta la interfaz relacionada con los
eventos.
En el capítulo 4 se lleva a cabo un análisis comparativo del rendimiento del modelo
propuesto. Se realizan medidas y se presenta el comportamiento de la evolución
temporal de la memoria utilizada en los analizadores elegidos como representación de
los modelos de análisis. Se describe el funcionamiento del modelo implementado y se
muestra el funcionamiento para otras implementaciones que usan otros modelos de
análisis. Así mismo, se muestran los esquemas de codificación soportados por las
distintas implementaciones. Con el prototipo implementado se ha realizado una serie de
pruebas sobre la plataforma J2SE y se presentan y analizan los resultados obtenidos.
8
Contribución al análisis XML para la mejora en las prestaciones de memoria
Finalmente, en el capítulo de conclusiones se resumen las principales
contribuciones y resultados de la Tesis Doctoral, apuntando una serie de posibles líneas
de investigación futuras.
Para la comprensión más profunda del trabajo realizado se ha creido conveniente
añadir una serie de apéndices al final de la memoria.
En el Apéndice A, se detalla como se realiza la detección de la codificación externa
de los ficheros XML.
El Apéndice B muestra el formato de transformación UTF-I16S para la
transformación de los caracteres ISO 10646 en unidades de 16 bits.
En el Apéndice C se presenta un modelo de validación de los documentos XML, las
DTD, que permiten determinar los tipos datos que pueden aparecen en un documento
XML, mientras que el Apéndice D trata sobre la validación de documentos XML
utilizando sintaxis basada en XML (XML Schema).
En el Apéndice E se presenta el uso y detalles relacionados con los espacios de
nombre en XML.
En el Apéndice F se presentan los servicios Web XML y estándares relacionados.
Finalmente, en el Apéndice G se presenta otras medidas.
CAPÍTULO 2.
Análisis de la información XML
La industria ha utilizado métodos de intercambio de datos que son específicos de un
determinado sector. Con la llegada del comercio electrónico, los negocios
incrementaron el número de relaciones entre los distintos sectores industriales. XML
hace extensible sus herramientas para el intercambio de datos en los distintos sectores
industriales. Los datos intercambiados en los documentos XML se codifican siguiendo
formatos de codificación y transformación, y necesitan de herramientas de análisis de la
información XML. Los analizadores XML son programas que extraen la información de
un documento XML, y permiten a una aplicación acceder a los datos mediante una
interfaz de programación o API (Application Programming Interface) en algún lenguaje
de programación. Debido a su portabilidad, Java es en un punto de conexión no sólo
entre plataformas sino entre desarrolladores. En este capítulo se presentan una
caracterización del análisis de los documentos XML. Se introduce la plataforma Java
para dispositivos móviles. Se muestran las características y aspectos diferentes en el
comportamiento de un analizador XML. Se presentan formatos de transformación para
la codificación de caracteres. Posteriormente, se presentan modelos de análisis
relacionados y se presentan las distintas interfaces para los modelos de análisis.
Además, se detallan y clasifican las implementaciones realizadas.
1 Introducción.
El lenguaje de marcas extensible, XML, es un lenguaje de propósito general
recomendado por el W3C (Word Wide Web Consortium) para la creación de otros
lenguajes de marcas de propósito específico. Una de sus principales ventajas es la
capacidad de compartir datos entre sistemas distintos, normalmente a través de Internet.
Lenguajes basados en XML, cada uno de ellos con un propósito diferente, como por
ejemplo RDF (Resource Description Framework) [RDF], MathML (Mathematical
Markup Language) [MathML], XHTML (Extensible HyperText Markup Language)
[XHTML], SVG (Scalable Vector Graphics) [SVG] y cXML (Commerce XML)
[cXML], se pueden definir una forma sencilla, permitiendo a los programas modificar y
validar documentos en estos lenguajes sin un conocimiento de su forma.
La versión 1.0 de XML es una recomendación del W3C publicada en Febrero de
1998. Está basada en el anterior estándar (SGML, Standard Generalized Markup
10
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Language), que data de 1986. Sus conceptos están ampliamente asentados y aceptados.
SGML es el descendente de Generalized Markup Language (GML) de IBM,
desarrollado en 1960 por Charles Goldfarb, Edward Mosher y Raymond Lorie. GML
precedió y fue una inspiración para el desarrollo de SGML en la creación de un conjunto
de reglas para cualquier lenguaje de descripción de un documento estructurado.
SGML [SGML] proporciona una variedad de sintaxis de marcas que pueden usarse
por distintas aplicaciones. Fue diseñado originalmente para compartir documentos
legibles por las máquinas en grandes proyectos del gobierno y la industria aeroespacial,
los cuales han permanecido legibles durante décadas. Este estándar, ISO 8879, ha sido
usado ampliamente en la edición y publicación de documentos, como DocBook
[DocBook] que originalmente se basó en SGML para, según su página de su diseñador
Norman Walsh[DocBook 06], crear un vocabulario XML (y SGML) que se use para
escribir documentación técnica (entre otras cosas).
Aunque HTML fue originalmente diseñado de forma independiente, posteriormente
fue reformulado (en la versión 2.0) para ser una aplicación de SGML. Las páginas Web
están formadas por marcas HTML y son un ejemplo de un documento que hace uso de
los conceptos de GML.
De SGML derivó XML como subconjunto simplificado, eliminando las partes más
engorrosas y menos utilizadas. Al igual que SGML, XML es un metalenguaje: un
lenguaje para definir lenguajes. Los elementos que lo componen pueden dar
información sobre lo que contienen, no necesariamente sobre su estructura física o
presentación, como ocurre en HTML. HTML también se definió utilizando XML. En
una primera aproximación, las diferencias entre ambos residen en que HTML es
simplemente un lenguaje, mientras que XML un metalenguaje, es decir, se trata de un
lenguaje para definir lenguajes.
XML se asoció desde el principio a la recomendación del W3C DOM (Document
Object Model), aprobado también en 1998. Éste no es más que un modelo de objetos
que, en forma de API (Application Programming Interface), permite acceder a las
diferentes partes que pueden componer un documento XML o HTML (HyperText
Markup Language). SGML proporciona un modo consistente y preciso de aplicar
etiquetas para describir las partes que componen un documento, permitiendo además el
intercambio de documentos entre diferentes plataformas. Sin embargo, el problema que
se le atribuye es su excesiva dificultad.
XML se utiliza para la especificación de protocolos tales como SOAP (Simple
Object Acces Protocol), pensados para el intercambio de información descentralizada,
sobre protocolos tales como HTTP (Hyper Text Transfer Protocol) [RFC 2616], FTP
(File Transfer Protocol) [RFC 959] o SNMP (Simple Network Management Protocol)
[RFC 1157] en entornos distribuidos para el uso de servicios Web XML. SOAP es un
Capítulo 2. Análisis de la información XML.
11
protocolo de datos basado en XML estandarizado por el W3C con el propósito de
habilitar el intercambio de datos sobre Internet. En un escenario típico con los servicios
Web, un mensaje SOAP que se entrega a través de HTTP necesita analizarse antes de
realizar cualquier operación.
Los documentos XML están formados por unidades de almacenamiento llamadas
entidades, las cuales contienen datos analizados o no analizados. Los datos analizados
están formados por caracteres; algunos de ellos forman caracteres de datos, y otras
marcas. Las marcas codifican una descripción del diseño de almacenamiento y de la
estructura lógica del documento. XML proporciona un mecanismo para imponer
restricciones sobre el diseño de almacenamiento y la estructura lógica.
Los objetivos de diseño para XML fueron:
XML debe ser directamente utilizable en Internet.
XML debe soportar una amplia variedad de aplicaciones.
XML debe ser compatible con SGML.
Debe ser sencillo escribir programas que procesen XML.
El número de características opcionales en XML debe ser mantenido al
mínimo posible, idealmente cero.
Los documentos XML deben ser legibles por humanos y razonablemente
claros.
El diseño de XML debe estar preparado rápidamente.
El diseño de XML debe ser claro y conciso.
Los documentos XML deben ser de fácil creación
La concisión en las marcas para dar mayor importancia a los datos.
Hay también un gran número de lenguajes relacionados de alguna forma con SGML
y XML, pero estos no pueden ser analizados, validados o procesados usando las
herramientas XML y SGML, y por tanto no pueden considerarse como aplicaciones de
SGML y XML. Un ejemplo es Z Format [Z Format], un lenguaje diseñado para edición
y documentación. Z Format es lenguaje codificado por David H. Kristensen y Dan Ponte
para la composición tipográfica. Z Format tiene una base cercana a XML y SGML y está
inspirado en el precedente de látex, TEX.
2 Codificación de caracteres. Formatos de Transformación
2.1 Generalidades
La codificación de texto como una secuencia de caracteres sin más información, permite
obtener una secuencia lineal normalmente conocida como texto plano. Un carácter sigue
a otro, sin ninguna estructura. El "marcado" permite definir una estructura jerárquica
para el texto o los datos.
12
Contribución al análisis XML para la mejora en las prestaciones de memoria.
De forma general, la codificación de caracteres es el código que empareja cada
carácter con un símbolo en otro sistema de representación, como por ejemplo un
número. El tamaño de esta representación puede ser mayor que el utilizado para su
procesamiento o almacenamiento. En este caso, se hace necesario algún tipo de
transformación, y de esta necesidad surgen los diferentes formatos de transformación de
la representación numérica de los caracteres.
Un estándar de codificación proporciona la base para el procesamiento
almacenamiento e intercambio de datos de texto en cualquier lengua sobre un software
moderno y/o en los protocolos de información. Aunque éste debiera ser único, no es así.
Unicode, por una parte y según su propia definición, es la codificación de caracteres
universal, mantenida por Unicode Consortium [Unicode HP]. ISO/IEC 10646, por otra,
es un estándar más reciente, International Organization for Standardization (ISO)
publicó el Universal Multiple-Octet Coded Character Set (UCS), para la representación,
transmisión, intercambio, procesamiento, almacenamiento, entrada y representación de
la forma escrita de todos los lenguajes y símbolos adicionales. Desde la versión 1.1 de
Unicode se ha intentado mantener de forma escrupulosa compatibilidad con ISO/IEC
10646 y sus extensiones.
Para poder dar a cada carácter un formato de representación única, los diseñadores
de UCS eligieron una codificación uniforme, usando una secuencia de bits formada por
16 o 31 bits (en dos formas de codificación, UCS-2 y UCS-4). Esta es la razón por lo
que aparece la frase "multiple-octet" en el nombre del estándar.
Según la recomendación XML, refiriéndose a sí misma: "Esta especificación, junto
con los estándares asociados (Unicode e ISO/IEC 10646 para caracteres, Internet RFC
1766 para las etiquetas de identificación de idiomas, ISO 639 para los códigos de
nombre para el lenguaje, e ISO 3166 para el código de nombre del país), proporciona
toda la información necesaria para entender XML versión 1.0 y construir programas
para procesarlo".
El procesamiento se realiza habitualmente sobre algún lenguaje de programación
que soporta una representación de los caracteres diferentes al rango de codificación del
estándar utilizado.
2.2 ISO/IEC 10646
ISO/IEC 10646 define las siguientes formas de codificación:
La codificación en 4 octetos (32 bits) que utiliza hasta 231 posiciones.
Una codificación en dos octetos (16 bits) con los caracteres del plano
cero, el Basic Multilingual Plane (BMP).
Capítulo 2. Análisis de la información XML.
13
La arquitectura de un carácter ISO/IEC 10646 en 4 octetos contiene divisiones
conceptuales divididas en 128 grupos de 256 planos, con cada plano conteniendo 256
filas de 256 células, tal y como se puede ver en la Tabla 2.1.
Grupo
0xxxxxxx
primer octeto
Plano
xxxxxxxx
segundo octeto
Fila
xxxxxxxx
tercer octeto
Célula
xxxxxxxx
cuarto octeto
Tabla 2.1: Estructura de un carácter UCS-4.
Para poder detectar la codificación sin necesidad de entidades externas, XML
proporciona en su recomendación instrucciones para la detección de los valores, tanto
para UCS-4 como para el resto de formatos.
2.3 Unicode
Unicode ha comenzado a reemplazar a otros esquemas de codificación como ASCII,
ISO 8859 y Extended Unix Code (EUC) a todos los niveles [Kuhn]. Éste habilita a los
usuarios a manejar no sólo prácticamente todos los alfabetos y lenguajes usados, sino
que además soporta un gran conjunto de símbolos matemáticos y técnicos para facilitar
el intercambio de la información.
El conjunto de caracteres Unicode 3.0 ocupa un espacio de 16 bits. Es la
codificación Unicode más simple, conocida como UCS-2; su codificación se realiza
mediante una secuencia de palabras de 16 bits. La mayor parte de las herramientas Unix
esperan ficheros ASCII y no pueden leer palabras de 16 bits sin algún tipo de
modificación. UCS-2, sobre Unix, no resulta apropiado para la codificación externa de
Unicode en nombres de ficheros, ficheros de texto, variables de entorno, etc.
Como se ha comentado anteriormente, ISO/IEC 10646 define un conjunto de
caracteres multiocteto conocido como UCS que comprende la mayor parte de sistemas
de escritura. Los caracteres multiocteto, sin embargo, no son compatibles con muchas
aplicaciones y protocolos, lo cual ha provocado el desarrollo de unos formatos de
transformación de UCS, cada uno con unas características diferentes. Los más
representativos son UTF-8, UTF-16 y UTF-32.
2.4 UTF-32
UTF-32 representa los valores como unidades enteras de 32 bits con el mismo valor que
el valor escalar Unicode. En UTF-32 los valores de la secuencia <004D, 0430, 4E8C,
10302> se representa como <0000004D 00000430 00004E8C 00010302>.
2.5 UTF-8
UTF-8 representa los valores en una longitud variable de unidades de 8 bits, tal y como
se muestra en la Tabla 2.2.
14
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Octeto de uso Formato (binario) nº de bits libres Máximo valor de UCS-4(hexa)
1º de 1
0xxxxxxx
7
0000 007F
1º de 2
110xxxxx
5
0000 07FF
1º de 3
1110xxxx
4
0000 FFFF
1º de 4
11110xxx
3
001F FFFF
1º de 5
111110xx
2
03FF FFFF
1º de 6
1111110x
1
7FFF FFFF
2º .. 6º
10xxxxxx
6
Tabla 2.2: Formato de los octetos en una secuencia UTF-8.
UTF-8 preserva el rango de la codificación ASCII, proporcionando compatibilidad
con los sistemas de ficheros, analizadores y otro software que dependan de valores
ASCII. La codificación de UCS-4 a UTF-8 según la RFC 2279 [RFC 2279], es de la
siguiente forma:
1. Se determina el número de octetos requeridos para el valor del carácter,
según la última columna de la Tabla 2.2. Es importante ver que las filas son
mutuamente exclusivas para la obtención del primer octeto.
2. Se preparan los bits de mayor peso del octeto, según la segunda columna de
la Tabla 2.2.
3. Se rellenan los bits marcados con x con los bits del valor del carácter,
comenzando desde el bit de menor peso del valor del carácter, y
colocándolos primero en el último octeto de la secuencia, luego en el
siguiente hasta llegar al último, de forma que se rellenen todos los bits
marcados con x.
La decodificación de UTF-8 a UCS-4 es el proceso inverso al de codificación y se
obtiene un valor entero de 31 bits de una secuencia de bytes de longitud variable según
el formato de codificación anteriormente explicado.
2.6 UTF-16
Para transformar la representación numérica de un carácter según UTF-16 [RFC 2781]
se procede de la siguiente forma. Sea U el número de un carácter, no mayor que
0x10FFFF,
1. Si U < 0x10000, se codifica el valor U como un entero sin signo y se
termina.
2. Sea U’ = U – 0x10000. Ya que U es menor o igual que 0x10FFFF, U’
debería ser menor o igual que 0xFFFF. Es decir, U’ puede representarse en
20 bits.
3. Se toman dos enteros sin signo de 16 bits, W1 y W2, con un valor inicial de
0xD800 y 0xDC00, respectivamente. Estos enteros tienen cada uno de ellos
10 bits libres para poder codificar el valor del carácter, hasta un total de 20
bits.
Capítulo 2. Análisis de la información XML.
15
4. Se asignan los 10 bits de menor peso de los 20 bits de U’ a los 10 de menor
de W1 y los 10 bits de menor peso de U’ a los 10 bits de W2. Y se termina.
De forma gráfica los pasos del 2 al 4 son tal como se especifica a continuación:
U’ = yyyy yyyy yyxx xxxx xxxx
W1 = 1101 10yy yyyy yyyy
W2 = 1101 11xx xxxx xxxx
Los valores entre 0xD8000 y 0xDFFF están reservados por UTF-16, y no tienen
ningún carácter asignado a ellos.
3 Java 2 Platform, Micro Edition (Java ME)
3.1 Introducción
XML es una sintaxis universal para describir y estructurar datos con independencia de la
aplicación lógica. Muchas de estas aplicaciones han elegido la tecnología Java como
soporte para su implementación, y debido a su naturaleza portable hacen una
combinación perfecta. La tecnología Java se creó como una herramienta de
programación en el proyecto denominado "the Green Project" en Sun Microsystems en
el año 1991. El equipo "Green Team" fue compuesto por trece personas y dirigido por
James Gosling. Una de las tres plataformas de ejecución de Java es la Micro Edition, ó
Java ME (anteriormente J2ME). Ésta proporciona un entorno de aplicación que va
dirigido especialmente a las necesidades de un amplio y de rápido crecimiento espacio
de consumidores, que incluyen entre otros teléfonos móviles y PDAs (Personal Digital
Assistants).
Las especificaciones para Java SE [Java SE], Java EE [Java EE], y Java ME [Java
ME] se han desarrollado tomando como eje central a Java Community Process (JCP).
Una especificación Java comienza como una Java Specification Request (JSR). Un
grupo de expertos que representan distintas las compañias se forman para crear una
especificación. Las JSR pasan a través de varios estados en el JCP antes de su
finalización. Cada JSR tiene asignado un número.
La tecnología Java 2 Platform, Micro Edition (Java ME) consta de una Máquina
Virtual y de un conjunto de APIs para proporcionar entornos de ejecución hechos para
dispositivos de consumo y electrónica “embebida”.
Actualmente, una gran cantidad de dispositivos móviles, PDAs y otros sistemas
embebidos, presentan una plataforma de recursos limitados en la que se puede utilizar
Java. Sin embargo, sus recursos disponibles, entérminos de CPU, ROM, RAM y
capacidad de presentación en pantalla son limitados. La Tabla 2.3 muestra los requisitos
de procesador y memoria para la nueva generación de móviles según se especifican en la
16
Contribución al análisis XML para la mejora en las prestaciones de memoria.
implementación de la máquina virtual de la CLDC HotSpot [HotSpot 03]. En esta tabla
se presentan los requisitos mínimos y típicos para procesador y memoria.
Item
Tipo de CPU
Velocidad de la CPU
RAM
ROM/flash
Mínimo
Típico
ARM
ARM
12MHz
60MHz
300KB (incluyendo MIDP) 600KB (incluyendo MIDP)
1MB
1.5MB
Tabla 2.3: Requisitos de procesador y memoria para la nueva generación de móviles.
Debido a su bajo consumo, el procesador ARM está presente la mayoría de
dispositivos que hay en el mercado para este tipo de dispositivos. Por otra parte, al tener
la memoria limitada, es de extrema importancia que se minimice la cantidad de dicha
memoria que ocupan tanto la máquina virtual como las librerías CLDC.
3.2 KVM
La KVM (K Virtual Machine) es la nueva implementación de la Máquina Virtual de
Java, que acepta el mismo conjunto de instrucciones de código máquina (realmente unas
pocas menos) y el mismo formato para los ficheros que la máquina virtual clásica. En la
Figura 2.3 se muestran los componentes de la KVM en un dispositivo móvil.
Figura 2.3: Componentes de la KVM sobre un dispositivo móvil.
3.3 APIs
Java ME está dividida en configuraciones, perfiles y paquetes opcionales. Las
configuraciones son especificaciones Java (Java Specification Request ó JSR) que
detalla la máquina virtual y el conjunto de API que pueden usarse con ciertos
dispositivos. La tabla 2.4 muestra las configuraciones existentes para Java ME. Existen
dos posibles configuraciones para la Java ME, estas son: Connected, Limited Device
Configuration (CLDC) y Connected Device Configuration (CDC).
CLDC 1.1 [JSR-139] es una versión revisada de la especificación CLDC 1.0 [JSR30] que incluye nuevas características tales como el punto flotante, soporte para
referencias débiles y otras mejoras. CLDC 1.1 es debe ser compatible con las
Capítulo 2. Análisis de la información XML.
17
implementaciones en CLDC 1.0, y mantiene las características en cuanto al tamaño en
memoria en los dispositivos con recursos limitados que presenta CLDC 1.0.
CDC [JSR-36] proporciona la base de Java ME en dispositivos con un
microprocesador de mayor tamaño (al menos de 32 bits) y una mayor memoria que
CLDC.
JSR #
30
139
36
Abreviatura
CLDC 1.0
CLDC 1.1
CDC
Explicación
Connected, Limited Device Configuration
Connected, Limited Device Configuration 1.1
Connected Device Configuration
Tabla 2.4: Configuraciones en Java ME
Los perfiles complementan una configuración añadiéndole APIs específicas para
proporcionar un entorno de ejecución para las aplicaciones en alguna categoría de
dispositivos específicos. Un perfil es un conjunto de APIs de alto nivel que además
define el modelo del ciclo de vida de la aplicación, el interfaz de usuario, persistencia de
almacenamiento y el acceso a las propiedades específicas del dispositivo.
Tal y como se ha presentado, Java ME tiene dos configuraciones básicas sobre las
que se construyen los perfiles. Mobile Information Device Profile [JSR-37] (MIDP 1.0),
está construido sobre CLDC, y fue el primer perfil de ejecución sobre Java ME. MIDP
2.0 [JSR-118] define un perfil que extiende y mejora MIDP 1.0.
Personal Profile [JSR-62] (PP), Personal Basis Profile [JSR-129] (PBP), y
Foundation Profile [JSR-FP] (FP) son tres perfiles de CDC. Estos tres perfiles junto con
MIDP 1.0 y MIDP 2.0 se muestran en la Tabla 2.5.
JSR #
37
118
46
129
62
Abreviatura
MIDP 1.0
MIDP 2.0
FP
PBP
PP
Explicación
Mobile Information Device Profile
Mobile Information Device Profile 2.0
Foundation Profile
Personal Basis Profile
Personal Profile
Tabla 2.5: Perfiles en Java ME.
3.4 APIs Opcionales
Debido a las características de los dispositivos algunas APIs son opcionales en la
plataforma J2ME. Los paquetes opcionales extienden la plataforma Java ME para añadir
funcionalidades a las que proporciona tecnología con la configuración (bien CLDC o
bien CDC) y a un perfil asociado.
Estas APIs opcionales se han creado para aplicaciones específicas y con tecnologías
emergentes, tales como conectividad a base de datos, mensajería inalámbrica,
multimedia, gráficos 3D, y Servicios Web.
Debido a su modularidad, los fabricantes de dispositivos pueden evitar llevar una
funcionalidad innecesaria o pesada incluyendo solo los paquetes que necesite. Algunos
de estos paquetes se muestran en la Tabla 2.6.
18
Contribución al análisis XML para la mejora en las prestaciones de memoria.
JSR #
75
82
120
135
164
165
172
177
179
180
184
190
Abreviatura
PIM
BTAPI
WMA
MMAPI
SATSA
Explicación
PDA Optional Packages for the J2ME Platform
Java APIs for Bluetooth
Wireless Messaging API
Mobile Media API
JAIN SIMPLE Presence
JAIN SIMPLE Instant Messaging
J2ME Web Services
Security and Trust Services API for J2ME
Location API for J2ME
SIP API for J2ME
Mobile 3D Graphics API for J2ME
Event Tracking API for J2ME
Tabla 2.6: Paquetes opcionales de Java ME.
3.5 JSR-185
JSR-185, Java Technology for the Wireless Industry, describe como las distintas JSRs
podrían trabajar juntas proporcionando una solución consistente para los dispositivos
inalámbricos.
J2ME es una tecnología inalámbrica surgida, no con la intención de desbancar a las
ya existentes, sino que puede ser utilizada para favorecerlas y mejorarlas. Por ejemplo,
utilizando código Java se pueden mejorar las prestaciones de los navegadores web
diseñados con otras tecnologías. Así, teléfonos móviles provistos de las tecnologías
WAP o i-Mode pueden potenciar sus posibilidades gracias a J2ME.
Puesto que CLDC es consciente de la gran cantidad de dispositivos existentes en el
mercado y de las grandes diferencias existentes entre estos, sólo se imponen
restricciones respecto de la capacidad de memoria. De esta forma, considerando que las
KVM, las librerías de configuración y de perfil, y las aplicaciones corriendo sobre el
dispositivo sólo deben ocupar entre 160 y 512 KB, se exigen al menos 128 KB de
memoria no volátil para la KVM y las librerías, y al menos 32 KB de memoria volátil
para la KVM en funcionamiento.
En lo que concierne al software, ocurre algo parecido. Debido a la gran diversidad
de software nativo que puede correr en el dispositivo, el CLDC sólo exige la existencia
de un software muy sencillo que cuente con una entidad de control de programas de
forma que pueda correr la KVM. No es necesario que de soporte ni tampoco que de
garantías de un buen funcionamiento en tiempo real.
Los requisitos exigidos por el MIDP son algo más estrictos, ya que éste debe tratar
con aspectos como la presentación en pantalla. Se exigen 128 KB de memoria no volátil
para componentes MIDP, 8 KB adicionales para almacenamiento de datos de aplicación
de forma persistente, y 32 KB de memoria volátil para KVM en ejecución. Los
requisitos en el display del equipo son de un tamaño de 96 x 54 mm , una profundidad
de 1 bit, y una relación de aspecto de 1:1. La interfaz de entrada debe de tener uno o más
2
Capítulo 2. Análisis de la información XML.
19
de los siguientes mecanismos: pantalla táctil y un teclado a una o dos manos. Por
ultimo, en lo relativo a la red, se pide una conexión bidireccional inalámbrica con un
ancho de banda limitado.
En lo concerniente al software, se exigen varios puntos: la existencia de un kernel
mínimo que controle al hardware y proporcione la entidad de control de programas
anteriormente mencionada, un mecanismo de lectura/escritura de memoria no volátil
para dar soporte a las APIs de almacenamiento de datos persistente, un mecanismo de
lectura/escritura para dar soporte a las APIs de red, un mecanismo que de soporte de
temporización, una capacidad mínima para escribir en la pantalla del dispositivo, y un
mecanismo para capturar la entrada de datos por parte del usuario.
Todos estos aspectos están en continua revisión y consideración bajo nuevas
especificaciones JSR. La nueva generación de dispositivos móviles puede necesitar
soporte XML para el procesamineto de documentos y servicios web. La especificación
JSR-280 [JSR-280] actualmente en desarrollo se está encargando de seleccionar el
subconjunto de DOM y SAX2 para realizar estas operaciones. Esta especificación
considera el análisis Pull una aproximación relativamente nueva y prometedora en este
campo.
4 Análisis de XML
4.1 Introducción
Los analizadores XML (ó parsers) son programas que extraen la información contenida
en un documento XML. Estos programas utilizan la representación del documento para
manipular la información que éstos contienen.
Un analizador XML puede tomar como entrada una cadena de caracteres en
secuencia y realiza ciertas operaciones sobre él. Esta cadena de caracteres en secuencia
se conoce como representación serializada del documento XML, y se forma a partir de
la fuente de datos de la que se extrajo la información XML. Esta fuente de datos puede
ser un fichero XML, un documento descargado mediante algún flujo de
comunicaciones, o una representación abstracta de la información XML en algún
lenguaje de programación, entre otros. Para la gestión de la información por parte del
analizador, y su posterior tratamiento y gestión por parte de la aplicación, el analizador
maneja una representación creada a partir de la fuente de datos virtual. El analizador
XML toma la información de entrada de la representación serializada XML y la
manipula para devolverla a la aplicación.
XML constituye la capa más baja dentro del nivel de aplicación, sobre el que se
puede desarrollar cualquier estructura de tratamiento de documentos, hasta llegar a la
20
Contribución al análisis XML para la mejora en las prestaciones de memoria.
presentación. Uno de los conceptos más relevantes de XML es la distinción entre
documentos XML validados y “bien formado” (well-formed).
Los documentos XML bien formados, son todos aquellos que cumplen las
especificaciones del lenguaje, como por ejemplo, el correcto entrelazado, naturaleza
jerárquica de los elementos que componen el archivo XML, nombrado de las etiquetas,
etc., aunque sin estar sujeto a los elementos fijados en un DTD (definición de los
elementos que puede haber en el documento XML). Muchos analizadores también
implementan validación utilizando una DTD, XML Schema, u otro método para
verificar que la estructura y contenido son como se especifican. En este caso, además de
estar bien formados, siguen una estructura y una semántica del documento determinada
reglas expresadas en algún lenguaje de modelado. Sus elementos, atributos, hijos como
subelementos estructurales, deben estar definidos por lenguaje de modelado. La
información analizada es devuelta a la aplicación mediante los métodos que proporciona
la interfaz de programación, API.
4.2 Modelos de análisis
La gestión de la información en un formato abierto permite el procesamiento por
cualquier programa (o por un programa creado expresamente para ello). Esto extiende la
aplicación y validez del programa, no solo en el momento en el que la información fue
creada, sino que basados en el principio de independencia de los datos, pueden
almacenarse en ordenadores no propietarios, con representaciones estandarizadas. XML
marca contenidos añadiendo información relacionada con el propósito de ésta. Con la
información almacenada en formato XML, una aplicación puede, mediante un
analizador, extraer la información relevante y procesarla adecuadamente para las
distintas situaciones. Los modelos de análisis representan formas diferentes de realizar
las operaciones de análisis de estos documentos. De esta forma se determina el
funcionamiento, que condicionará la implementación realizada, y las posibilidades que
puede ofrecer un determinado programa dicho proceso. Estos modelos son:
DOM,
Push y
Pull.
Cada uno tiene sus ventajas y desventajas. El siguiente documento XML,
libros.xml, describe un catálogo de libros y se usa como ejemplo para describir los
tres modelos. Este fichero se representa en la Figura 2.4. Los datos o información
aparecen en negrita. Los metadatos son los datos (o metadatos) que acompaña a los
datos, son las etiquetas que acompañan a la información.
<?xml version="1.0" ?>
<catalogo>
<!-- Ejemplo -->
<libro id="101">
Capítulo 2. Análisis de la información XML.
21
<titulo>The XML handbook</titulo>
<autor>C.F. Golfarb,P. Prescod</autor>
<precio>39.95</precio>
</libro>
<libro id="121">
<titulo>XSLT Programmer's Ref.</titulo>
<autor>M.Kay</autor>
<precio>19.95</precio>
</libro>
</catalogo>
Figura 2.4: Ejemplo de fichero xml.
Este documento puede representarse de forma gráfica, para mostrar su estructura y
contenido. En la Figura 2.5 se puede apreciar una estructura jerárquica, donde el "mayor
nivel" es catalogo, que se conoce como elemento raíz. catalogo tiene varios hijos,
dos elementos libro, y un comentario.
titulo: “The XML handbook”
libro
id:101
autor:“C.F. Golfarb,P. Prescod ”
precio: “39.95 ”
catalogo
titulo:“XSLT Programmers’s Ref.”
libro
autor: “M. Kay ”
id:121
precio: “19.95 ”
Comentario: Ejemplo
Figura 2.5: Representación gráfica de un documento XML.
En el mundo de la programación, una forma estándar de acceder a las operaciones
que ofrece un programa es mediante el uso de una interfaz (o punto de acceso), visible
por el programador (o programa usuario de la aplicación), de tal manera que esconda los
detalles de la implementación. De esta forma, las interfaces de programación de la
aplicación o APIs, mediante el uso de los métodos, operaciones o funciones,
proporcionan una forma estándar de ejecutar una aplicación. Y aunque deberían de ser
independientes de los detalles de la implementación suelen condicionar tanto la
implementación como la forma en la que los datos pueden ser devueltos.
Las interfaces de los tres modelos se presentan en las siguientes secciones. Primero
se presenta el Modelo de Objeto de un Documento (DOM), a continuación se presenta
el modelo de análisis Push, cuya única interfaz es Simple API for XML (SAX), y
posteriormente se presenta el modelo Pull.
22
Contribución al análisis XML para la mejora en las prestaciones de memoria.
4.3 Modelo de Objeto de un Documento: DOM
4.3.1 Introducción
DOM, utiliza una representación interna estándar de la estructura de un documento, y
proporciona una interfaz al programador para poder acceder de forma fácil, consistente y
homogénea a sus elementos, atributos y estilo. Es un modelo independiente de la
plataforma y del lenguaje de programación. El W3C establece varios niveles de
actuación, coincidiendo con el tiempo en que se presentan como recomendación:
Nivel 1: define una interfaz de programación para HTML y XML. Contiene
funcionalidades para la navegación y manipulación de documentos. Tiene 2
partes: el núcleo o parte básica, para documentos XML, y la parte HTML.
Nivel 2: incluye un modelo de objetos e interfaz de acceso a las
características de estilo del documento, definiendo funcionalidades para
manipular la información sobre el estilo del documento.
Nivel 3: Especifica interfaces a posibles sistemas de ventanas, manipulación
de DTD y modelos de seguridad.
El objetivo es que cualquier script pueda ejecutarse de forma más o menos
homogénea en cualquier navegador que soporte DOM. Es decir, tener una plataforma
estándar en la que poder crear contenidos sin temor a no estar soportado por alguna
marca o versión de navegador, y que además sea potente y versátil. Además, y al igual
que el conjunto de piezas que el W3C está creando para su uso en el intercambio de
documentos e información, no estará sujeto al ámbito de los navegadores, sino que su
uso será extensible a cualquier tipo de aplicación que acceda a esos documentos.
4.3.2 Diagrama UML
El Lenguaje de Modelado Unificado [UML] (UML - Unified Modeling Language) es un
lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que
comprende el desarrollo de software. Se ha convertido en el estándar de facto de la
industria, debido a que ha sido impulsado por los autores de los tres métodos más
usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos
autores fueron contratados por la empresa Rational Software Co. para crear una notación
unificada en la que basar la construcción de sus herramientas CASE.
La Figura 2.13 es una referencia rápida al diagrama UML que representa las
interfaces DOM a Nivel 2. En el que se representan las clases/interfaces y los métodos
de cada uno de ellos. Este tipo de diagramas proporcionan una panorámica de la
implementación mostrando las clases/interfaces y los métodos relevantes.
Capítulo 2. Análisis de la información XML.
<<interface>>
Document
<<interface>>
Attr
+getDocType()
+getImplementation()
+getDocumentElement()
+createElement()
+createDocumentFragment()
+createTextNode()
+createComment()
+createCDATASection()
+createProcessingInstruction()
+createAttribute()
+createEntityReference()
+getElementsByTagName()
+importNode()
+createElementNS()
+createAttributeNS()
+getElementsByTagNameNS()
+getElementById()
<<interface>>
Entity
+getPublicId()
+getSystemId()
+getNotationName()
<<interface>>
Notation
+getPublicId()
+getSystemId()
<<interface>>
DOMImplementation
+hasFeature()
+createDocumentType()
+createDocument()
<<interface>>
NamedNodeMap
<<interface>>
Element
<<interface>>
Node
<<interface>>
EntityReference
<<interface>>
ProcessingInstruction
+getTarget()
+getData()
+setData()
+getName()
+getSpecified()
+getValue()
+getOwnerElement()
<<interface>>
DocumentType
+getName()
+getEntities()
+getNotations()
+getNotations()
+getPublicId()
+getSystemId()
+getInternalSubset()
<<interface>>
DocumentFragment
+getNodeName()
+getNodeValue()
+setNodeValue()
+setNodeType()
+getParentNode()
+getChildNodes()
+getFirstChild()
+getLastChild()
+getPreviousSibling()
+getNextSibling()
+getAttributes()
+getOwnerDocument()
+insertBefore()
+replaceChild()
+removeChild()
+appendChild()
+hasChildNodes()
+cloneNode()
+normalize()
+isSupported()
+getNamespaceURI()
+getPrefix()
+setPrefix()
+getLocalName()
+hasAttributes()
http://www.w3.org/TR/DOM-Level-2-Core
+getTagName()
+getAttribute()
+setAttribute()
+removeAttribute()
+getAttributeNode()
+setAttributeNode()
+removeAttributeNode()
+getElementsByTagName()
+getAttributeNS()
+setAttributeNS()
+removeAttributeNS()
+getAttributeNodeNS()
+setAttributeNodeNS()
+getElementsByTagNameNS()
+hasAttribute()
+hasAttributeNS()
+getNamedItem()
+setNamedItem()
+removeNamedItem()
+item()
+getLength()
+getNamedItemNS()
+setNamedItemNS()
+removeNamedItemNS()
<<interface>>
CharacterData
+getData()
+setData()
+getLength()
+substringData()
+appendData()
+insetData()
+deleteData()
+replaceData()
23
<<interface>>
NodeList
+item()
+getLength()
<<interface>>
DOMException
<<interface>>
CDATASection
<<interface>>
Comment
<<interface>>
Text
+splitText()
Figura 2.6: Jerarquía de Interfaces del Nivel 2 de DOM.
El nombre "Document Object Model" fue elegido ya que es un "modelo de objeto"
en el tradicional diseño orientado a objeto. Los documentos son modelados usando
objetos, y el modelo comprende no solo la estructura de un documento, pero también las
propiedades de un documento y los objetos de los que está compuesto. En otras
palabras, los nodos en el diagrama de arriba no representan una estructura de datos, sino
que representan objetos, en los que se tienen funciones e identidades. A modo de
ejemplo se presenta la interfaz Node: En la siguiente figura se observa tanto las
variables estáticas como los métodos con los parámetros y valores devueltos en código
Java. El resto de interfaces están detalladas tanto en Java, IDL [OMGIDL], como
ECMAScript [ECMAScript], en las páginas del W3C[DOM Level 2].
package org.w3c.dom;
public interface Node {
public static final short ELEMENT_NODE
= 1;
public static final short ATTRIBUTE_NODE
= 2;
public static final short TEXT_NODE
= 3;
public static final short CDATA_SECTION_NODE
= 4;
public static final short ENTITY_REFERENCE_NODE
= 5;
public static final short ENTITY_NODE
= 6;
public static final short PROCESSING_INSTRUCTION_NODE = 7;
public static final short COMMENT_NODE
= 8;
public static final short DOCUMENT_NODE
= 9;
public static final short DOCUMENT_TYPE_NODE
= 10;
public static final short DOCUMENT_FRAGMENT_NODE
= 11;
public static final short NOTATION_NODE
= 12;
public String getNodeName();
public String getNodeValue() throws DOMException;
public void setNodeValue(String nodeValue) throws DOMException;
public short getNodeType();
24
Contribución al análisis XML para la mejora en las prestaciones de memoria.
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
Node getParentNode();
NodeList getChildNodes();
Node getFirstChild();
Node getLastChild();
Node getPreviousSibling();
Node getNextSibling();
NamedNodeMap getAttributes();
Document getOwnerDocument();
Node insertBefore(Node newChild, Node refChild)
throws DOMException;
Node replaceChild(Node newChild, Node oldChild)
throws DOMException;
Node removeChild(Node oldChild) throws DOMException;
Node appendChild(Node newChild) throws DOMException;
boolean hasChildNodes();
Node cloneNode(boolean deep);
void normalize();
boolean isSupported(String feature, String version);
String getNamespaceURI();
String getPrefix();
void setPrefix(String prefix) throws DOMException;
String getLocalName();
boolean hasAttributes();
}
Figura 2.7: Interfaz Node.
DOM proporciona un API que permite acceso aleatorio y manipulación de un
documento XML en memoria. En primer lugar esto parece como una ventaja para el
desarrollador. Aunque esta perceptible simplicidad se convierte en un alto coste: el
funcionamiento. Para un documento grande podría necesitarse leer el documento en
memoria antes de tomar acciones apropiadas basadas en los datos. Mediante la
construcción de un árbol DOM el árbol puede llegar a multiplicar el consumo de
memoria del propio XML, e incurre en una cantidad nada trivial para el coste de
procesamiento, haciendo que DOM no sea deseable en algunas situaciones. Esta es una
tendencia “natural” en el modelo DOM, aunque podría ser tendente también en
cualquier otra implementación basada en eventos.
4.3.3 Ejemplo con DOM
DOM es una técnica de análisis basada en árboles que construye el árbol entero en
memoria. Esto permite tener un acceso a todo el documento de forma cómoda e
intuitiva. La Figura 2.8 muestra la estructura en forma de árbol del modelo de análisis
DOM. Document es la raíz que tiene al menos un nodo hijo, el elemento raíz, el cual
es el elemento catalogo en el código de ejemplo. Otro nodo es DocumentType, para
la declaración de la DTD, la cual no está definida en nuestro ejemplo. Elemento
catalogo tiene nodos hijos. Los nodos hijos pueden tener elementos, texto, comentarios,
instrucciones de procesamiento, tal y como se muestra en el ejemplo.
Capítulo 2. Análisis de la información XML.
25
Document
DocumentType
null
Element
catalogo
Element
libro
Element
libro
Attr
“121”
Text
“”
Element
titulo
Element
titulo
Element
autor
Element
precio
Text
Text
Text
“XSLT Programmers’s Ref.”
Attr
“101”
Comments
“Ejemplo”
“19.95 ”
“M. Kay ”
Element
autor
Text
Text
“The XML handbook”
“C.F. Golfarb,P. Prescod ”
Element
precio
Text
“39.95 ”
Figura 2.8: Representación gráfica de un árbol DOM.
En la Figura 2.9 ilustra como es el funcionamiento de la API DOM. Este ejemplo
imprime en la salida los títulos de los libros obtenidos del documento XML.
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document document = builder.parse("libros.xml");
NodeList nodes = document.getElementsByTagName("titulo");
for(int i = 0; i < nodes.getLength(); i ++) {
Element titleElem = (Element)nodes.item(i);
Node childNode = titleElem.getFirstChild();
if (childNode instanceof Text) {
System.out.println("El titulo del libro es: "
+ childNode.getNodeValue());
}
}
Figura 2.9: Funcionamiento de la API DOM.
La salida del documento es:
El titulo del libro es: The XML handbook
El titulo del libro es: XSLT Programmer's Referente
Este programa toma un fichero XML, crea un árbol DOM, y encuentra todos los
nodos de los elementos que contienen como etiqueta el valor especificado por el método
getElementsByTagName("titulo"). Finalmente imprime el texto de la
información asociada con los elementos antes obtenidos, iterando sobre la lista de los
títulos de los elementos y examinando el primer hijo que contiene el texto contenido
entre el comienzo y el final de la marca del elemento, mediante el método
getFirstChild().
26
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Se puede acceder a todos los elementos del documento. Esta API permite la
manipulación del árbol, añadiendo y eliminando elementos.
Aunque la estructura en forma de árbol proporciona un buen soporte para manipular
el documento hay ciertos aspectos a considerar
El documento XML tiene que ser analizado entero al menos una vez, el
análisis parcial no es posible.
Cargar todo el documento y construir una estructura en forma de árbol
puede ocupar mucha memoria, especialmente cuando el documento es
grande. El árbol DOM tiene un orden de magnitud de la memoria utilizada
mayor que el tamaño del documento, por lo tanto consume bastante
memoria.
El tipo genérico del nodo DOM es una ventaja de cara a la interoperabilidad,
pero podría no ser la mejor opción cuando se quiere tener un tipo de objeto
más específico.
El análisis con DOM es apropiado cuando la aplicación necesita tener acceso
aleatorio a todo el documento. Un buen ejemplo es cuando se realiza operaciones de
transformación del documento, como con XSL, ya que el analizador necesita navegar a
través del documento, también es apropiado para aplicaciones, tales como editores
XML, que necesitan modificar los datos.
4.3.4 Modelo Productor/Consumidor en DOM
Según la relación entre el analizador y la aplicación se pueden comparar los distintos
modelos de análisis de la información XML. Un analizador es el encargado de extraer la
información de un documento XML, y entregarla a la aplicación. El tipo de relación
entre ambos (analizador y cliente) puede ser diferente para los distintos modelos.
Una aplicación actúa como cliente en relación con el analizador, recibiendo la
información que el analizador le proporciona a través las interfaces de los métodos de
las interfaces de programación. Pero esta interacción puede responder bajo petición del
cliente o bien puede hacer frente al funcionamiento del analizador.
Por tanto, en la configuración de todos los componentes, hay una serie de roles para
proporcionar la funcionalidad de una aplicación.
El primer rol es el productor de eventos, que es normalmente un analizador
XML, obtenido como una instancia de alguna clase de una librería.
El segundo rol es el consumidor que en el caso de ser una analizador XML
basado en eventos los captura y procesa si corresponde, y en el caso de un
analizador XML basado en árboles accede a la representación en memoria
de documento XML.
Capítulo 2. Análisis de la información XML.
27
Un analizador DOM devuelve una representación en forma de árbol de un
documento XML. Un analizador Push llama a los métodos del cliente con eventos
XML. Un analizador Pull devuelve los eventos XML al cliente bajo petición. Tal y
como se detalla en las figuras de los siguientes apartados. Los analizadores DOM
devuelven una representación en forma de árbol del documento XML, y la aplicación
puede acceder a la información XML. En la Figura 2.10 se muestra la aplicación en su
roll de consumidor de los datos XML que los obtiene de la representación en forma de
árbol que contruye el analizador XML de la fuente de datos. Se puede observar que
desde la aplicación se accede directamente a una representación que se ha hecho de los
datos para su tratamiento.
Árbol DOM
nodo Document
analizador
datos
XML
Node Raíz
Node hijo
Texto
lectura/escritura
aplicación
Node hijo
Texto
Figura 2.10: Modelo Productor/consumidor en DOM.
Pero DOM no puede usarse para leer el documento XML. Para eso se usa el modelo
Push (SAX), de esta forma pueden trabajar de forma conjunta. El modelo Push se
expone en el siguiente apartado.
4.4 Análisis con Push
4.4.1 Introducción
Simple API for XML (SAX) es la API del modelo Push para el procesamiento XML. No
es un estándar W3C, sino que es fruto de la discusión de una lista de distribución XMLDEV que desarrollo SAX 1.0 [SAX]. SAX no construye la representación en forma de
árbol del documento como lo hace DOM, sino que entrega una serie de eventos según
los datos obtenidos del documento. Estos eventos se entregan a unos manipuladores,
que proporcionan acceso al contenido del documento. Hay tres tipos básicos de
manipuladores de eventos:
DTDHandler, para acceder al contenido de las DTDs. Toma los eventos
que se producen cuando la DTD es analizada.
ErrorHandler, para analizar errores de bajo nivel. Cuando el analizador
encuentra un error, este llama a este manejador, que en algunos casos la
aplicación puede ignorar el error y continuar. Otras veces el error hace lo
28
Contribución al análisis XML para la mejora en las prestaciones de memoria.
posible para que el analizador continúe, en este caso la aplicación debería
dar información sobre el error.
ContentHandler, para acceder al contenido del documento. Con este
manejador la aplicación desarrollada pone el código que procesa los datos.
La Figura 2.11 muestra como el analizador SAX obtiene los eventos. El analizador
lee la entrada del documento, coloca cada evento y lo entrega a MiManejador,
mientras procesa el documento. La lectura de los datos no se realiza bajo petición de la
aplicación que utiliza el analizador de tipo Push. Por el contrario, los eventos son
entregados por el analizador a la aplicación y la aplicación podrá obtener la información
del documento XML sobreescritura de los métodos, en función del evento generado en
el proceso de lectura.
MiManejador
Analizador
SAX
libros.xml
startElement “titulo”
characters
endElement “titulo”
Lee datos directamente
isTitle = true
Imprime el título
isTitle = false
Coloca los eventos
Figura 2.11: SAX entrega un documento a una aplicación como una secuencia de eventos.
La construcción de un árbol DOM requiere leer el documento XML entero y
posicionar los objetos en memoria. Pero DOM no puede usarse para leer el documento
XML. Para eso se puede usar el modelo Push (SAX), de esta forma pueden trabajar de
forma conjunta. La Figura 2.12 muestra como las librerías Java de Sun implementan el
Modelo de Objeto del documento.
Document
Handler
Error
Analizador
SAX
Handler
DOM
Object
DTD Event
Handler
Entity
Object
Object
Object
Object
Resolver
Figura 2.12: SAX entrega un documento a una aplicación como una secuencia de eventos.
Capítulo 2. Análisis de la información XML.
29
En esta figura aparece EntityResolver que es invocado cuando el analizado
podría acceder a texto que está fuera de la entidad del documento.
4.4.2 Diagrama UML para SAX
Push es un modelo de análisis de documentos XML cuya única instanciación es SAX
(Simple API for XML). La Figura 2.13 muestra un diagrama con las interfaces de SAX
2.0. ContentHandler contiene los métodos para extraer la información de los eventos
producidos en el análisis. Locator y Attributes contiene solamente métodos que
permiten obtener información del análisis (“getter”). XMLReader y InputSource
contienen métodos “setter” para la configuración en el análisis.
<<interface>>
ContentHandler
<<interface>>
DTDHandler
+startDocument()
+endDocument()
+startPrefixMapping()
+endPrefixMapping()
+startElement()
+endElement()
+characters()
+ignorableWhitespace()
+processingInstruction()
+skippedEntity()
+setDocumentLocator()
<<interface>>
Locator
+getSystemId()
+getPublicId()
+getLineNumber()
+getColumnNumber()
+notationDecl()
+unparsedEntityDecl()
+notationDecl()
+unparsedEntityDecl()
<<interface>>
XMLReader
<<interface>>
Attributes
+getValue()
+getURI()
+getLocalName()
+getRawName()
+getType()
+getLength()
SAX 2.0
<<interface>>
LexicalHandler
+getProperty()
+getFeature()
+getContentHandler()
+getEntityresover()
+getErrorHandler()
+getDTDHandler()
+setProperty()
+setFeature()
+setContentHandler()
+setEntityresover()
+setErrorHandler()
+setDTDHandler()
+parse()
<<interface>>
XMLFilter
+getParent()
+setParent()
<<interface>>
DeclHandler
+elementDecl()
+attributeDecl()
+internalEntityDecl()
+externalEntityDecl()
<<interface>>
ErrorHandler
+warning()
+error()
+fatalError()
<<interface>>
EntityResolver
+resolveEntity()
InputSource
+getSystemId()
+getPublicId()
+getInputStream()
+getCharacterStream()
+setSystemId()
+setPublicId()
+setInputStream()
+setCharacterStream()
Figura 2.13: Interfaces de SAX 2.0.
La API SAX 2.0 se puede descargar de forma gratuita [APISAX20]. La Figura 2.14
muestra la interfaz ContentHandler el programador sobrescribe estos métodos para
obtener la información generada por los eventos. Los datos se proporcionan a través de
los parámetros formales de los métodos de la interfaz.
package org.xml.sax;
public interface ContentHandler{
public void setDocumentLocator (Locator locator);
public void startDocument () throws SAXException;
public void endDocument() throws SAXException;
public void startPrefixMapping (String prefix, String uri)
throws SAXException;
public void endPrefixMapping (String prefix) throws SAXException;
public void startElement (String uri, String localName,
String qName, Attributes atts) throws SAXException;
Contribución al análisis XML para la mejora en las prestaciones de memoria.
30
public void endElement (String uri, String localName,
String qName)throws SAXException;
public void characters (char ch[], int start, int length)
throws SAXException;
public void ignorableWhitespace (char ch[], int start,
int length)throws SAXException;
public void processingInstruction (String target,
String data)throws SAXException;
public void skippedEntity (String name) throws SAXException;
}
Figura 2.14: Interfaz ContentHandler.
Los analizadores Push (SAX) se pueden utilizar para construir el árbol DOM.
Mediante la obtención de la información generada por eventos en el proceso de lectura
con un analizador de tipo Push, se puede utilizan para construir el árbol DOM, de forma
que se pueda manipular fácilmente el documento.
4.4.3 Ejemplo con Push
En este apartado se presenta un ejemplo del modelo Push. El siguiente ejemplo realiza
la misma operación que en el ejemplo previo con DOM: imprime la información del
título el libro.
Primero, se escribe una clase que implementa ContentHandler, que reemplaza
los métodos para los tipos de eventos en los cuales se está interesado. En este ejemplo se
deja de lado el resto de eventos. La particularización de la clase ContentHandler,
proporciona los métodos para la gestión de los estados permitiendo eventos de
comienzo del elemento, fin de elemento, caracteres del evento. La operación es válida
para todos los elementos, no sólo para el elemento titulo.
public class MiManejadorDeConenido extends DefaultHandler {
boolean isTitle;
public void startElement(String uri, String localName,
String qName, Attributes atts) {
if (qName.equals("titulo"))
isTitle = true;
}
public void endElement(String uri, String localName,
String qName) {
if(qName.equals("titulo"))
isTitle = false;
}
public void characters(char[ ] chars, int start, int length) {
if(isTitle){
System.out.println("El titulo del libro es: "
+ new String(chars, start, length));
}
}
}
Figura 2.15: Funcionamiento de la API SAX.
Segundo, se configura el ContentHandler para el analizador SAX, y luego el
analizador comienza a procesar el documento XML. El analizador genera eventos y los
Capítulo 2. Análisis de la información XML.
31
coloca en el ContentHandler, mientras se lee el documento desde el comienzo hasta
el final.
public static void main(String args[]){
SAXParser parser = null;
DefaultHandler handler = new MiManejadorDeConenido();
SAXParserFactory factory = SAXParserFactory.newInstance();
try{
parser = factory.newSAXParser();
parser.parse(new FileInputStream("libros.xml"),handler);
}catch(Throwable e){
System.out.println("Error: "+e);
}
}
Figura 2.16: Configuración de la API SAX.
Comparado con DOM, el analizador SAX ofrece un mejor comportamiento en
memoria. Proporcionando un acceso al contenido del documento XML de bajo nivel. El
modelo Push tiene presenta un mejor comportamiento en memoria, ya que no necesita
cargar el documento entero en memoria, esto hace que sea más apropiado para
documentos grandes. Además, no se necesita crear objetos para todos los nodos, como
lo hace el modelo DOM. El modelo Push puede usarse en un amplio contexto, donde
varios manipuladores (ContentHandler) pueden registrarse y recibir eventos en
paralelo.
La desventaja de SAX es que tiene que implementar los manipuladores de eventos
para manejar todos los eventos entrantes. Se deben mantener el estado de los eventos en
el código de la aplicación. Ya que el analizador SAX no comunica metainformación
como lo hace DOM que soporta relaciones padre/hijo, haciendo más complejo mantener
el documento en la parte de la aplicación. Por tanto, siempre que no se necesite
mantener el documento entero, un analizador SAX puede ser una buena solución.
Una de las grandes desventajas de SAX es que no se puede navegar en el
documento. Por lo que no da soporte al lenguaje de caminos, XPath, que determinar la
ruta para extraer elementos del documento. Esta limitación también se muestra en los
“espacios de nombres”. Por lo que es una pobre elección para la manipulación o
modificación de un documento.
Las aplicaciones que necesiten sólo leer el contenido de un documento pueden
verse beneficiadas con el análisis SAX. Tal es el caso de las aplicaciones Business-toBusiness (B2B) y en las plataformas de aplicaciones integradas (EAI) que usan XML
como formato que encapsula, en el cual el receptor final simplemente recupera los
datos. SAX 2.0 tiene un mecanismo para construir filtrado que hace más fácil la salida
de un subconjunto del documento o hace simplemente una transformación simple del
documento.
32
Contribución al análisis XML para la mejora en las prestaciones de memoria.
4.4.4 Modelo Productor/Consumidor en Push
En este apartado se presenta gráficamente los componentes del modelo Push. La Figura
2.17 muestra el modelo Productor y Consumidor del modelo Push. En el dibujo se
observa como los datos son entregados directamente desde la fuente a la aplicación
como consumidor de ellos, a través de unos métodos, que proporciona la API SAX. Los
métodos deben ser sobreescritos por la aplicación para su manipulación.
El primer papel es un productor de eventos, el cual es el analizador XML. El
productor transforma en eventos la información leída del documento XML, para
proporcionarlos al consumidor. El productor “carga” los eventos en objetos para
servirlos al segundo componente, el consumidor de los datos XML.
Productor
Consumidor
void startDocument ()
void endDocument ()
void characters(char buf [], int offset, int len)
void endElement (String uri, String lNam, String qName) aplicación
void startElement(String uri, String localNam,
String qName, Attributes attrs)
analizador
datos
XML
Figura 2.17: Modelo Productor/consumidor en Push.
En vez de construir la representación en forma de árbol de la información XML, el
modelo Push convierte en eventos la información leída del documento XML. En este
modelo Push el patrón de comunicación típica es exclusivamente desde el productor al
consumidor.
La mayoría de aplicaciones que utilizan la implementación del modelo Push, SAX,
sólo tienen un productor de eventos aunque pueden tener más de uno. SAX es un
sistema conducido por eventos donde el analizador notifica a la aplicación cada vez y
analiza una sección de un documento XML. Estos eventos de bajo nivel se usan por la
aplicación para construir su representación en memoria del documento XML. Estos
métodos no permiten a una aplicación preguntar por el siguiente evento, el
funcionamiento del modelo Pull permite tratar los eventos bajo petición tal y como se
muestra en el siguiente apartado.
4.5 Análisis con Pull
4.5.1 Introducción
Pull es una nueva técnica de análisis, que al igual Push, es un modelo guiado por
eventos. Aunque, en vez de usar el mecanismo de SAX con el uso de los manipuladores
de eventos y sobreescritura de métodos, el modelo Pull devuelve eventos a medida que
la aplicación los solicita. Sus APIs pueden ser bidireccionales, dando la posibilidad de
Capítulo 2. Análisis de la información XML.
33
leer un documento XML y de poder generarlo. Las primeras implementaciones del tippo
Pull surgieron como envolvente de los eventos de tipo Push para construir eventos al
estilo Pull. Push realiza un análisis sin estado, son eventos de bajo nivel y muy
eficientes en memoria, pero son eventos sin estado. Pull proporciona un análisis
dependiente del estado. En algunas implementaciones se suele construir el árbol DOM y
posteriormente se construyen bucles al estilo iterador para recoger la información.
Mientras SAX devuelve diferentes tipos de eventos al ContentHandler, Pull
devuelve el evento a la aplicación pudiéndolo proporcionarlo como objeto.
La Figura 2.18 muestra que cuando una aplicación pide un evento, un analizador
Pull lee bajo demanda del documento XML y devuelve el evento a la aplicación. La
generación de eventos se produce de forma secuencial desde el comienzo del documento
hasta el final, con movimiento del cursor siempre hacia delante.
Analizador
Aplicación
Pull
libros.xml
START_ELEMENT “titulo”
CHARACTERS
END_ELEMENT “titulo”
Lectura bajo petición
next()
next()Imprime titulo
next()
Pide el evento
Figura 2.18: Funcionamiento del modelo Pull.
4.5.2 Diagrama UML para Pull
Un tercer modelo empleado para analizar documentos XML es Pull. Inicialmente este
modelo no presentaba ninguna API para su implementación. En la actualidad existe una
que puede encontrarse en [XPP], y otras implementaciones como StAX anteriormente
presentadas. Esta API al igual que el modelo Push está basada en eventos. En la Figura
2.19 se representa el diagrama UML de clases para la implementación JSR-173 [JSR173].
34
Contribución al análisis XML para la mejora en las prestaciones de memoria.
XMLStreamReader
XMLStreamWriter
QName
+close()
+flush()
+getNamespaceContext()
+getPrefix()
+getProperty()
+setDefaultNamespace()
+setNamespaceContext()
+setPrefix()
+writeAttribute()
+writeCData()
+writeCharacters()
+writeComment()
+writeDefaultNamespace()
+writeDTD()
+writeEmptyElement()
+writeEmptyElement()
+writeEndDocument()
+writeEndElement()
+writeEntityRef()
+writeNamespace()
+writeProcessingInstruction()
+writeProcessingInstruction()
+writeStartDocument()
+writeStartElement()
+writeStartElement()
+writeStartElement()
+getNamespaceURI()
+getLocalPart()
+getPrefix()
<<interface>>
NamespaceContext
+getNamespaceURI()
+getPrefix ()
+getPrefixes()
<<interface>>
XMLConstants
<<interface>>
XMLStreamConstants
<<interface>>
XMLStreamException
<<interface>>
Location
+getCharacterOffset()
+getColumnNumber()
+getLineNumber()
+getLocationURI()
+close()
+getAttributeCount()
+getAttributeLocalName()
+getAttributeName()
+getAttributeNamespace()
+getAttributePrefix()
+getAttributeType()
+getAttributeValue()
+getAttributeValue()
+getCharacterEncodingScheme()
+getElementText()
+getEncoding()
+getEventType()
+getLocalName()
+getLocation()
+getName()
+getNamespaceContext()
+getNamespaceCount()
+getNamespacePrefix()
+getNamespaceURI()
+getNamespaceURI()
+getNamespaceURI()
+getPIData()
+getPITarget()
+getProperty()
+getText()
+getTextCharacters()
+getTextCharacters()
+getTextLength()
+getTextStart()
+getVersion()
+hasName()
+hasNext()
+hasText()
+isAttributeSpecified()
+isCharacters()
+isEndElement()
+isStandalone()
+isStartElement()
+isWhiteSpace()
+next()
+nextTag()
+require()
+standaloneSet()
Figura 2.19: Pull (API para StAX).
Una implementación del modelo Pull es Streaming API for XML (StAX) [JSR173]. StAX da el control del análisis al programador mediante una API basada en un
simple iterador y un flujo de eventos subyacente. La Figura 2.20 se presentan los
métodos de la interfaz XMLStreamReader, con los métodos next() y hasNext(),
que permite recorrer todo el documento solicitando los eventos. Se puede observar
como se importa la interfaz QName, que soporta los nombres cualificados según se
especifica la norma [Bray 99].
package javax.xml.stream;
import java.io.Reader;
import javax.xml.namespace.NamespaceContext;
import javax.xml.namespace.QName;
public interface XMLStreamReader extends XMLStreamConstants {
public Object getProperty(java.lang.String name)
throws java.lang.IllegalArgumentException;
public int next() throws XMLStreamException;
public void require(int type, String namespaceURI,
String localName) throws XMLStreamException;
public String getElementText() throws XMLStreamException;
public int nextTag() throws XMLStreamException;
public boolean hasNext() throws XMLStreamException;
public void close() throws XMLStreamException;
public String getNamespaceURI(String prefix);
public boolean isStartElement();
public boolean isEndElement();
public boolean isCharacters();
Capítulo 2. Análisis de la información XML.
35
public boolean isWhiteSpace();
public String getAttributeValue(String namespaceURI, String
localName);
public int getAttributeCount();
public QName getAttributeName(int index);
public String getAttributeNamespace(int index);
public String getAttributeLocalName(int index);
public String getAttributePrefix(int index);
public String getAttributeType(int index);
public String getAttributeValue(int index);
public boolean isAttributeSpecified(int index);
public int getNamespaceCount();
public String getNamespacePrefix(int index);
public String getNamespaceURI(int index);
public NamespaceContext getNamespaceContext();
public int getEventType();
public String getText();
public char[] getTextCharacters();
public int getTextCharacters(int sourceStart, char[] target,
int targetStart, int length) throws XMLStreamException;
public int getTextStart();
public int getTextLength();
public String getEncoding();
public boolean hasText();
public Location getLocation();
public QName getName();
public String getLocalName();
public boolean hasName();
public String getNamespaceURI();
public String getPrefix();
public String getVersion();
public boolean isStandalone();
public boolean standaloneSet();
public String getCharacterEncodingScheme();
public String getPITarget();
public String getPIData();
}
Figura 2.20: Interfaz XMLStreamReader.
4.5.3 Ejemplos con Pull
Los métodos next() y hasNext() permiten a la aplicación desarrollar y preguntar
por el siguiente evento (Pull) en lugar de hacer frente a los eventos producidos mediante
en la forma en la que lo hace el modelo Push. Esto proporciona a un desarrollador un
mayor control del proceso de análisis del documento XML. StAX permite al
programador parar el procesamiento del documento, ir paso a paso, pasar de largo
algunas secciones del documento, y obtener subsecciones del documento.
Pull incluye la posibilidad de realizar la operación de lectura y escritura, de esta
forma las aplicaciones pueden usar las interfaces Pull sin tener en cuenta los detalles de
una implementación en particular.
A diferencia de DOM y Push, Pull especifica dos modelos de análisis. El modelo
cursor, que al igual que el modelo Push, simplemente devuelve eventos. El modelo
Contribución al análisis XML para la mejora en las prestaciones de memoria.
36
iterador devuelve eventos como objetos, lo cual proporciona una interfaz del tipo
procedimiento.
La Figura 2.21 presenta el análisis con la API StAX para los dos modelos.
XMLInputFactory factory = XMLInputFactory.newInstance();
Reader reader =
new InputStreamReader(new FileInputStream("libros.xml"));
XMLEventReader r = factory.createXMLEventReader( reader );
boolean isTitle = false;
while(r.hasNext()) {
XMLEvent e = r.next();
if(e.isStartElement() &&
((((StartElement)e).getName())
.getLocalPart()).equals("titulo")){
isTitle = true;
}else if(e.isCharacters() && isTitle){
System.out.println(""+((Characters)e).getData());
}else if(e.isEndElement() &&
((((EndElement)e).getName())
.getLocalPart()).equals("titulo")){
isTitle = false;
}
}
Figura 2.21: Funcionamiento del modelo Pull al estilo iterador.
En este ejemplo, la aplicación pide el siguiente evento, el cual hace que el
analizador StAX avance hacia el siguiente evento en la posición y devuelva el
correspondiente objeto asociado al evento. La aplicación puede acceder al contenido del
elemento mediante el método getData(), que devuelve la información del título del
libro.
El siguiente ejemplo imprime la información del título del libro usando el modelo
cursor.
XMLInputFactory factory = XMLInputFactory.newInstance();
Reader reader = new InputStreamReader(
new FileInputStream("libros.xml"));
XMLStreamReader r =
factory.createXMLStreamReader( reader );
boolean isTitle = false;
while(r.hasNext()) {
int evento = r.next();
switch(evento){
case XMLStreamConstants.START_ELEMENT:
if((r.getLocalName()).equals("titulo"))
isTitle = true;
break;
case XMLStreamConstants.CHARACTERS:
if(isTitle)
System.out.println(r.getText());
break;
case XMLStreamConstants.END_ELEMENT:
if((r.getLocalName()).equals("titulo"))
isTitle = false;
break;
}
}
Figura 2.22: Funcionamiento del modelo Pull siguiendo el modelo cursor.
Capítulo 2. Análisis de la información XML.
37
En este ejemplo, la aplicación pregunta el siguiente evento, usando la llamada al
método r.next(). Esto hace que el analizador StAX mueva el cursor hacia la
posición del siguiente evento. Si este evento indica el comienzo del elemento “titulo”, el
código de la aplicación llamará a r.next() una vez más, para avanzar el cursor, y
obtendrá entonces el texto para el elemento, usando el método r.getText().
El modelo de funcionamiento al estilo cursor de StAX se puede comparar al análisis
SAX. Aunque con StAX, la aplicación tiene el control del análisis, lo cual hace el
código más fácil de escribir y mantener. StAX también proporciona el modelo iterador
para fácil uso, pero en este caso, creando objetos para los eventos que tiene un coste en
cuanto al funcionamiento. A diferencia de SAX, que necesita que la aplicación
mantenga el estado de donde está el documento, StAX en función de su funcionamiento
de generar eventos bajo petición, libera a la aplicación de esta tarea.
En comparación con DOM, StAX tiene la misma desventaja que SAX en términos
de soporte para la navegación por todo el documento. La navegación hacia atrás del
documento no es posible, es decir, se accede a la información del documento
secuencialmente desde el comienzo hasta el final con demanda de eventos bajo petición
por parte de la aplicación. Aunque pueda parecer que StAX proporciona las mismas
prestaciones que SAX para modificar el documento, StAX es una API bidireccional con
capacidad de escritura de un documento XML.
4.5.4 Modelo Productor y Consumidor en Pull
En este apartado se presenta gráficamente los componentes del modelo Pull. La Figura
2.22 se muestra el modelo Productor y Consumidor del modelo Pull. En el dibujo se
observa como los datos son entregados directamente desde la fuente a la aplicación
como consumidor de ellos, bajo petición.
El consumidor de datos XML debe pedirlos al productor para obtener la
información. Las peticiones desde el consumidor al productor se realizan con el método
"next()". Este devuelve información relacionada con el siguiente evento. El productor
transforma en eventos la información leída del documento XML, para proporcionarlos
al consumidor. En la implementación del modelo Pull, StAX, esta información puede
ser un objeto de la clase XMLEvent, tal y como se especifica en el modelo iterador, o
bien un valor entero, de la interfax XMLStreamConstants, del modelo cursor, tal y
como se presentó con los ejemplos de apartados anteriores.
38
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Productor
Consumidor
boolean hasNext ()
true
int next()
START_DOCUMENT / START_ELEMENT, ...
analizador
aplicación
datos
XML
Figura 2.23: Modelo Productor/consumidor en Pull.
A diferencia del modelo Push, la aplicación para la manipulación de los datos XML
no tiene que sobreescribir los métodos. Y a diferencia del modelo DOM no construye
una representación en forma de jerárquica del documento.
El modelo Pull usa dos métodos de los objetos de un iterador next() y
hasNext(), para manipular los datos XML, como los iteradores de Java. Un iterador
es un objeto que puede moverse a lo largo de una secuencia de objetos y selecciona cada
uno de la secuencia.
El modelo Iterador debería tener un peor funcionamiento en memoria que el modelo
cursor, ya que de forma necesaria construye un objeto para cada evento que se genera
por parte del productor de eventos. El modelo Pull permite al programador parar el
procesamiento del documento, ir paso a paso por secciones del documento, y obtener
secciones del documento.
5 Selección del modelo de análisis
5.1 Introducción
En este apartado se hace una valoración de los tres modelos de análisis de los
documentos XML, separándolo en tres apartados, consideraciones a favor o pros,
consideraciones en contra o contras, y situación en la que es mejor utilizarlo. Estos
puntos se discuten a continuación.
5.2 Pros
Las tres técnicas de análisis de los documentos XML tienen puntos a favor de cara a su
uso. Este apartado presenta los aspectos positivos que presentan las distintas técnicas de
manipulación de los documentos XML. Estos se presentan de forma esquemática en la
Tabla 2.7.
El modelo DOM presenta una interfaz de fácil uso para un programador, con una
amplio y rico conjunto de posibilidades. La estructura jerárquica de los documentos
XML (con un único nodo raíz, e hijos apartir de este elemento) hacen que sea una forma
Capítulo 2. Análisis de la información XML.
39
natural manejar toda la información siguiendo la estructura que el documento tiene. La
manipulación del documento siguiendo una estructura cercana a la del documento XML
es sencilla, fácil e intuitiva.
Los modelos basados en eventos, tiene un buen comportamiento en memoria. Estos
entregan los eventos producidos en el proceso de análisis directamente a la aplicación.
Por ello se pueden filtrar operaciones, filtrar los eventos que proceden del analizador.
DOM
Push
Pull
Carga el árbol entero en Buen comportamiento en La aplicación controla el
memoria.
memoria (a priori).
análisis.
Gran conjunto de APIs
Permite el registro de Capacidades de filtrado
múltiples manipuladores
Fácil navegación y uso
Eficiente recuperación de
datos
Tabla 2.7: Pros de los modelos de análisis.
Por tanto, los modelos basados en eventos (Push y Pull) presentan una mayor
simplicidad y eficiencia de con su capacidad de filtrado pudiendose realiar operaciones
de filtrado los eventos producidos; donde los eventos del modelo Pull son bajo petición.
Mientras que DOM es un modelo que manipula la información en forma de objetos,
construyéndolos a partir de los datos XML para una manipulación rápida y un acceso
directo después de construir la estructura jerárquica.
5.2 Contras
DOM proporciona APIs a los programadores para la manipulación en forma de árbol. La
primera impresión parece una ventaja para el desarrollador ya que no requiere escribir
código para analizar. Pero esta simplicidad tiene un coste: el funcionamiento. Algunas
implementaciones necesitan el documento en memoria, de esta forma para documentos
grandes debería leer todo el documento antes de realizar ninguna acción.
Otra desventaja de DOM es que el programador debería usar el árbol como base par
el manejo del documento XML. Para muchas aplicaciones el modelo de árbol podría no
ser la forma de representación de los datos más apropiada.
DOM
El documento XML entero
debe analizarse una vez al
menos
Costosa la carga el árbol
entero en memoria
Nodos de DOM genérica no
ideal para asociarlo a tipos
de objeto
Push
Pull
No carga el documento en No carga el documento en
memoria.
memoria.
No soporta la modificación No soporta la modificación
XML “en el lugar”
XML “en el lugar”
No soporta alcance para
espacio de nombres
Tabla 2.8: Contras de los modelos de análisis.
40
Contribución al análisis XML para la mejora en las prestaciones de memoria.
5.3 Mejor uso
Se puede analizar un documento XML con DOM, Push (SAX) o Pull (Streaming API).
En esta sección se describe cuando es mejor utilizar cada uno de ellos.
La carga de todo el documento en memoria que realiza el modelo DOM es útil
debido a que se puede acceder fácilmente a toda la información XML, pero supone un
gran consumo de memoria.
Push es rápido y eficiente, pero su modelo de eventos es más utilizado como
filtrado independiente del estado. Por ejemplo, un analizador SAX llama un método en
tu aplicación cuando se encuentra una etiqueta de un elemento y llama un método
diferente cuando se encuentra texto. Si el procesamiento que se hace es independiente
del estado, significando esto que no depende de los elementos que han se han producido
antes, entonces SAX trabaja bien.
Por otra parte, para procesamiento, donde el programa necesita hacer una cosa con
un dato bajo un elemento A pero algo diferente con un elemento B, entonces el modelo
Pull es la mejor elección.
DOM
Aplicaciones que necesiten
alguna modificación de
documentos XML, o para
XSLT.
Push
Pull
Aplicaciones que solo lean Aplicaciones que necesiten
del
XML
(no
para un modelo de flujo y soporte
manipulación
del de espacio de nombres (no
documento)
para manipulación)
Tabla 2.9: Mejor caso para usar el modelos.
DOM es bueno para pequeños documentos, y para la edición de estructuras del
documento XML añadiendo y borrando elementos.
Cuando se necesite modificar una estructura XML, especialmente cuando se
necesite modificar la de forma interactiva, la estructura en memoria toma más sentido.
6 Codificación de texto. Implementaciones.
6.1 Introducción
La codificación de texto ha sido tradicionalmente prometedora para hacer explicita la
comprensión de (o teorías relacionadas) un documento [Coombs 87] [SperbergMcQueen 01a]. Lenguajes de Marcas basados en SGML/XML tales como DocBook
[Walsh 06] o TEI [ACH/ACL/ALLC 94] se han presentado como claros exponentes.
Aunque existen límites al grado de especificación en el que puede conseguirse con la
especificación de los lenguajes. El problema se podría considerar por el hecho de que
aunque los lenguajes de marcas basados en SGML/XML proporcionan reglas explícitas
para la sintaxis de validación y bien formado, pueden proporcionar otra semántica
también válida. Como resultado se proporcionan estructuras de datos generadas
razonablemente bien formadas, pero no son, al menos no sin un posterior desarrollo,
Capítulo 2. Análisis de la información XML.
41
efectivas para la interpretación de la expresividad [Renear 01]. Muchos desarrolladores
de sistemas de programación desean tener un mecanismo para especificar, de una forma
más concreta como obtener las DTDs, qué estructura de datos debe mantener la
aplicación o qué tablas y columnas en una base de datos SQL se pueden construir con
los datos XML cuando se reciben.
El área que nos concierne es la tarea de proporcionar una forma clara y explícita el
significado e interpretación de las marcas. Muchos de los productos y proyectos que
usan XML y SGML asumen de forma implícita que las marcas son el significado, y lo
utilizan para regir el procesamiento de los datos. Un gran número de autores han
descrito sistemas para explotar la información del significado o interpretación de las
marcas, entre estos los más relevantes se describen en [Simons 97], [Simons 99], [Welty
97], [Ramalho 99], [Sperberg-McQueen et al. 01a], [Sperberg-McQueen 01b], y
[Thompson 01]. Hay una gran variedad de razones para que sea un problema
interesante. La mejor forma de comprender el significado asignado a las marcas es que
proporciona una mejor forma de escribir, una forma buena de usar herramientas para
crear, gestionar las marcas.
Ramalho [Ramalho 99] da un marco en el que habilita sustancialmente mejora a la
validación y la calidad para asegurar, y habilitar de forma automática un sistema para
detectar un gran número de errores en el uso de las marcas o en los datos que no pueden
detectados mediante el simple análisis sintáctico o mediante métodos orientados a tipos
de datos.
Welty [Welty 97] argumenta que una aproximación más formal para la semántica
de marcas aumentará considerablemente la mejora en la recuperación y extracción de la
información. Siempre que una clase de inferencia lógica tenga un consumo en tiempo
excesivo para realizar una consulta, esto podría ayudar a reducir el uso de la práctica de
marcas, o en enmascarar la variación en marcas con colecciones heterogéneas [Schatz
96].
Para una documentación que no use XML, el significado de las marcas podría estar
en su mapeo a estructuras de datos, o más bien al significado que puedan tener en el
rango de la aplicación de estructuras de datos y que las marcas podrían validar el mapeo;
esta poción la ha presentado Henry Thompson [Thompson 01]. En un puro nivel
práctico, experiencia con sistemas de esta clase se describen aquí y se puede esperar que
proporcionen información útil de cómo hacer la documentación de la aplicación de las
marcas de una forma clara y útil. En otros trabajos [Sperberg-McQueen et al. 2001a], se
propone identificar el significado de las marcas en un documento como un conjunto de
inferencias.
42
Contribución al análisis XML para la mejora en las prestaciones de memoria.
6.2 DocBook
DocBook es un conjunto de marcas muy extendido para la descripción de libros
artículos, y otros documentos, normalmente de carácter técnico. DocBook esta definido
usando la sintaxis DTD nativa de SGML y XML. Al igual que HTML, DocBook es un
ejemplo de lenguaje de marcas definido sobre SGML/XML.
DocBook tiene unos 15 años de antigüedad. Comenzó en 1991 como un proyecto
conjunto de HaL Computer Systems y O’Reilly. Su popularidad crece, y se presenta para
su mantenimiento por un organismo, el Davenport Group. A mitad de 1998, se convirtió
en un Comité Técnico (TC) de Organization for the Advancement of Structured
Information Standards (OASIS).
La DTD de DocBook fue en un principio diseñada e implementada por HaL
Computer Systems y O’Reilly. & Associates. Se desarrolló inicialmente para facilitar el
intercambio de documentos UNIX inicialmente marcado con troff. Su diseño es el que
en parte sirvió como base para un proyecto posterior con intercambio SGML. Se formó
un comité técnico de DocBook en OASIS a mediados de 1998, con Eduardo Gutentar de
Sun Microsystems. DocBook V3.1, se publicó en febrero de 1999, fue la primera
entrega de OASIS. En febrero de 2001, OASIS hizo las especificaciones oficiales de
DocBook SGML V4.1 y DocBook XML V4.1.2. Posteriormente se han incorporado
además de la DTD, XML Schema [Thompson 01], RELAX y TREX [Clark 01c].
Walsh [Walsh 02] explica como llevar los metadatos a dispositivos con menor
capacidad de recursos, como PDA, y soportando transformación XSLT. Además [Walsh
04] desarrolla una gramática RELAX NG nativa para DocBook.
6.3 UBL (Universal Business Language)
Jon Bosak [UBL 06], considerado como el padre de XML, ha desarrollado (Universal
Business Language). UBL que se ha convertido en una especificación mantenida por
OASIS. UBL soluciona los problemas de intercambio de documentos para negocios en
un formato XML. Su propósito es definir una librería estándar para documentos para el
intercambio de documentos electrónicos XML.
El ímpetu para dar comienzo al comité técnico de UBL procede del deseo de un
número de participantes ebXML[ebXML] para definir un estándar XML para llevar el
formato a ebXML, es decir, una contrapartida XML a los estándares EDI tradicionales.
Tal y como se describen en ebXML, el conjunto ebXML de especificaciones, muchas de
ellas ahora estandarizadas como ISO 15000 [ISO 15000], proporcionan una completa
infraestructura basada en XML que da funciones para utilizar EDI sobre Internet.
UBL proporciona un formato de datos estándar para el intercambio de mensajes en
sobre las infraestructuras que la soportan. Aunque, UBL está diseñado para ser
“agnóstico” con respecto a la infraestructura, y los mensajes UBL pueden usarse en un
Capítulo 2. Análisis de la información XML.
43
amplio rango de contexto desde la más compleja SOA (Service-Oriented Architectures)
al más simple intercambio de documentos via correo electrónico.
6.4 Analizadores. Trabajos relacionados.
Las herramientas de mayor nivel necesitan de elementos que extraigan la
información de forma eficiente, esta operación la realiza los analizadores XML. Estos
programas condicionan el comportamiento de la aplicación y la forma de utilizarlo.
Tanto el funcionamiento como la implementación han dependido de las
implementaciones realizadas sobre SGML. Lécluse [Lécluse 96] presenta una
taxonomía de los analizadores SGML, donde compara las aproximaciones basadas en
árboles frente a eventos.
Los documentos XML deben estar bien formados y pueden estar validados
siguiendo alguna forma de especificar su estructura.
Muchos de los analizadores siguen los modelos e implementaciones que se
realizaron en SGML. Las herramientas XML inicialmente se han adaptado de las
previas existentes en SGML. Jade [Jade], es el procesador de James Clark que soporta
DSSSL (Document Style Semantics and Specification Language) [ISO 10179], que es
un precedente temporal de XSLT [Clark 99] usado por usuarios Linux, ya trasladado a
la plataforma windows. sgmls de Clark es el analizador SGML más utilizado.
OpenJade [OpenJade] es la evolución de Jade. Junto con DSSSLprint y
NEXTPublisher [Next] es una propuesta de Next Solution, OpenJade es una de las
pocas implementaciones de este estándar, y es la herramienta más usada por el proyecto
DocBook para el procesamiento DSSSL. Farreres [Farreres 02] continuó con el
desarrollo de OpenJade.
expat o XT [XT] (analizador y procesador XSLT, respectivamente) son utilizados
por muchos desarrolladores XML también implementados por James Clark. Dada su
importancia en Python [Python], Perl [Perl] y proyectos Apache, expat es uno de los
analizadores más utilizados.
Por otra parte, el proceso de desarrollo del propio SAX comenzó el 13 de
Diciembre de 1997, principalmente como resultado de la persistencia de Peter MurrayRust, que es el autor de un navegador basado en su analizador Java (JUMBO). Peter,
Tim Bray (autor del analizador Lark XML y uno de los editores de la especificación
XML) y David Meggison (autor del analizador XML Ælfred de Microstar) hicieron una
API estándar XML para analizadores basadas en eventos. La discusión se realiza de
forma pública en una lista de correo XML-DEV, con la contribución de mucha gente
aportando comentarios e ideas. Al final Jon Bosak, permitió a SAX usar el dominio
xml.org para el nombre del paquete org.xml.sax. La comunidad de desarrolladores
XML-DEV desarrolló SAX 1.0, que terminó hacia el final del 1998.
44
Contribución al análisis XML para la mejora en las prestaciones de memoria.
DOM surgido bajo el amparo del organismo W3C, y es una forma “natural” de
pensar en un documento de marcas. Es un estándar maduro que ha ido unido a la
recomendación XML desde un principio, tal y como se ha detallado anteriormente.
Casarini [Casarini 01] implementa Gnomo (GNU Network Object Model
Environment) DOM Engine (Gnome2) que es una implementación DOM que apunta a
proporcionar interfaces para documentos XML para programadores Gnome.
Jose Luis Sierra [JLSierra 02] propone un modelo de procesamiento de árboles que
permite la extensión modular de los intérpretes de marcas, basándose en permitir la
extensibilidad de las marcas según [Ousterhout 90], y permitiendo modularidad en los
intérpretes.
DOM4J [DOM4J] es una librería con código abierto para el trabajo con XPath y
XSLT sobre la plataforma Java usando Java Collections Framework y con amplio
soporte para DOM, SAX y JAXP.
JDOM [JDOM] proporciona una solución usando XML para el lenguaje Java que
sea tan simple como Java en sí misma. JDOM está centrada en el lenguaje de
programación Java y optimizada para este lenguaje. Utiliza sus clases y es una API de
fácil manejo para los desarrolladores actuales de Java, y proporciona un bajo coste de
puntos de entrada para usar XML. JDOM tiene un buen comportamiento en el
intercambio de los estándares existentes tales como Simple API for XML y DOM, esta
no es una capa de abstracción o mejora a estas APIs. JDOM proporciona una
implementación robusta, con un peso ligero de lectura y escritura de datos XML sin la
compleja y las opciones de consumo de memoria.
Xerces Java [Xerces], es otra implementación DOM de otro proyecto Apache.
Xerces fue originalmente basado en un analizador Java de IBM, conocido como
XML4J. El desarrollo de Xerces Java 2 provocó una versión beta. La actual versión se
conoce como Xerces Java 1. Al igual que Crimson, el analizador Xerces puede ser
accedido a través de una interfaz SAX2 así como DOM. Aunque, Xerces no
proporciona ninguna forma de usar un analizador diferente al analizador SAX2 con el
Xerces de DOM. Xerces Java incluye suporte de validación contra ambos DTDs y XML
Schema.
Xerces Java también soporta un modo de expansión para DOM, en el cual los
componentes del documento son inicialmente representados en un formato compacto
que es expandido a una amplia representación DOM. Este modo es para permitir un
análisis más rápido y reducir la memoria de uso, particularmente para aplicaciones que
podrían usar solo parte de la entrada del documento. Al igual que Crimson, Xerces es un
código abierto bajo licencia Apache. La versión Xerces 1.4.2 tiene un tamaño de
1.8MB.
Capítulo 2. Análisis de la información XML.
45
Harold propone a XOM [Harold 04] como implementación basada en árboles cuya
mejora es en el tamaño de la aplicación que es de 2 a 3 veces menor que JDOM
[JDOM]. Sin embargo, desborda la metodología estructurada de los objetos que dice
seguir (Java) proporcionando un uso anárquico y extenso de objetos y clases. Descarta el
uso de Interfaces en beneficio de clases. Su implementación no soporta serialización de
objetos. Las páginas web que mantiene a título individual son una extensa recopilación
de tópicos y trabajos relacionados con XML.
Electric XML [EXML] procede de un proyecto comercial soportando entornos
distribuidos. Difiere de los modelos presentados antes en que soporta solo un
subconjunto de documentos XML, no proporciona ningún soporte para validación, y
tiene una licencia más restrictiva. Aunque EXML ofrece la ventaja de tener un tamaño
pequeño y soporte directo para un subconjunto de XPath. No proporciona ninguna
funcionalidad para convertir en o de flujo de eventos DOM o SAX2 excepto de un
texto. EXML es código abierto bajo The Mind Electric una licencia restringida que
prohíbe incrustarlo en cierto tipo de aplicaciones o librerías. La versión Electric XML
2.2 tiene un tamaño de 0.05MB de jar.
Krupnikov [Krupnikov 03] propone Streaming Transformations and Glue
framework (STnG), es una herramienta de transformación a partir de los datos
estructurados en forma arbórea.
Java Web Services Developer Pack (Java WSDP) [JWSDP] es un kit de desarrollo
integrado y gratuito que se puede utilizar para construir, probar y desarrollar
aplicaciones XML, servicios Web, y aplicaciones Web con la última tecnología de
servicios Web e implementación de estándar. Java WSDP 1.6 proporciona elección de
desarrollo y flexibilidad para soportar el Sun Java System Application Server Platform
Edition 8, el Sun Java System Web Server 6.1, y Tomcat 5.0 para Java WSDP 1.5 Web
para el desarrollo de servicios Web.
Gorman [Gorman 04] presenta un analizador XML basado en eventos que se
implementa sobre el analizador SAX, proporcionando un uso sencillo sin reducir las
ventajas del analizador SAX. Ofrece además algunas ventajas del analizador DOM,
presentando un dato en una forma mucho más cercana al punto de vista del diseñador de
un documento XML, y añadiendo algunas herramientas de soporte para facilitar el
diseño, implementando la Generic XML Stream Parser API.
La diferencia en el soporte de un estilo de programación que soporte una API de un
analizador de flujo (stream o basado en eventos), sin embargo el estilo podría parecer
extraño para un desarrollador SAX o DOM. Este estilo de programación depende del
uso implícito y explícito de ambos en el uso de pilas para salvar y restaurar el estado
[Knuth 73]. El procesamiento XML visto desde el programador es como una actividad
en un flujo en serie de datos, con un procesamiento controlado indirectamente mediante
46
Contribución al análisis XML para la mejora en las prestaciones de memoria.
cambio de estados que afectan al proceso de salida en lugar de permitir que sea el
proceso de salida en sí para realizar un proceso de decisión basado en el proceso que
debe de realizar como resultado de salida. Los métodos del elemento ejercitan este
control colocando (pushing) el estado original y modificando el estado actual cuando se
introduce un elemento y, extrayendo (“poping”) el estado original cuando se sale de un
elemento. En este estilo de programación, un método del elemento es un buen “objeto”
para representar un elemento, ya que,
El método responde directamente a la actividad de análisis del elemento.
La invocación analizada del método corresponde a la jerarquía del elemento
en el documento.
El anidamiento del procesamiento de los estados creados por el anidamiento
de la invocación de los métodos corresponde al anidamiento de la semántica
de las interpretaciones implicadas mediante la jerarquía de los elementos y
sus atributos.
Si se puede aceptar la noción de un método como “objeto”, la implementación de
Gorman puede considerarse como una buena aproximación del procesamiento de un
documento XML orientado a objetos.
Sam Wilmott [Wilmott c03] describe las corrutinas, que no es una idea nueva,
Conway [Conway 63] muestra como las corutinas difieren de la forma actual de
transferir el control entre dos líneas de ejecución, y explica como las corutinas se
utilizan para coordinar un par de actividades síncronas.
Gorman [Gorman 04] muestra como transferir el control en un programa Java, esto
se muestra en la Figura 2.24, a través de invocación de un método el cual especifica el
punto en el que la ejecución comienza en el destino, y suspende su ejecución en el punto
actual. Posteriormente devuelve el punto en el que la ejecución fue suspendida.
Principal
Subordinado
V
|
suspende | --- invoca (1) ------------+-> | comienzo
/
|
/
|
/
|
reanuda | <-- devuelve(1) -------+---+-- | fin
|
/
/
|
/
/
|
/
/
suspende | --- invoca (2) --->+
/
/
/
/
reanuda | <-- devuelve (2) --+
|
V
Figura 2.24: Transferencia del control a través de la invocación de métodos.
Capítulo 2. Análisis de la información XML.
47
Se puede percibir como el control de transferencia es asimétrico. Las corutinas, por
otra parte, dan igualdad a ambas líneas de ejecución. Cada línea elige cuando ceder el
control a la otra, pero no especifica el punto de comienzo en la otra línea. En lugar de
esto, la otra línea de ejecución continua desde el punto de vista en el que previamente
cede el control, tal y como se presenta en la Figura 2.25.
Corutina 1
Corutina 2
V
|
suspende | -- reanuda 2 ----------------> |
|
|
|
continúa | <---------------- reanuda 1 -- |
|
|
|
suspende | -- reanuda 2 ----------------> |
|
|
|
continúa | <---------------- reanuda 1 -- |
|
|
V
continúa
suspende
continúa
suspende
Figura 2.25: Transferencia de control en corutinas.
Se pueden usar corutinas para implementar la API en un analizador SAX. Para
realizarlo se transforma cada par de etiquetas de comienzo y final del evento del
analizador SAX en un único método de invocación (tal y como se muestra en la Figura
2.25, esto significa que cada uno de los métodos invocados debería suspenderse
mientras el analizador SAX se ejecuta en el siguiente evento, el método no puede
compartir la pila con el analizador SAX. En Java, (y en otros lenguajes como C++), la
única forma de ejecutarlo con una pila separa es la ejecución con hilos separados (o
separando los procesos. Las corutinas transfieren el control mediante la suspensión de
un método, en lugar de invocar un método y devolverlo desde el método.
El analizador SAX se ejecuta en una corutina, que hereda de Thread añadiendo
métodos para soportar la transferencia del control ilustrada en la figura.
Aplicación
Analizador
V
|
suspende | -- comienza el analizador ---->| comienzo
|
|
continúa | <----- cede a la aplicación -- | suspende
|
|
suspende | -- cede al analizador
-----> | continúa
|
|
continue | <----- cede a la aplicación -- | suspende
|
|
suspende | -- cede al analizador
-----> | continúa
48
Contribución al análisis XML para la mejora en las prestaciones de memoria.
|
|
V
Figura 2.26: Ejecución de un analizador SAX como una corutina.
En la figura se puede observar que el control de transferencia es simétrico después
de que el analizador haya comenzado. La Figura 2.27 muestra como una
implementación podría coordinar una aplicación un analizador SAX cuando se analiza
un documento simple que contiene dos elementos anidados con algunos elementos
PCDATA en su interior.
Aplicación
Actividad
SAX Parser
Actividad
V
|
suspende | -- comienza el analizador ------->|
|
|
continúa | <------- cede a la application -- |
|
|
|
suspende | -- cede al analizador-----------> |
|
|
continue | <------------ startElement (a) -- |
| comienza elemento método (a)
|
|
suspende | -- cede al analizador ----------> |
suspend element method (a) |
|
continúa | <------------ startElement (b) -- |
| comienza elemento método (b)
|
|
suspende | -- cede al analizador ----------> |
suspende element method (b) |
|
continúa | <-----evento characters
-- |
| comienza método characters
|
|
suspende | -- devuelve --------------------> |
|
|
continúa | <-------------- endElement (b) -- |
| reanuda element method (b)
|
|
suspende | -- devuelve --------------------> |
|
|
continúa | <-------------- endElement (a) -- |
| reanuda elemento methodo (a)
|
|
suspende | -- devuelve -------------------> |
|
|
continúa | <---------------------- reanuda-- |
|
|
V
método API
Actividad y alcance
a
b
char
comienza
suspende
continúa
suspende
continúa
suspende
continúa
suspende
continúa
suspende
continúa
suspende
continúa
fin
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Capítulo 2. Análisis de la información XML.
49
Figura 2.27: Ejecución de un analizador SAX como una corutinas.
El alcance del elemento del método a encierra el alcance del elemento del método b,
ya que el elemento del método b es invocado y devuelto mientras el elemento del
método a se suspende. De igual forma, el alcance de los métodos para la obtención de
los caracteres está dentro del elemento de método b.
La implementación de Gorman está escrita en Java, aunque lenguajes como perl
[perl] y Python [Python] podría tener un mejor comportamiento aprovechando las
ventajas con respecto a las operaciones de texto. Los requisitos esenciales para cualquier
lenguaje es que permita un analizador basado en eventos y una aplicación para ejecutar
en una pila separada pero sincronizada con los demás, como podría ser con las
corrutinas [Wilmott 03]. Java no soporta las corutinas y por tanto es necesario usar hilos
sincronizados separados. La misma aproximación debería trabajar en Python, usando
Python rlock. Aunque Python soporta generadores. Un generador produce la salida de
una petición, pero no usa la misma pila como requisito de la aplicación. Por lo tanto, un
analizador que se ejecute en un generador debería ser más o menos equivalente a un
analizador ejecutándose en una corutina.
Sam Wilmott toma una aproximación diferente, creando con OmniMark
[OmniMark] un lenguaje con procesamiento de flujo.
Jeremy Carrol [Carrol 01] aboga por implementar otra capa sobre un analizador
basado en eventos como SAX pero las medidas muestran que las corutinas sobrecarga el
uso en tiempo de procesamiento, debido al intercambio de hilos de Java. Por esta razón,
Carrol recomienda usar un nivel más bajo para guiar la máquina de estados de alto nivel
(él llama esto “invertir” el alto nivel del analizador) de esta forma el bajo nivel puede
ejecutar el alto nivel como una subrutina de más bajo nivel. Este autor no ha seguido en
esta línea, pero comenta que sus propias medidas muestran que la ejecución de una API
de eventos tiene una mayor velocidad que una DOM.
XML Pull Parser (XPP)[XPP] [XPP2] es un desarrollo que muestra una
aproximación diferente para analizar XML. Al igual que EXML, XPP proporciona
soporte solo para un subconjunto de documentos XML y no proporciona soporte para
validación. Contiene la ventaja de tener un tamaño pequeño. Esta ventaja, junto con su
aproximación de análisis Pull, hace que sea una buena alternativa para el análisis XML.
XPP usa interfaces casi exclusivamente, pero este usa solo un pequeño número de
clases en total. La limitación que restringe XPP a un subconjunto de documentos XML
no soporta entidades, comentarios, o procesamiento de instrucciones en el documento.
XPP crea una estructura de documento consistente solo en elementos, atributos
(incluyendo espacio de nombres), y contenidos de texto. Esto es una seria limitación
para algún tipo de aplicaciones. XPP no proporciona ninguna forma de convertir de o a
50
Contribución al análisis XML para la mejora en las prestaciones de memoria.
DOM o SAX2. XPP es código abierto bajo licencia Apache. La versión PullParser 2.0.1
Beta 8 tienen un tamaño de 0.04MB de jar.
La implementación StAX [JSR-173] está desarrollada en los apartados anteriores.
NekoPull [NekoPull] extiende a Xerces Native Interface (XNI) y está diseñado para
proporcionar funcionalidad de análisis Pull.
Se puede representar de forma gráfica e ilustrar como se relacionan las APIs XML
unas con otras. En la Figura 2.27 se representa la clasificación de flujo y eventos sobre
las APIs para el análisis XML. Se puede ver que las APIs caen dentro de alguna de las
dos siguientes categorías: orientada a flujo y orientada a eventos. Hay APIs que pueden
contener ambos tipos de funcionamiento, orientadas a flujo y a eventos, tales como
XPP2 aunque no es lo normal. En la región de las APIs de flujo existen las
implementaciones Push (SAX) y las Pull.
La principal diferencia para el modelo Pull está en como los eventos XML se
propagan, de esta forma distinguimos tres grupos:
La aproximación del tipo Cursor, donde los eventos están disponibles
directamente procedentes del analizador como propiedad y no se crea objeto
para representar el evento XML (como por ejemplo, XmlPull, XPP3,
kXML2, StAX en modo Cursor).
La aproximación del tipo Iterador, cada evento XML se representa como un
objeto nuevo (kXML1, StAX en modo Iterador).
Una aproximación mezcla de las dos anteriores (reutilización de eventos):
los objetos de los eventos son utilizados pero su creación puede evitarse y
pueden reutilizarse los objetos utilizados por los eventos (NekoPull, XPP1,
XPP2).
Push
SAX
Eventos
Árboles
zcl
DOM
JDOM
Me
Cu
rs
or
a
Pull
BEA
kXML1 Iterador
XPP2
StAX
Neko
XmlPull
Pull
(XNI2XmlPull,
kXML2,
XPP1
XPP3)
DOM4J
…
Figura 2.28: Taxonomía de las APIs XML.
Stefan Haustein y Aleksander Slominski presentan una línea temporal para las APIs
XML escritas en Java. En la Figura 2.29 se muestran las APIs basadas en eventos tanto
Push como Pull.
Capítulo 2. Análisis de la información XML.
Push
SAX1
Ælfred
51
SAX2
Pull
kXML1
XP
NekoPull
www.trantor.de/xml/
XPP1
BEA
Iterador
Cursor
1998
1999
StAX
XmlPull1:
kXML2
XPP3
2000
2001
2002
2003
2004
2005
Figura 2.29: Temporización de las APIs XML en Java según Slominski y Haustein.
Jimmy Zhang [Zhang 04a][Zhang 04b] implementa el Virtual Token Descriptor –
VTD- para el análisis XML [VTD-XML]. VTD-XML usa enteros de 64 bit para
representar el comienzo, longitud, tipo y otra información relevante relacionada con un
token para el análisis XML suponiendo una considerable mejora en las prestaciones de
memoria utilizada durante el análisis.
6.5 Validación de documentos XML.
La validación de los documentos lleva asociada la forma en la que se especifica la
información contenida en el documento XML, habitualmente se dice que hay un
“modelo de contenido” para un documento XML. Murata [Murata 00a], hace una
taxonomía de los lenguajes de modelado XML usando la teoría de lenguajes formales.
El modelo de contenido puede expresarse de alguna de las siguientes formas:
DTD, que es el modelo heredado de SGML y recogido en la recomendación
XML.
XML Schema [Thompson 01], una iniciativa del W3C que concluyó con
una amplia recomendación, con un extenso número de participantes en la
propuesta.
Schematron [ISO/IEC 19757], que está propuesto para la estandarización
ISO.
RELAX NG [Clark 01b], elaborado, diseñado e implementado por James
Clark y estándar internacional (ISO).
Las implementaciones de Sun hechas con Java siempre son un punto de referencia,
este es el caso de Sun Multi-Schema XML Validator (MSV), implementado por Kohsuke
Kawaguchi [Kawaguchi 03]. Su tamaño es de 2.3 MB y da soporte a varios lenguaje de
modelado.
James Clark propone Tree Regular Expressions for XML (TREX) [Clark 01e].
TREX es un lenguaje para la validación de documentos XML.
Thompson y Tobin [Thompson 03] usan un autómata de estados finitos (FSA) para
realizar la validación XML siguiendo XML Schema [Thompson 01].
52
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Desde 1991, Murata [Makoto 98][Murata 97][Murata 98][Murata 00a][Murata
00b][Murata 01] [Murata 03] ha construido la teoría de los lenguajes regulares
(tree/hedge) para validar tanto RELAX NG como XML Schema haciendo propuestas de
validación sobre la plataforma Java para móviles.
6.6 Taxonomía de los analizadores en la Java ME.
6.6.1 Introducción
Jonathan Knudsen [Knudsen 02a], presenta un escenario para el uso de analizadores
XML y una taxonomía de las implementaciones, indicando el tipo, licencia y otros
detalles de los analizadores, tal y como se muestra en la Tabla 2.10.
Nombre
KXML
MinML
TAM
NanoXML
TinyXML
XMLtp
Xparse-J 1.0
URL
http:kxml.enhyndra.org
http://www.wilson.co.uk/xml/minml.htm
http://simonstl.com/projects/tam/
http://nanoxml.sourceforge.net/orig/kvm.html
http://www.grinninglizard.com/tinyxml/
http://mitglied.lycos.de/xmltp/
http://www.webreference.com/xml/tools/xparsej.html
Licencia
EPL
BSD
MPL
Zlib/libpng
GPL
BSD
GPL
MIDP
Si
No
Si
Si
No
No
Si
Tipo
Pull
Push
Push
DOM
DOM
DOM
DOM
Tabla 2.10: Analizadores XML de pequeño tamaño.
Nombre
BSD
CPL
EPL
GPL
LGPL
MPL
Zlib/libpng
URL
http://opensource.org/licenses/bsd-license.php
http://opensource.org/licenses/cpl.php
http://kxml.enhydra.org/software/license/
http://www.webreference.com/xml/tools/license.html
http://opensource.org/licenses/lgpl-license.php
http://www.mozilla.org/MPL/MPL-1.1html
http://opensource.org/licenses/zlib-license.php
Tabla 2.11: Licencias de los analizadores XML.
6.6.2 NanoXML
Eric Giguère llevó con NanoXML 1.6.4 [NanoXML] un analizador XML a la KVM. La
KVM sigue la especificación CLDC (Connected Limited Device Configuration de la Java 2
Micro Edition). Esta implementación es una pequeña versión para la Máquina Virtual de
Java que está pensada para pequeños dispositivos inalámbricos.
En Abril de 2000, NanoXML salió el proyecto AUIT, The Abstract User Interface
Toolkit.
El propósito en la implementación de NanoXML fue el de realizar un analizador
pequeño, que sea fácil de utilizar. SAX y DOM son demasiado complejos para lo que se
necesitaba y son demasiado grandes para su uso.
Capítulo 2. Análisis de la información XML.
53
NanoXML 1 es considerablemente pequeño, razonablemente rápido para pequeños
documentos XML es bastante fácil de usar y es gratuito (bajo licencia zlib/libpng).
Como no es un analizador que esté pensado para analizar un documento DocBook, no
soporta análisis de la DTD o mezcla de datos.
NanoXML es un proyecto SourceForge y, la versión 1.6.8 es de Mayo de 2001.
En Julio de 2001, apareció NanoXML 2. A diferencia de NanoXML1, la velocidad
y el cumplimiento se consideraron como criterios para la nueva versión. NanoXML 2 es
muy modular, se puede fácilmente reemplazar los diferentes componentes en el
analizador para personalizarlo como se necesite. La modularidad de nanoXML 2
también beneficia extensiones como el soporte SAX, el cual puede ahora directamente
acceder al analizador. En NanoXML 1, el adaptador SAX tiene que iterar la estructura
de datos construida.
El tamaño de esta nueva versión aumentó considerablemente a un fichero jar de
tamaño 32K. Este tamaño continúa siendo bastante pequeño comparado con los
analizadores de otras plataformas.
Hay tres ramas en NanoXML 2:
NanoXML/Lite es el sucesor de NanoXML 1. Caracteriza un analizador
que es extremadamente pequeño.
NanoXML/Java es el analizador estándar.
NanoXML/SAX es el adaptador SAX para NanoXML/Java.
Otra versión de NanoXML es NanoXML2.2.1, que data de Abril de 2002.
6.6.3 kXML2
kXML [kXML2] es un pequeño analizador XML al estilo Pull, especialmente
diseñado para entornos limitados tales como Applets, Personal Java o dispositivos
MIDP, basado en la API XML.
kXML proporciona una libreria compacta para el uso en dispositivos J2ME. KXML
es un proyecto mantenido por la organización Enhydra que soporta las siguientes
características, soporte de espacio de nombres XML, modo "Relaxed" para el análisis
HTML u otros formatos SGML, pequeño tamaño, soporte para escritura, y
opcionalmente soporte DOM y WAP.
kXML2 es un analizador XML Pull, similar a kXML, pero no soporta espacio de
nombres. El tamaño es bastante pequeño. Si se necesita soporte para espacio de nombre,
o acceso a los comentarios XML o instrucciones reprocesamiento, se debería de utilizar
kXML2 que aumenta considerablemente su tamaño. La implementación está realizada
en el paquete: org.kobjects.xml.
kXML3 propone un modelo arquitectónico del que no proporciona ningún código.
El proyecto Enhydra kXML esta actualmente cerrado.
54
Contribución al análisis XML para la mejora en las prestaciones de memoria.
6.6.4 MinML
Un analizador que sigue el modelo Push es MinML [MinML]. Éste es un analizador
XML mínimo (minimal XML parser). Este analizador está pensado para poderse
ejecutar en sistemas embebidos (de 512Kb de RAM) sin usar todos los recursos del
sistema para analizar el documento.
Algunas de las características de este analizador son las siguientes, que lee las DTD
pero no las procesa, así como las secciones CDATA, atributos, referencias a entidad
(&amp; etc), y elementos vacíos.
Soporta SAX1 y se ha añadido una extensión simple (haciendo subclase de
org.xml.sax.DocumentHandler y org.xml.sax.Parser) que permite
caracteres de datos para ser procesados en la aplicación del usuario proporcionados en
subclases de java.io.Reader.
MinML es bastante pequeño. Tiene un fichero jar de 14Kb aproximadamente. Está
bajo licencia de estilo BSD. Se puede descargar una versión estable, la 1.7 desde el 18
de Noviembre de 2001.
6.6.5 XMLtp
XMLtp [XMLtp] es un pequeño analizador XML, escrito en Java. Su principal
propósito es servir a la parte de la aplicación que desea usar XML con un formato de
almacenamiento para los datos de la aplicación, que sigue el modelo Push.
XMLtp permite un subconjunto de XML para la comprobación de que un
documento XML está “bien formado”. Esta implementación no soporta validación con
DTDs. Por lo tanto no entiende la correspondiente declaración de la semántica de la
DTD de la especificación XML.
Según los diseñadores, hay unos usos para una DTD y es cuando XML de usan por
aplicaciones como su formato de almacenamiento de datos interno. La aplicación tiene
que comprender y verificar la corrección semántica de su aplicación de datos y, en el
sentido más estricto que pueden definirse en una DTD. Además XMLtp proporciona el
manejo sintáctico para leer XML, pero forma parte de las tareas del programador
proporcionar la semántica de comprobación de los datos.
En el caso de que se necesite verificación, hay una carga de procesamiento mayor
en la implementación de SAX. Estos procesadores son mayores que XMLtp. XMLtp fue
escrito para tener un analizador pequeño, no para cubrir todas las características.
Algunas de las características se resumen a continuación, soporte Unicode, los
comentarios son ignorados, así como las instrucciones de procesamiento que también
son ignoradas. Se puede considerar un analizador pequeño, “Casi” XML, rápido y de
fácil manejo.
Capítulo 2. Análisis de la información XML.
55
6.6.6 TinyXML
TinyXML es un analizador XML pequeño y simple escrito en C++ que puede ser
fácilmente integrado en otros programas. Esta es un propuesta mantenida por
Sourceforge. En las últimas versiones se ha incorporado soporte para las secciones
CDATA. Sin embargo, resulta inapropiado para plataformas Java sin soporte para
código nativo.
6.6.7 Xparse-J
Xparse-J es un analizador XML escrito en Java que "aspira a ser el analizador XML
escrito en Java más pequeño del planeta". Xparse-J es una traducción de Xparse, un
analizador XML JavaScript de 5K.
Xparse-J no lee las DTD, tampoco da soporte para la interfaz SAX o DOM. Aunque
su funcionamiento puede aproximarse más a un estilo DOM. Xparse-J lee el documento
XML de un string para dar una presentación del documento con una estructura en forma
de
árbol
contenido
en
com.exploringxml.xml.Node
y
com.exploringxml.xml.JSArray. Ambos Node y JSArray contienen las
funcionalidades básicas para la navegación a lo largo de árbol del documento para
acceder a todos los datos.
Xparse-J consta sólo de tres clases:
La clase principal: Xparse
La clase para delimitar un nodo en el documento XML: Node
La clase array que contiene los elementos hijos, atributos, etc.: JSArray
Para realizar la lectura del documento se utiliza el método Xparse.parse().
Cada nodo conteine un de java.util.Hashtable atributos, que se puede consultar
mediante numeración al estilo Java.
Xparse-J está distribuido bajo liciencia pública GNU (GPL).
6.6.8 JSR-280
La implementación de Java JSR-280 [JSR-280] está pensada para proporcionar una API
XML de propósito general para la siguiente generación de dispositivos móviles. Java
tiene pensado fragmentar las interfaces XML en estos dispositivos; cada especificación
(JSR) que necesite soporte XML tiene un subconjunto de la propia especificación. La
API propone que dará soporte a:
Análisis basado en manejadores de eventos SAX 2
Procesamiento de documentos al estilo DOM
Esta API podría también incluir soporte para análisis Pull.
56
Contribución al análisis XML para la mejora en las prestaciones de memoria.
7 Qué hace diferentes a los analizadores.
7.1 Consideraciones generales
En esta sección se presentan una clasificación de aspectos que hacen diferentes a los
analizadores. Las interfaces de análisis ofrecen los métodos mediante los cuales se
pueden acceder. XML nos invita modelar la información como un árbol, pero éste no
necesita ser procesado de esta forma. XML puede ser comprendido, y procesado, en
diferentes niveles de abstracción [Sperberg-Mcqueen 05]:
1. Como un flujo de caracteres
2. Como una secuencia de caracteres de datos mezclado con marcas
3. Como un árbol en su forma obvia
4. Como un grafo con enlaces entre nodos (definidos por relaciones entre la
relación padre-hijo y los elementos XML, por enlaces ID/IDREF, o por
métodos de aplicación específicas entre elementos)
5. Como un árbol o grafo con información del tipo de datos y validez
6. Como una instancia de la estructura de datos de una aplicación
La multiplicidad de niveles presenta otras opciones sobre la unicidad en la
definición de un modelo, con acceso restringido a un solo nivel de abstracción
proporcionado a través de una interfaz de aplicación en programación bien controlada.
En esta dirección se presentan los aspectos que hacen diferentes las distintas clases
de analizadores XML, enfocándolos función de [Wilmott 05]:
La forma en la que los datos son devueltos,
qué información es devuelta al cliente,
La relación entre el analizador y el cliente.
Estos tres puntos se desarrollan a continuación.
7.2 Forma en la que los datos son devueltos
Las diferencias establecidas entre los modelos de análisis determinan características en
cuanto a la forma en la que los datos son devueltos, marcando diferencias entre
analizadores que trabajan in-situ, y analizadores que copian los datos. Los analizadores
entregan información de documento que se analizan donde un marco de trabajo suele ser
algún lenguaje orientado a objetos que contienen información sobre el documento
analizado. Estos objetos contienen información del documento XML. Esta información
se puede copiar del origen de donde se obtiene o se puede devolver el lugar de donde se
ha obtenido la información.
1. Los analizadores “in-situ” en la medida de lo posible, indican donde se han
encontrado los datos en el documento, en vez de copiarlos. Análisis “in-situ” de los
Capítulo 2. Análisis de la información XML.
57
datos XML deja la información en la posición o dispositivo desde donde fue
proporcionada al analizador XML, en lugar de copiarla en el analizador. Un
analizador in-situ analiza los datos a su cliente referenciándolos en los datos
originales en lugar de proporcionarlos con una copia para el cliente. Los datos
originales pueden estar en un sistema de ficheros, en una base de datos, en un buffer
“leído”, en una “plataforma” de memoria (un mensaje de texto en tu teléfono), en un
buffer de un editor de texto (en memoria o paginado), en una estructura de datos del
cliente.
El análisis in-situ tiene dos ventajas principales.
En primer lugar, es poco disperso en el uso de la memoria local, lo cual es
importante cuando la memoria local es pequeña (como por ejemplo en un
teléfono celular) o los documentos analizados son grandes (construyendo
una base de datos).
Por otra parte soporta XML usando un formato nativo de la aplicación,
como por ejemplo un editor de texto que use XML como representación
interna de un documento. Un analizador “in-situ” analiza los datos a su
cliente referenciándolos en los datos originales en lugar de proporcionarlos
con una copia para el cliente.
2. Los analizadores que copian la información del documento XML en objetos
devolviéndolo al cliente.
El análisis in-situ de la información XML tiene aspectos positivos. Por una parte
concentra el uso de la memoria de la memoria utilizada, lo cual es importante donde la
memoria es pequeña o los documentos analizados sean grandes. Soporta la información
usando un formato nativo de la aplicación.
In-situ es más potente que la copia de los datos (“data-copying”). Si el cliente no
tiene cuidado donde los datos están los datos, ambos lo harán; si el cliente tiene cuidado,
solo in-situ lo hará. En el proceso de análisis de los documentos XML, primero son los
analizadores data-copying primero y los analizadores in-situ vienen después.
Los analizadores XML que usan una copia de los datos de la fuente de la
información XML, construyen objetos para su procesamiento y análisis.
Los analizadores in-situ especifican donde los datos fueron encontrados, en la
medida de lo posible. Estos analizadores utilizan elementos que puedan representar la
posición donde la información está ubicada. Los punteros son un tipo de referencia.
Estos elementos son referencias como elemento que contiene una dirección.
La forma en la que los datos son devueltos bien sean in-situ o con copia de datos, es
independiente de la interfaz que se utilice, bien sea basada en eventos o árboles. Sin
embargo el modelo basado en árboles se considera que es más intensivo en memoria,
para proporcionar un funcionamiento con acceso aleatorio a la información del
58
Contribución al análisis XML para la mejora en las prestaciones de memoria.
documento, con posibilidad de modificar fácilmente la estructura en memoria. Los
analizadores XML que usan una copia de los datos de la fuente de la información XML,
construyen objetos para su procesamiento y análisis.
7.3 La información que es devuelta al cliente
La entrega de la información de un documento XML puede variar para una misma
interfaz de programación. Estas interfaces presentan diferencias de un modelo a otro ya
que su funcionamiento condiciona la forma en la que los datos son devueltos a la
aplicación o cliente. Los modelos de procesamiento de mensajes (tales como los SOAP)
más conocidos, provocan una elección entre los modelos basados en eventos y los
modelos basados en árboles. La combinación del buen funcionamiento, baja memoria,
acceso aleatorio, actualización incremental, obliga a tomar una decisión entre el modelo
utilizado.
La entrega de la información del documento XML puede presentar varias
diferencias dependiendo de como los datos son devueltos. Los analizadores pueden
copiar toda la información del documento XML construyendo objetos para devolverlos
al cliente. Los analizadores in-situ, en la medida de lo posible, indican donde los datos
fueron encontrados en el documento analizado.
Según qué información es devuelta al cliente,
La estructura de los elementos y propiedades, y datos que contienen la
información. Se puede devolver la información en sí un evento que se asocie
a un determinado tipo de información. La información contenida en un
archivo XML son cadenas de caracteres y la forma de devolver la
información va asociada a estructuras de datos relacionados con cadenas de
caracteres e irá intrínsecamente asociada al lenguaje de programación que se
esté utilizando.
Posición de la entidad interna y el valor de la información. El
posicionamiento de la entidad interna podrá estar asociado a elementos de
direccionamiento de las estructuras.
Información de la entidad externa, y la posibilidad del cliente de participar
en la entidad de resolución.
La entrega de la información de un documento XML desde el analizador, se realiza
en un programa a través de una interfaz. Estas interfaces presentan diferencias de un
modelo a otro ya que su funcionamiento condiciona la forma en la que los datos son
devueltos a la aplicación o cliente.
Capítulo 2. Análisis de la información XML.
59
7.4 Relación entre el analizador y el cliente
Según la relación entre el analizador y el cliente, los modelos de análisis tienen un
comportamiento diferente,
un analizador DOM devuelve al cliente una representación en forma de árbol del
documento XML para poder acceder y manipularlo.
Un analizador Push llama a los métodos del cliente según los datos del
documento XML, transformando en eventos para el cliente.
Un analizador Pull devuelve los eventos XML al cliente bajo petición del
cliente.
Los modelos basados en eventos, Push y Pull leen de representación serializada,
como un flujo de entrada, de donde se obtienen los datos, pero nunca se puede ir hacia
atrás hacia una posición anterior o saltar a otra posición hacia delante. Si se quiere
acceder a una posición previa se debe de usar el modelo DOM pero tiene un uso
intensivo en memoria. Sería deseable poder acceder a posiciones previas en la
representación serializada de la información XML, sin tener el uso intensivo en
memoria que realiza DOM. Es por tanto deseable, de cara tener un buen
comportamiento en memoria durante la ejecución de una aplicación basada en XML,
utilizar un analizador basado en eventos del tipo Pull que puedan acceder a todo el
documento tal y como lo hace DOM, sin que por ello suponga una penalización en
cuanto al uso intensivo de la memoria utilizada en la ejecución de este proceso. Por
tanto, una buena solución sería extender la interfaz Pull para manejar el documento
XML bajo demanda, realizando análisis in-situ para obtener un mejor comportamiento
en memoria.
8 Conclusiones
Este capítulo ha definido los elementos utilizados en el proceso de análisis de los
documentos XML:
Los analizadores XML (ó “parsers”): Los analizadores son programas que
extraen la información contenida en él. Estos programas pueden utilizar una
representación del documento para poder realizar las operaciones de análisis
de la información contenida en el documento.
Representación serializada: La representación del documento son los datos
estructurados usados por el programa para trabajar con el documento en
memoria, se denomina representación serializada. Esta representación se
utiliza como entrada para el analizador XML.
60
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Fuente de datos virtual: La fuente de datos virtual, es el lugar que contiene
los datos XML donde normalmente son almacenados, y se extraen los datos
para construir su formato serializado.
DOM, Push y Pull:
o DOM es la especificación de una API para el procesamiento XML
basado en árboles. Ya que DOM crea una estructura de datos en
memoria modelando los datos representados en XML y permitiendo
acceso aleatorio, y se considera como una forma muy fácil y natura
de trabajar con XML. Pero la construcción del árbol DOM puede
consumir varias veces el tamaño del fichero, y cuando el tamaño del
fichero es grande supone un coste de procesamiento bastante grande,
haciendo que DOM no sea deseable debido al alto consumo de
recursos.
o Push y Pull proporcionan un excelente funcionamiento cuando DOM
presenta problemas de memoria y procesamiento, ambos usan
interfaces de bajo nivel de tokenización y, por defecto, nunca
mantienen el documento entero en memoria. Como resultado el
procesamiento XML basado Push y Pull va asociado a un menor
consumo de memoria y potencialmente pueden manejar ficheros
XML mayores. A menos que el cliente construya su propio modelo
de forma personalizada en la aplicación que usa el analizador, Push y
Pull no ofrecen acceso aleatorio, y en un uso ineficiente puede
provocar el escanear el documento XML varias veces, haciendo que
el funcionamiento de DOM sea una mejor solución.
in-situ: Según como los datos son devueltos, los analizadores copian toda la
información del documento XML en objetos, devolviéndolos al cliente. Los
analizadores in-situ, en la medida de lo posible, indican donde los datos
fueron encontrados en el documento analizado.
Según que información es devuelta al cliente, la estructura de los elementos
y propiedades, y datos que contienen la información se puede proporcionar,
y los datos que contienen la información. La información de la entidad
externa y la posibilidad del cliente de participar en la resolución de la
entidad.
Los diferentes modelos de análisis de los documentos XML están basados en
árboles o basados en eventos. Los modelos basados en árboles construyen una
representación interna de todo el documento en memoria. Los modelos basados en
eventos entregan los eventos analizado a la aplicación, proporcionando un acceso serie
(en un formato serializado) para acceder al documento XML. Estos modelos hacen
Capítulo 2. Análisis de la información XML.
61
accesibles la información del documento a través de las distintas interfaces, estas son
DOM, para el modelo basado en árboles, que permite un acceso al documento entero
debido al mantenimiento en memoria, y Push/Pull. En este capítulo se ha presentado la
forma en la que los analizadores pueden
manejar la información del documento XML, de esta forma pueden resaltarse
dos puntos, el acceso de la información como entrada al analizador y por otra
parte según la forma en la que la información es devuelta a la aplicación. Y
por tanto se ha presentado
El análisis in-situ: Según como los datos son devueltos, los analizadores
copian toda la información del documento XML en objetos, devolviéndolos
al cliente. Los analizadores in-situ, en la medida de lo posible, indican donde
los datos fueron encontrados en el documento analizado.
El análisis sin extracción de los datos: Según que información es devuelta
al cliente, la estructura de los elementos y propiedades, y datos que contienen
la información se puede proporcionar, y los datos que contienen la
información. La información de la entidad externa y la posibilidad del cliente
de participar en la resolución de la entidad.
Por otra parte se ha presentado una amplia panorámica de las implementaciones
realizadas con los distintos modelos de análisis.
CAPÍTULO 3.
Modelo Propuesto
En el capítulo anterior se ha detallado el proceso de análisis y estructura de un
documento XML y se han enumerado las interfaces disponibles y sus características, así
como distintas propuestas e implementaciones. De esta forma podemos referirnos a
DOM, Push y Pull como los tres interfaces para analizar la información XML, con
distintas implementaciones y propuestas para los distintos modelos. Este capítulo
presenta el nuevo modelo de análisis. El nuevo modelo de análisis XML, extiende la
interfaz Pull a todo el documento, y es un modelo basado en eventos, que permite el
movimiento no sólo hacia delante como los modelos Push y Pull, sino también permite
el movimiento del cursor hacia atrás, accediendo a elementos previamente analizados.
La implementación realizada de este modelo requiere el mantenimiento de la
representación del documento XML. A lo largo de este capítulo se presentan los
elementos en los que se basa el nuevo modelo, interfaz Pull y análisis in situ. Se detalla
como extender la interfaz Pull a todo el documento con los métodos que soportan estas
operaciones. Se presenta el modelo productor/consumidor del nuevo modelo. Se
presentan ejemplos de uso de este modelo. Finalmente, se presenta una implementación
en el lenguaje Java que realiza estas operaciones.
1 Introducción
Muchos documentos, (tales como libros, revista,... ) podrían tener una forma
determinada en la que están estructurados los documentos. En una gran cantidad de
situaciones, después de que los datos sean procesados, los resultados necesitan ser
escritos en un formato XML, para asegurar su reutilización y longevidad de la
información. Aplicado de forma consistente, esta línea de pensamiento da como
resultado una arquitectura de procesamiento de la información en la cual virtualmente
cada proceso se convierte de una transformación XML en otra. Muchos documentos
pueden estar compuestos por componentes (tales como capítulos y artículos). Estos
pueden descomponerse en componentes (tales como títulos, párrafos, figuras, ...). En
XML, estos componenetes, como ya hemos vistos se llaman elementos. Cada elemento
representa un componente lógico de un documento. Los elementos pueden contener
64
Contribución al análisis XML para la mejora en las prestaciones de memoria.
otros elementos y pueden también contener palabras y sentencias en las que se debería
pensar normalmente como el texto de un documento. XML llama este texto los
caracteres de datos del documento. Esta vista jerárquica del documento XML se ha
presentado de forma gráfica en los ejemplos DOM del capítulo anterior. Su estructura
jerárquica se conoce habitualmente como estructura arbórea. El elemento que contiene a
todos los demás se conoce como raíz. Los elementos pueden también contener
información extra añadida en los atributos, describiendo las propiedades de los
elementos, tal y como se ha mostrado en el ejemplo del capítulo previo. Una aplicación
necesita diferentes niveles de abstracción, y se puede entender que los componentes de
descripción de marcado, se enfrenta a la independencia de la aplicación, pudiendo ser
una ventaja, en lugar de ser una desventaja, para permitir a XML ser visto de esta forma
con diferentes niveles. Las diferentes capas en la pila XML proporciona acceso a estos
niveles de abstracción. El estudio detallado de las características de análisis de los
documentos XML permite realizar una aproximación en búsqueda de elementos y
operaciones que optimicen el uso de la memoria, a fin de poder aplicarlo a plataformas
donde los recursos (expresados en términos de memoria) sean un factor crítico, para el
despliegue de aplicaciones que den soporte a la nueva generación de dispositivos. El
flujo de datos XML se puede proporcionar mediante un sistema de ficheros, o una
interfaz de red. La declaración interna de la codificación de caracteres es necesaria para
traducir del flujo de octetos procedentes al flujo de caracteres. Un analizador XML lee
del flujo de octetos, los traduce en caracteres, y los analiza traduciéndolos a contenidos
y marcas, proporcionando acceso para mediante alguna de las interfaces de análisis.
El mantenimiento de la representación serializada del documento XML en un
formato serializado extraído de la fuente de datos de la que procede el documento XML,
puede suponer una mejora en memoria, si no se realiza duplicación de esta
representación. Se puede realizar un análisis eficiente de la información con un enfoque
de la memoria utilizada de tal forma que los datos sean analizados en el lugar de donde
se han extraído. El nuevo modelo de análisis se plantea bajo características de análisis
que manejen estructuras de datos con la menor duplicación de la información,
manteniendo una única representación. Se realiza una implementación haciendo
hincapié en el análisis de los documentos en el lugar en el que se encontraron,
enfocándolo desde dos perspectivas diferentes: bajo el punto de vista de los datos que se
proporcionan a la aplicación y bajo el punto de vista de los datos suministrados a la
aplicación.
Capítulo 3. Modelo propuesto.
65
2 El nuevo modelo
El nuevo modelo de análisis de documentos XML usa el cursor como elemento que
contiene información sobre el evento generado permitiendo la posibilidad de extraerla
de la representación del documento XML generada.
Este modelo permite el movimiento del cursor para acceder a información
previamente analizada, y es un modelo basado en eventos, y por tanto no construye la
pesada (en términos de memoria) representación arbórea del modelo DOM y
proporciona la posibilidad de mover el cursor hacia adelante y hacia atrás, a información
previamente analizada en el proceso de iteración. El control del análisis de la
información XML en este modelo es del programador, mediante una API basada en un
patrón iterativo y los eventos del flujo asociados. Esta propuesta se presenta un marco
de los dispositivos móviles para llevar la tecnología XML en el marco de los Servicios
Web XML.
2.1 Pull-everything
Se puede pensar en la API Push y Pull como una interfaz que accede secuencialmente a
los datos contenidos en el XML. Un analizador XML debería asegurar que el
documento XML está “bien formado” (well-formed) para que las etiquetas estén
correctamente construidas, cada etiqueta de comienzo tenga su etiqueta de finalización
asociada, y que los elementos estén siempre anadidos de forma correcta unos con otros.
Estos modelos están guiados por eventos. El analizador lee el documento XML una vez,
desde el comienzo hasta el final, y cada evento de análisis, tal y como el reconocimiento
del comienzo o final de un elemento, y lo notifica a la aplicación. La API SAX es rápida
y usa menos memoria y es aconsejable usarla cuando se realizan solo operaciones de
lectura o see van a realizar cambios son pequeños. Tal y como se ha visto en el ejemplo
del capítulo anterior primero se genera una instancia del analizador con
SAXParserFactory. Y cuando se ejecuta el analizador, este invoca las operaciones
apropiadas (llamadas a los métodos), que se organizan en grupos (o interfaces). Y estos
métodos son los que determinan qué hacer en la aplicación del programador. Además de
los manejadores (“hander”) mostrados en el capítulo anterior se puede utilizar los
métodos de DocumentHandler. La información de los eventos que el analizador
reconoce se envían a la interfaz DocumentHandler para su procesamiento.
DOM no puede ser usada para leer el documento XML, por esto usa SAX, de esta
forma SAX y DOM pueden trabajar juntos. DOM es una colección de objetos en el
programa que se pueden manipular. De esta forma, cuando la aplicación desea realizar
algún cambio, este puede modificar su estructura, modificando datos, eliminándolos, o
insertando datos nuevos. Cuando la aplicación ha realizado todos los cambios, puede
66
Contribución al análisis XML para la mejora en las prestaciones de memoria.
entonces escribir la estructura en un documento XML. La API DOM oculta los detalles
de la API SAX, y proporciona una estructura de objetos en forma de árbol bastante
familiar. Por otra parte, la construcción de DOM requiere leer todo el documento y
montar el árbol en memoria por lo que es más intensivo en memoria. Por esta razón, la
API SAX podría ser más apropiada para aplicaciones en la parte del servidor y filtrado
independiente del estado de los datos que no necesiten una representación en memoria
de documento entero, ya que es rápido y eficiente.
XP [XP] es el primer analizador al estilo Pull implementado por Stefan Haustein al
estilo iterador, tal y como se ha presentado en la Figura 2.28 del capítulo anterior. La
implementación se realizó “encima” de SAX para proporcionar algunas funcionalidades,
que suelen ser apropiadas y utilizas una vez construido el árbol DOM para recorrer (de
forma iterativa) elementos del documento. Este nivel de apilamiento de API hace que
pueda plantearse como una solución eficiente el análisis in-situ con una interfaz Pull sin
la extracción de eventos desde la API SAX, este punto se considera en la siguiente
sección y va asociado al mantenimiento de una estructura en la se mantiene
almacenados los datos y a los que se puede a todos acceder. Consecuentemente, en este
contexto se puede extender las peticiones del estilo Pull a todo el documento con un
direccionamiento en la iteración tanto en el sentido habitual de Push y Pull, como en la
dirección hacia atrás hacia información que ha podido ser analizada previamente.
La implementación más simple de un analizador es la que sigue el modelo Push.
Dependiendo del contenido del documento y del estado interno el analizador produce
eventos como “startElement” or “characters” que son enviados (o empujados, “pushed”)
para ser tratados por la aplicación. Aunque el modelo Push, bajo el punto de vista de la
aplicación puede causar algunos problemas en el manejo del evento, ya que la aplicación
necesita conocer el estado de procesamiento interno antes de hacer algo con el evento.
Esta funcionalidad se proporciona de una forma bastante natural en el modelo Pull.
SAX, como se ha dicho realiza un análisis independiente del estado, a diferencia del
procesamiento dependiente del estado que realiza el modelo Pull, donde el programa
necesita hacer una cosa con los datos de un elemento A y algo diferente con los datos de
otro elemento A, es en estos casos donde el modelo Pull podría ser la mejor elección.
Con un analizador Pull, se puede obtener el siguiente (next) nodo, en cualquier punto
del código y preguntar por él, mediante el uso de los métodos “getter”. El eliminar las
interfaces subyacentes para la implementación de un modelo Pull con el acceso a toda la
estructura serializada del documento XML, permite acceder a información previamente
analizada haciendo posible realizar las preguntas (Pull) desde la aplicación al
analizador.
Capítulo 3. Modelo propuesto.
67
El análisis Pull usa dos métodos de un iterador next() y hasNext(). Un
iterador en el lenguaje de programación Java es un objeto que puede moverse a lo largo
de una secuencia de objetos y selecciona cada uno de la secuencia.
El modelo Pull da el control del análisis al programador mediante una API basada
en un iterador simple. Los métodos next() y hasNext() permiten a la aplicación
desarrollar y preguntar por el siguiente evento, pide el evento; en lugar de hacer frente a
los eventos producidos, tal y como sucede en el modelo Push.
Pull-everything, extiende la interfaz Pull a todo el documento. Permite generar
eventos en la forma Pull, tal y como se lee la información del formato serializada del
documento XML, y añade nuevas opciones para el movimiento en la representación
serializada del documento XML hacia atrás. Esta es una aportación de esta Tesis
Doctoral que se implementa mediante método que recorren el documento XML en la
forma de estructura jerárquica que contiene una representación natural de un documento
XML.
La extensión del modelo Pull a todo el documento implica, que se podrá acceder
mediante algún mecanismo a todo el documento. En esta línea, el direccionamiento de
una única estructura puede representar una solución óptima. La capacidad de acceso a
todo el el documento permite un mantenimiento de la información en su formato nativo,
y mediante su direccionamiento, se pemita el acceso a la información, a fín de eliminar
su duplicidad.
El mantener disponible un acceso al flujo de datos de entrada del analizador
disponible para todo el documento, permite en un análisis, en el lugar en el que los datos
se han encontrado, lo que se conoce como “in-situ”. La generación de objetos se puede
realizar manteniendo los datos sobre los que se realiza el análisis de la información, sin
realizar copia de toda la información. Los datos pueden ser devueltos generando objetos
desde la propia representación del documento.
La extensión de la interfaz Pull a todo el documento, que denominamos Pulleverything, y DOM permiten el acceso a la información de todo el documento XML. Se
presenta por tanto, un modelo basado en los eventos, donde extiende el modelo Pull con
movimiento del cursor hacia atrás, pudiendo acceder a información previamente
analizada. Se puede decir, por tanto, que los analizadores Pull implementan
parcialmente la interfaz Pull-everything.
La extensión de la interfaz Pull a eventos en la parte del cliente, dan a éste un
mayor control ampliando el rango de aplicación de un analizador XML. Existe una
mayor interacción entre el cliente y el analizador, y es el cliente el que determina la
operación a realizar. Pull-everything da la posibilidad de hacer partícipe al cliente (o
consumidor) en el proceso de análisis pudiendo recrearse en la representación del
documento XML, permitiendo el acceso al documento según el criterio del cliente, y
68
Contribución al análisis XML para la mejora en las prestaciones de memoria.
permitiendo una forma fácil de analizar la información in-situ, y sin la copia de los
elementos de información de los datos XML para la generación de los objetos devueltos
a la aplicación.
La representación serializada de todo el documento XML permite la movilidad del
elemento utilizado para extraer la información (el cursor), para proporcionarla a la
aplicación. Esto ha permitido a la implementación realizada, Free Cursor Mobility,
implementar las nuevas operaciones que se especifican en los siguientes apartados.
Free Cursor Mobility, extiende el modelo Pull a todo el documento, permite generar
eventos desde el punto en el que el cursor obtiene los datos en la representación
serializada. Este elemento (el cursor) se asocia a la información que, bajo petición,
puede proporcionar los modelos basados en eventos.
2.2 Análisis in-situ
En el análisis léxico para la generación de compiladores en C, Holub apunta [Holub 90]
que muchos compiladores utilizan una gran parte del tiempo en la fase de análisis
léxico. Consecuentemente, vale la pena optimizar el análisis léxico para tener mayor
velocidad. En el estándar C, el bufferado del sistema de entrada en la actualidad es una
elección pobre por varias razones. Primero, muchos sistemas “bufferan” copian de la
entrada de caracteres al menos tres veces antes que el programa los utilice: desde el
disco al buffer que mantiene el sistema operativo, desde este buffer a un segundo buffer
que es parte de la estructura FILE, y finalmente desde el buffer de FILE a la cadena de
caracteres que pertenece al lexema. Todas estas copias ocupan tiempo y espacio de
memoria. Además el tamaño no es óptimo. Se puede leer desde el disco una vez, para
que se ejecuten más rápido estas rutinas (sin embargo esto es dependiente del sistema
operativo, no existe ninguna ventaja bajo UNIX durante la lectura de más de un bloque
a la vez; MS-DOS, sin embargo, su funcionamiento es mucho mejor con lecturas de
gran tamaño).
La información que se puede mantener para la ejecución de una aplicación
habitualmente es bastante menor que la memoria de almacenamiento en la que se
soporta. Están pensadas para realizar operaciones diferentes y tienen carácterísticas
diferentes. Pero una aplicación en gran parte de los casos necesita tener la posibilidad de
acceder en cualquier momento a ella. Por ejemplo, en la pantalla de un dispositivo se
presenta una pequeña cantidad de información, mientras que se puede actualizar la
pantalla y poder acceder al resto de la información.
Este problema no es nuevo, durante la implementación de los Sistemas Operativos
se han presentado diferentes técnicas de paginado de la información (swap) a fin de
poder optimizar el acceso a los datos para poder manejar en un entorno donde la
Capítulo 3. Modelo propuesto.
69
cantidad de información que se maneja es mayor que el tamaño de la memoria para
poder mantenerla.
XML representa el nivel más bajo en el nivel de aplicación. DOM. presupone el
acceso a toda la información, a diferencia de los modelos basados en eventos que no
parte de esta hipótesis. Esto no rompe con la idea del paginado (o swap) sobre la que se
asientan los programas que se ejecutan en los Sistemas Operativos, pero a nivel de
aplicación estas consideraciones pueden resultar engorrosas o molestas, y por tanto, una
posible implementación sea la carga de todo el documento XML.
in-situ parsing parte de la idea de que no va a realizar una duplicacacón la
información sino que la va a direccionar, a fín de no duplicar información.
En el caso de un dispositivo móvil la información se debe descargar de forma
completa y rápida en alguna estructura, son requisitos del buen funcionamiento para
aplicaciones que utilicen flujos de red, manteniendo al menos una estructura. Esta
información vendrá condificada en algún esquema de codificación, aunque los lenguajes
de programación suelen trabajar con su propio esquema, para manejar las cadenas de
texto. El lenguaje de programación C mantiene caracteres de 8 bits. El lenguaje de
programción Java trabaja con caracteres de 16 bits.
El tamaño de la memoria utilizada durante la ejecución de un programa puede verse
agrabado dependiendo de la metodología utilizada en programación. Para lenguajes de
programación orientados a objetos, y más concretamente en el lenguaje de programación
Java, puede utilizar una tabla donde mantener la información leida de un flujo
(habitualmente un fichero) esta operación la realizan los flujos del tipo Buffered. Estos
flujos han desaparecido en la plataforma Java ME, representan un uso excesivo en
memoria.
El lenguaje de programación Java es un lenguaje de programación de alto nivel. Se
pueden desarrollar aplicaciones de forma rápida y eficiente con un coste en tiempo
considerablemente pequeño. Representa además un punto de convergencia entre
programadores en cuanto a la sintaxis de código. Este alto nivel hace que puedan tratar
los elementos que representan las cadenas de caracteres de una forma altamente
eficiente. El engorroso y problemático tratamiento que proporcionan lenguajes de
programación de más bajo nivel (como C) para el manejo y tratamiento de las cadenas
de texto, hace que se vea a Java como un cierto alivio en la comparación. La
concatenación, sustitución manejo es más rápido y eficiente para el programador, pero
representa un coste añadido para la aplicación. Cuando se realiza un concatenación de
dos objetos de tipo String se realiza la conversión a otros objetos de tipo
StringBuffer y su posterior conversión a objeto de tipo String, y todo esto
transparente al programador. Pero el precio a pagar es en cuanto a la memoria utilizada
que además no es controlable ya que no se contrala el garbage collector.
70
Contribución al análisis XML para la mejora en las prestaciones de memoria.
La información XML, procedente de un documento o de la red, se utiliza para
construir un formato que proporcione datos en un foramto en serie para entregarlos al
analizador, para manejar una estructura de datos de la que poder extraer la información,
esta es la representación serializada. El proceso habitual es el copiar de la red o del
documento en primer lugar, y luego reconstruir una representación. La representación
serializada de un documento puede coincidir con la fuente de datos virtual, aunque en la
mayor parte de los analizadores esta coincidencia no se produce.
Si coinciden la representación serializada y la fuente de datos virtual se minimiza la
memoria utilizada para el análisis de un documento XML. Esta optimización es
especialmente útil en los entornos en los que el uso de memoria puede ser crítico.
En el análisis de la información in-situ, la información se gestiona en el lugar en
que los datos están almacenados.
Si no se realiza un análisis en el lugar donde está la información, es necesiario
manejar la información mediante algún otro mecanismo, esto es, mediante copia de la
información, y mantener al menos la información relevante o con un significado
especial para la aplicación. Este análisis de la información se conoce como copia de
datos (“data-copying”), y es un proceso habitual tanto en las operaciones que realiza
cualquier lenguaje de programación y como en las aplicaciones realizadas.
Análisis “in-situ” de los datos XML deja la información en la posición o dispositivo
desde donde fue proporcionada al analizador XML, en lugar de copiarla en el
analizador. Un analizador in-situ analiza los datos a su cliente referenciándolos en los
datos originales en lugar de proporcionarlos con una copia para el cliente.
Los datos originales pueden estar en un sistema de ficheros, en una base de datos,
en un buffer “leído”, en una “plataforma” de memoria (un mensaje de texto en tu
teléfono), en un buffer de un editor de texto (en memoria o paginado), en una estructura
de datos del cliente.
Análisis in-situ tiene las siguientes ventajas,
Es poco disperso en el uso de la memoria local, lo cual es importante donde
la memoria local es pequeña (como por ejemplo el teléfono celular) o los
documentos analizados sean grandes (construyendo una base de datos).
Soporta el formato nativo de codificación de la aplicación. Como por
ejemplo, un editor de texto que use XML para la representación interna de
un documento.
In-situ es más potente que la copia de los datos. En el proceso de análisis de los
documentos XML, resulta más cómodo para un programador realizar copia de datos,
aunque el uso de memoria es mayor. Los analizadores XML que usan una copia de los
datos de la fuente de la información XML, habitualmente construyen objetos para su
procesamiento y análisis.
Capítulo 3. Modelo propuesto.
71
Los analizadores in-situ, en la medida de lo posible, indican donde los datos fueron
encontrados. Estos analizadores utilizan elementos que puedan representar la posición
donde la información está ubicada. Estos elementos son referencias como elemento que
contiene una dirección. Los punteros son un tipo de referencias que permiten un acceso
rápido y eficiente a la información contenida en la estructura referenciada.
El análisis in-situ que se puede realizar en una implementación para la plataforma
Java ME sin un sistema de archivos donde mantener la información puede ser de un
archivo descargado a través de un flujo de comunicaciones, como por ejemplo HTTP,
manteniendo una única copia del documento. En un entorno con un sistema de archivos
debería de poder direccionar toda la información relevante, total o parcialmente, a fin de
poder devolverla a la aplicación. Para poder manejar de forma eficente un análisis insitu hace falta algún tipo de direccionamiento, o mantenimiento del lugar donde se
almacena la información.
2.3 Funcionamiento del nuevo modelo
Free Cursor Mobility (FCM) es una implementación del nuevo modelo para la
plataforma Java sobre dispositivos móviles (Java ME), que implementa las nuevas
operaciones que permite extender la interfaz Pull a Pull-everything. Es por tanto, un
analizador basado en eventos.
FCM mantiene el formato serializado de todo el documento XML, permitiendo
manipularlo a demanda de la aplicación, con el objetivo de optimizar la memoria
utilizada durante la ejecución del programa.
Se fundamenta en la idea del cursor del modelo de la implementación StAX pero
mantiene el formato serializado de todo el documento, pudiendo mover el cursor hacia
adelante como en Push y Pull, y hacia atrás. Estas operaciones requieren nuevos
métodos para su uso.
En la Figura 3.30 se muestra el funcionamiento del analizador FCM. Esta figura
muestra el proceso análisis del documento XML, libros.xml, del capítulo anterior
para la extracción de la información. Esta figura se puede contrastar con las Figuras 2.8,
2.11, y 2.18 del capítulo anterior. Dichas figuras representan de forma gráfica la
estructura de un árbol DOM, la forma en la que SAX entrega un documento a una
aplicación como una secuencia de eventos y el funcionamiento del modelo Pull,
respectivamente. La Figura 3.30 muestra el funcionamiento de FCM, donde el
analizador permite el movimiento no sólo hacia adelante (como en Push y Pull) sino
también hacia atrás.
72
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Aplicación
Analizador
FCM
libros.xml
START_ELEMENT“titulo”
CHARACTERS
END_ELEMENT “titulo”
Lectura bajo petición
Movimiento del cursor
next()
next()Imprime titulo
next()
Pide el evento
Figura 3.30: Funcionamiento del modelo Pull-everything de FCM.
La potencia del analizador FCM, es permitir el movimiento del cursor “hacia atrás”,
extendiendo los eventos a todo el documento XML (Pull-everything). Estas operaciones
están soportadas mediante métodos de eficiente implementación para minimizar el uso
de la memoria utilizada durante el análisis.
El nuevo modelo está basado en el uso de referencias para almacenar la información
de los documentos XML sin transformación del esquema de codificación. Se puede usar
los métodos del iterador (next() y hasNext()) al igual que el modelo Pull, pero usa
referencias a la información leída, y estas se puede devolver.
InputStream
input;
//...
XMLFCMReader
r
= new XMLFCMReader();
r.parse(input ,input.available());
boolean isTitle = false;
while(r.hasNext()) {
int evento = r.next();
switch(evento){
case XMLFCMConstants.START_ELEMENT:
if((r.getLocalName()).equals("titulo"))
isTitle = true;
break;
case XMLFCMConstants.CHARACTERS:
if(isTitle)
System.out.println("El titulo del libro es:"
+r.getText());
break;
case XMLFCMConstants.END_ELEMENT:
if((r.getLocalName()).equals("titulo"))
isTitle = false;
break;
}
Capítulo 3. Modelo propuesto.
73
}
Figura 3.31: Funcionamiento del analizador FCM.
2.4 Soporte de las nuevas operaciones
El modelo FCM ofrece nuevas posibilidades sobre el análisis Pull, que son soportadas
por nuevos métodos. Estas operaciones están relacionadas con la configuración del
cursor a secciones de datos XML previamente analizadas.
Los nuevos métodos son los siguientes:
public void setCursorToPreviousSibling(), que configura el valor del cursor
al hermano previo de un determnado elemento,
public void setCursorToParent(), que configura el cursor al padre de un
determinado elemento, lo tuviera.
public void setCursorToRoot(), que configura el cursor al nodo raíz de toda
la estructura.
FCM proporciona los correspondientes métodos con resultado de tipo booleano:
public boolean hasPreviousSibling(), que devuleve un valor cierto (true) si
el elemento en el cual está en un determinado momento tiene hermano
previo.
public boolean hasParent (), que devuleve un valor cierto (true) si el
elemento no es el elemento raíz.
Un método para saltar hacia delante secciones del documento XML sin realizar
análisis de él,
public void skipWithoutParseChilds() , que permite saltar subsecciones del
documento XML. Este método sitúa el cursor al final de un elemento,
saltando todos los hijos que pudiera tener. Este método presenta unas
características excelentes en cuanto a que no instancia objetos, por lo que no
consume memoria.
En una implementación de un sistema conducido por eventos para el análisis de
documentos XML se permite el acceso a modo de flujo a la representación serializada
de los datos XML, mediante un cursor, como un elemento que puede moverse a lo largo
de dicha representación. Los analizadores XML basados en eventos que implementan
FCM leen la información apuntada por el cursor en los datos XML para generar los
distintos eventos usando el modelo de eventos pull, usando el patrón de diseño de un
iterador. Para mover hacia atrás el cursor se pueden usar los métodos
setCursorToParent()
y
setCursorToPreviousSibling()
(bajo
petición), que mueven hacia atrás el cursor en los datos XML. Estas operaciones se
muestran en la Figura 3.32.
74
Contribución al análisis XML para la mejora en las prestaciones de memoria.
En esta figura se representa en ejemplo simple de un documento XML, en la que se
ha obtenido la representación serializada. Utilizando esta representación el cursor puede
extraer a información. Los valores del cursor apuntan a la representación serializada de
los datos XML para permitir el análisis de la información. Los métodos next() y
skiptWithoutParseChilds() permiten realizar un movimiento hacia delante en
el
proceso
de
análisis.
Los
métodos
setCursorToParent()
y
setCursorToPreviousSibling() permiten el moviento hacia atrás del cursor
en el proceso de análisis.
<el>Romeo</el><conj>and</conj><ella>Julieta<
setCursorToParent()
setCursorToPreviousSibling()
analizador
eventos
next()
skiptWithoutParsingChilds()
Métodos
del analizador
aplicación
Figura 3.32: Funcionamiento del analizador FCM.
<?xml version=“1.0” ?>
<root>
<lovers>
<el>Romero</el>
En el modelo productor y consumidor de FCM, la aplicación<conj>and</conj>
llama al analizador
<ella>Julieta</ ella >
para obtener el siguiente evento, o para realizar el movimiento hacia
delante o hacia
</lovers>
<sentence>
atrás del cursor. Con hasNext() y next() la aplicación puede tener
conocimiento de si
Enamorados
existe algún evento y la posibilidad de tomarlo, respectivamente. </sentence>
</root>
2.5 El modelo productor y consumidor
La aplicación puede gestionar el evento bajo petición de la aplicación en el papel de
director, y capturar el evento en el role de consumidor del evento, tal y como se puede
ver en la Figura 3.33.
En el role de director, la aplicación puede mover hacia delante y hacia atrás el
cursor a lo largo de la representación serializada de los datos XML.
En el papel de director, la aplicación, puede mover hacia delante o hacia atrás el
cursor en la representación serializada de los datos XML. Con next() la aplicación
mueve el cursor hacia delante, con setCursorToParent()/setCursorToPreviousSibling()
la aplicación mueve el cursro hacia atrás.
Capítulo 3. Modelo propuesto.
Productor
Mueve
el cursor
adelante
o atrás
analizador
datos
XML
boolean hasNext ()
boolean hasPreviousBrother ()
true
Consumidor
int next()
void skipWithoutParsingChilds()
aplicación
75
START_DOCUMENT / START_ELEMENT, ...
Figura 3.33: Productor/Consumidor en FCM.
El funcionamiento de FCM da un control basado en procedimiento, permitiendo
pararlo, o recrear subsecciones de los datos XML.
La Figura 3.33 se puede comparar con las Figuras 2.23, 2.17 y 2.10 del capítulo
anterior.
2.6 Ejemplo de utilización
Este sistema conducido por eventos que toma los datos de la representación
serializada para generar los eventos para notificarlos a la aplicación puede mostrarse un
ejemplo de uso en la siguiente figura.
Algunos de los eventos que se pueden capturar son los siguientes
START_ELEMENT, START_DOCUMENT, ... que están especificados en la interfaz
XMLFCMConstants (más detalles de esta interfaz aparecen en el capítulo siguiente).
boolean flag1 = true;
boolean flag2 = true;
while (in.hasNext()){
evento = in.next();
if(evento == XMLFCMConstants.START_ELEMENT){
if((in.getLocalName()).equals("Header")&& flag1){
in.skipWithoutParseChilds();
flag1 = false;
}
if((in.getLocalName()).equals("Fault") && flag2){
in.setCursorToFather();
if(in.hasPreviousSibling()){
in.setCursorToPreviousSibling();
flag2 = false;
}
}
}
76
Contribución al análisis XML para la mejora en las prestaciones de memoria.
}
Figura 3.34: Ejemplo de ejecución en FCM.
En el ejemplo de la figura de arriba se ponen de manifiesto los siguientes puntos:
1 El patrón iterativo se realiza mediante un bucle del tipo while.
2 Los métodos hastNext()/next() del iterador, que comprueba si existe
3
algún evento y lo obtiene, respectivamente. El uso de estos métodos supone el
movimiento del cursor hacia delante.
La captua de los eventos obtenidos con el método next(), en este caso el
único evento capturado es XMLFCMConstants.START_ELEMENT, que
indica el comienzo de un elemento y que pertence a la interfaz
XMLFCMConstants (los detalles de la interfaz están especificados en el
4
capítulo siguiente, relacionado con la implementación).
El
uso
de
los
métodos
setCursorToParent()
y
setCursorToPreviousSibling(), que representan el movimiento del
cursor hacia atrás.
En este ejemplo la llamada al método in.skipWithoutParseChilds(),
realiza un movimiento del cursor hacia delante en la representación serializada.
Cuando se usa el movimiento del cursor hacia atrás es posible que se necesite
variables de control, ya que el cursor volverá a encontrarse la misma condición con la
que realizó el movimiento del cursor hacia atrás.
3 Aplicación del Modelo propuesto a Java ME.
Este apartado se presenta una aplicación del modelo propuesto a la plataforma Java
J2ME. Esta implemenación utiliza Pull extendiéndolo a todo el documento XML
realizando análisis in-situ. La implementación trabajo con el cursor como elemento que
permite el movimiento sobre la representación serializada, y se conocida como Free
Cursor Mobility (FCM).
3.1 Introducción
En los últimos años, Sun y las principales compañías de dispositivos de consumo han
colaborado en crear un entorno de desarrollo de aplicaciones Java para pequeños
dispositivos de memoria, altamente portable con recursos limitados tales como teléfonos
celulares, buscapersonas y asistentes personales.
Este trabajo comenzó con el desarrollo de una nueva, pequeña máquina virtual de
Java llamada KVM. Dos esfuerzos de estandarizaciónn en el Java Community Process
(JCP), Connected Limited Device Configuration (CLDC) y Mobile Information Device
Profile (MIDP), se han realizado para estandarizar las librerías de Java y asociarlas la
lenguaje Java y las características de la máquina virtual a lo largo de una gran variedad
Capítulo 3. Modelo propuesto.
77
de dispositivos de consumo. Los estándares CLDC y MIDP son una parte clave de la
Java™ 2 Platform, Micro Edition (J2ME™).
Una configuración de la plataforma J2ME especifica el subconjunto del lenguaje de
programación Java, el subconjunto de funcionalidades de la configuración de la
máquina virtual, las características de seguridad y las características de red, así como las
librerías en el núcleo de la plataforma, para soportar un amplio rango de productos de
consumo. CLDC es la base para uno o más perfiles. Un perfil de la plataforma J2ME
define un conjunto adicional de APIs y características para un concreto mercado
vertical, categoría de dispositivo o industria, tal y como se ha detallado en el capítulo
anterior.
En este contexto de Java ME y para una configuración CLDC válida desde la
versión 1.0 se presenta la implementación del modelo de análisis de documentos XML
basado en el movimiento libre del cursor (FCM).
El análisis con Streaming API for XML (StAX) [JSR-173] especifica una API para
XML es un análisis pull, implementada con un iterador, escrita en el lenguaje Java.
StAX se implementó para dar soporte a Data Binding (JAXB) [JSR-101] y la llamada a
procedimiento remoto (JAX-RPC) [JSR-173].
JAXB y JAX-RPC necesitan de una XML Streaming API. StAX hace que este tipo
de código sea mucho más natural de escribirlo que con SAX, y mucho más eficiente que
DOM. StAX desarrolla una APIs y las normas que soporten el procesamiento XML
como un flujo. La especificación se dirije principalmente a tres áreas:
1 Desarrollo de áreas y convenios que permitan a un usuario analizar eventos Pull de
un flujo de entrada XML.
2 Desarrollar un API que permita a un usuario escribir eventos a un flujo de salida
XML.
3 Desarrollo de un conjunto de objetos e interfaces que encapsulen la información
contenida en un flujo XML.
La especificación debería ser fácil de usar, eficiente, y que no requiera una
gramática. Debería de inclluir soporte para espacio de nombre y la construcción de
XML asociada.
En las desventajas de esta especificación incluye:
1 La especificación de una API de validación. La validación se realizará en la capa
encima del analizador. Esto no descarta el análisis de parámetros de validación para
un analizador subyacente.
2 Dependencia especifica de una gramática XML.
3 Soporte para aplicaciones que transforme o editen una DTD.
La implementación realizada de FCM está basada en la StAX, su especificación en
determina la sección 4.12, que cataloga como no normativa, el subconjunto que debería
78
Contribución al análisis XML para la mejora en las prestaciones de memoria.
ser suficiente para una implementación sobre la plataforma J2ME. La forma en la cual
se crea una instancia bajo la J2ME no está definida.
3.2 Subconjunto mínimo para la implementación
La especificación JSR.173 determina un subconjunto de clases suficiente para un
analizador XML para la plataforma J2ME.
Esta subconjunto es el siguiente:
1 Clases:
javax.xml.stream.XMLStreamReader
javax.xml.stream.XMLStreamWriter
javax.xml.stream.XMLStreamException
javax.xml.stream.Location
javax.xml.stream.XMLStreamConstants
2
Clases/interfaces:
javax.xml.namespace.QName
javax.xml.namespace.NamespaceContext
javax.xml.XMLConstants
Estas clases se han tomado como referencia para la implementación. Los métodos
de cada una de las clases están especificados en los javadoc que se proporciona en
[StAX javadoc].
3.3 Los datos XML
El nuevo modelo puede usar valores del cursor para acceder a la información
previamente analizada. StAX diferencia entre Virtual Data Source, que son los datos
XML almacenados, pero no necesariamente en su formato de representación serializada.
Un requisito de este modelo es la necesidad de mantener una representación
serializada de todos los datos XML para poder mover el cursor. En un entorno de la
plataforma J2ME con la configuración CLDC, sin un sistema de fichero para leer o
mantener los datos XML, la información debería ser descargada de la red. Por ejemplo,
a través de una conexión HTTP. Estos datos deberían almacenarse en una estructura
para su posterior procesamiento y análisis. La información procedente de la red debería
ser salvada en cualquier estructura rápidamente.
Para optimizar la memoria, sería deseable no redimensionar ninguna estructura. Por
lo tanto es necesario conocer el tamamño de la estructura en la que se van a ubicar todos
los datos. Todo el proceso dedetección del esquema de codificación y dimensionado de
las estructura se desarrolla en los siguientes puntos.
Capítulo 3. Modelo propuesto.
79
3.3.1 Detección del Esquema de codificación
De acuerdo con la recomendación XML, todos los analizadores deberían aceptar los
esquemas de codificación UTF-8 y UTF-16 de Unicode. También da en una sección no
normativa la autodetección de los esquemas de codificación, entre los cuales se incluyen
UCS-4 con sus 4 variantes, y los dos tipos de UTF-16. En todos estos casos puede tener
la presentacia o ausencia de Byte Order Mark (BOM).
Según la recomendación, cada entidad XML no va acompañada de una entidad
externa de información, y un documento XML no tiene que comenzar con la declaración
del esquema de codificación indicando que sea, o bien UTF-8, o UTF-16; sino que los
primeros caracteres deberían ser '<?xml'. Cualquier procesador puede detectar, después
de dos o cuatro octetos de entrada, cual es el esquema de codificación utilizado.
Leyendo esta secuencia, nos podría ayudar a conocer en UCS-4, '<' es "#x0000003C"
y '?' es "#x0000003F", y el Byte Order Mark requerido para un flujo de datos UTF16 es “#xFEFF”.
Teniendo en cuenta estas consideraciones en la lectura de los bytes previos para
determinar el esquema de codificación utilizado en el documento XML, la
implementación realizada da soporte a UTF-8, UTF-16BE, UTF-16LE, y UCS-4 en sus
cuatro versiones, tal y como se especifica en la recomendación XML.
3.3.2 Tamaño de la Estructura
HTTP contiene una cabecera indicando la longitud (Content-Length). Utilizando las
clases de la plataforma J2ME para el uso HTTP se puede obtener la longitud. Si la
longitud no se proporciona, esto sucede si el valor de getLength() devuelve-1, se
puede estimar una longitud.
Si conocemos es esquema de codificación y también el tamaño de los datos
(obtenido con el método getLength()), entonces se puede estimar el tamaño de una
estructura compacta para gestionar los datos XML, que hecho de esta forma es la
representación serializada.
3.3.3 ¿Qué estructura?
La clase StringBuffer tiene un constructor con un argumento entero para
configurar un array interno de caracteres a una capacidad inicial. La estructura interna de
un StringBuffer es un tabla de char, donde el tipo de datos char tiene 16 bits.
En esta estructura se insertan los datos obtenidos del flujo de entrada HTTP. Los
datos se “reconstruyen” del flujo para insertarlos en la estructura según el esquema de
codificación que utilizen.
80
Contribución al análisis XML para la mejora en las prestaciones de memoria.
En la codificación de caracteres basada en 8 bits, como por ejemplo la de ISO8859-x, UTF-8, ASCII o cualquier otro de 7 bit u 8 bit no utilizan el byte superior en
todos los caracteres de la tabla interna que mantiene la estructura StringBuffer.
En la codificación de caracteres basada en 32 bits, como UCS-4 necesita una
transformación para poder representarlo en las unidades de 16 bits. Esta transformación
no presentan como lineas de continuación en el capítulo final.
Mediante un objeto de tipo StringBuffer se puede crear un objeto String.
Cuando se crea un String con un objeto de tipo StringBuffer, el String apunta a
la misma tabla de caracteres. String tienen un “status” especial en Java y tienen método
nativos para oerar que proporcionan una rápida ejecución.
3.4 Documentos XML “bien formados” (well-formed)
La Recomendación del W3C de XML 1.1 dice que “la restricción de bien formado es
por definición una regla que se aplica a todo documento XML bien formado.
Violaciones de bién formado deben ser errores fatales”.
¿Cómo podemos implementar una estructura para comprobar que un documento
XML está bien formado? Una primera implementación puede hacerse con los datos
XML que se extraen de la representación serializada para crear objetos de tipo String
que se almacenan en un tabla de de objetos de tipo String. Esta situación se ilustra en
la Figura 3.35.
Analizador
String[]
Representación Serializada
...
conj
lovers
root
conj
cursor
<root><lovers><el>Romeo</el><conj>y</conj><ella>Julieta<
Figura 3.35: Estructura que puede dar soporte a un documento bien formado.
En esta figura se puede observar que un objeto de tipo String se inserta en la matriz
incrementando el número de elementos utilizados, quedando el resto libre. El número de
elementos de la estructura es finito el tamaño se puede sobrepasar, necesitando
comprobar en cada inserción el tamaño de la estructura, y si se produjera
desbordamiento de los límites de la matriz se debería usar el método
System.arraycopy debiendo crear una estructura mayor previamente, para pode
copiarla.
Capítulo 3. Modelo propuesto.
81
3.5 Estructura para la implementación de “bien formado” en FCM
Opuesto al modelo de datos que contienen la información, una referencia es un objeto
pequeño que contiene información que se refiere a datos que están en otro lugar. Las
referencias incrementan la flexibilidad en donde la informción se puede almacenar,
como las referencias se sitúan, y se pasan entre áreas de código.
Cuando se desee acceder a cualquier dato mediante una referencia se puede realizar.
Los punteros son los más poderosos y eficientes tipos de referencias, almacenando sólo
la dirección de un objeto en memoria. El mecanismo de referencias, puede variar según
la implmentación, esta es una carácterística fundamental del lenguage de programación
común a todos los lenguajes de programción modernos. En Java una referencia genérica
para toda clase de objetos se declara mediante Object. Los elementos se podrían insertar
en un array usado como pila (new Object[TAM]). Un elemento contendría
información relacionada con la posición del cursor al comienzo del elemento.
En la Figura 3.36 se observa que cualquier objeto es insertardo en la matriz
incrementando la profundidad, al igual que en el caso anterior se puede desbordar el
tamaño del array.
Analizador
Object[]
Representación
Serializada
cursor
<root><lovers><el>Romeo</el><conj>y</conj><ella>Julieta<
Figura 3.36: Estructura alternativa para dar soporte a un documento bien formado.
Y si esa situación se produjera se debería de redimensionar en la misma forma en la
que se ha especificado en el caso anterior. A diferencia del apartado anterior se utilizan
elementos que contengan un direccionamiento de la representación serializada del
documento XML, en lugar de extraerlo e insertarlo en la matriz.
3.6 Otra posible representación para dar soporte en FCM
En la siguiente Figura se presenta otra posible opción, para dar soporte a la
comprobación de que un documento XML esté bien formado. Al igual que el caso
anterior en FCM se basa en referencias a la representación serializada de la información
XML. La diferencia con el caso anterior es que utiliza una estructura más escalable, sin
la necesidad de utilizar el método System.arraycopy.
82
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Analizador
cursor
<root><lovers><el>Romeo</el><conj>y</conj><ella>Julieta<
Figura 3.37: Estructura elegida para dar soporte a un documento bien formado en FCM.
Se puede observar en la gráfica como se puede mantener la información para cada
elemento del documento XML, y además es perfectamente escalable. La inserción de
cualquier elemento nuevo se puede realizar sin el redimensionamiento global de toda la
estructura.
Entre la información de cada elemento que se desarrolla en el siguiente apartado
aparece información del cursor para ese elemento.
3.7 Cómo estrurar la información con el uso de referencias
Un elemento puede representarse por un conjunto de referencias, con la que poder tener
una estructura jerárquica de todo el documento XML. Con esta estructura jerárquica se
puede utilizar para organizar toda la información desde el primer elemento (el elemento
raíz) hacia cualquier otro elemento.
En la Figura 3.38 se puede observar como un elemento se caracteriza por un array
de referencias.
Otra información (Opcional)
Referencia al hijo del elemento
Referencia al padre del elemento
Referencia al hermano
Cursor del elemento
Figura 3.38: Referencias de un elemento.
Las referencias de un elemento son las siguientes:
Una referencia al padre (si corresponde), el elemento raíz es un caso
especial, no tiene padre.
Una referencia al hermano. Un elemento puede tener un hermano. Si el
elemento tiene un hermano la referencia correspondiente al hermano debería
contener el valor. El elemento raíz no puede tener hermanos.
Una referencia al hijo. Se puede acceder a un hijo de este elemento con una
referencia al hijo.
Capítulo 3. Modelo propuesto.
83
El cursor al comienzo de este elemento. Se necesita un valor que represente
el cursor al comienzo del elemento. Este valor permite que mediante el
“movimiento” en la estructura jerárquica permita el acceso a elementos
anteriores.
Mediante estas referencias se puede caracterizar un elemento y se puede actualizar
la posición actual del cursor con los datos previamente analizados, usando las
referencias de los elementos.
Fa Figura 3.39 muestra la estructura jerárquica que se puede crear para hacer
referencia a la estructura de un documento.
padre
elemento
hijo
…
hermano
Referencia al hijo del elemento
Referencia al padre del elemento
Referencia al hermano
Cursor for this element
…
Figura 3.39: Uso de referencias para representar un elemento.
3.8 La Interfaz XMLFCMConstants
FCM es una implementación del nuevo método análisis de documentos XML basado en
eventos para la J2ME. Los eventos se producen bajo demanda del consumidor siguiendo
un patrón iterativo. Este patrón en cada paso devuelve un valor entero relacionado con
el evento producido.
Los valores devueltos se asocian con los eventos especificados en la interfaz
XMLFCMConstants.
La implementación StAX reserva los valores enteros en el rango de 0 a 256 para
este propósito, pudiendo el usuario definir nuevos eventos fuera de este rango.
En la Figura 3.40 se presentan los eventos soportados por la implementación FCM
para el manejo por parte de la aplicación.
XMLFCMConstants.START_ELEMENT
XMLFCMConstants.START_DOCUMENT
XMLFCMConstants.END_ELEMENT
XMLFCMConstants.PROCESSING_INSTRUCTION
XMLFCMConstants.CHARACTERS
XMLFCMConstants.SPACE
84
Contribución al análisis XML para la mejora en las prestaciones de memoria.
XMLFCMConstants.END_DOCUMENT
XMLFCMConstants.ATTRIBUTE
XMLFCMConstants.DTD
XMLFCMConstants.CDATA
XMLFCMConstants.NAMESPACE
Figura 3.40: Elementos de la interfaz XMLFCMConstants.
3.9 Otras características de la implementación
Existen otras características de la implementación que las detallo en los siguientes
puntos:
o El tamaño de la implementación es de un archivo jar de 21.5 KB. Este tamaño
es sin ofuscación.
o El analizador implementado es una API bidireccional. La bidireccionalidad se
realiza debido a las clases
o XMLFCMReader para realizar el proceso de lectura del documento y
o XMLFCMWriter, que permite escribir un documento XML a través de un
flujo.
o No soporta validación ni contra un XML Schema ni contra una DTD. Pero las
DTD se devuelven como String.
o Soporte para nombres cualificados. Se implementa la clase QName, para este
propósito. Los nombres cualificados siguen la especificación XML Schema
Part2:
Datatypes
specification[Schema
04],
y
Namespaces
in
XML[Namespaces].
o Todas las clases del paquete com.sierra.io, están relacionadas con las
operaciones de lectura y escritura del flujo. Estas clases son nuevas en relación
a la implementación JSR-173. Son las siguientes:
o Perteneciente al paquete io:
ArrayInputStream
XMLReader
XMLWriter
o Perteneciente al paquete com.sierra.io.i18n:
ReaderUCS4
ReaderUTF16
ReaderUTF8
WriterUCS4
WriterUTF16
WriterUTF8
Capítulo 3. Modelo propuesto.
85
La Figura 3.41 muestra las representación de las clases de la implementación en una
estructura arbórea para la representación de los ficheros contenidos en los directorios,
\---com
\---sierra
+---io
|
|
ArrayInputStream.java
|
|
XMLReader.java
|
|
XMLWriter.java
|
|
|
\---i18n
|
ReaderUCS4.java
|
ReaderUTF16.java
|
ReaderUTF8.java
|
WriterUCS4.java
|
WriterUTF16.java
|
WriterUTF8.java
|
\---xml
|
XMLConstants.java
|
+---fcm
|
Location.java
|
XMLFCMConstants.java
|
XMLFCMException.java
|
XMLFCMReader.java
|
XMLFCMWriter.java
|
\---namespace
NamespaceContext.java
QName.java
Figura 3.41: Clases de la implementación.
Los métodos públicos que están contenidas en las clases de la implementación
realizada se muestran en la Figura 3.42.
86
Contribución al análisis XML para la mejora en las prestaciones de memoria.
XMLFCMReader
XMLFCMWriter
QName
+close()
+flush()
+getNamespaceContext()
+getPrefix()
+getProperty()
+setDefaultNamespace()
+setNamespaceContext()
+setPrefix()
+writeAttribute()
+writeCData()
+writeCharacters()
+writeComment()
+writeDefaultNamespace()
+writeDTD()
+writeEmptyElement()
+writeEmptyElement()
+writeEndDocument()
+writeEndElement()
+writeEntityRef()
+writeNamespace()
+writeProcessingInstruction()
+writeProcessingInstruction()
+writeStartDocument()
+writeStartElement()
+writeStartElement()
+writeStartElement()
<<interface>>
XMLConstants
<<interface>>
XMLFCMConstants
<<interface>>
NamespaceContext
+getNamespaceURI()
+getPrefix ()
+getPrefixes()
XMLFCMException
<<interface>>
Location
+setCursorToPreviousSibling ()
+setCursorToParent()
+setCursorToRoot()
+hasPreviousSibling()
+hasParent()
+skipWithoutParseChild()
+close()
+getAttributeCount()
+getAttributeLocalName()
+getAttributeName()
+getAttributeNamespace()
+getAttributePrefix()
+getAttributeType()
+getAttributeValue()
+getCharacterEncodingScheme()
+getElementText()
+getEncoding()
+getEventType()
+getLocalName()
+getLocation()
+getName()
+getNamespaceContext()
+getNamespaceCount()
+getNamespacePrefix()
+getNamespaceURI()
+getPIData()
+getPITarget()
+getText()
+getTextCharacters()
+getTextLength()
+getTextStart()
+getVersion()
+hasName()
+hasNext()
+hasText()
+isAttributeSpecified()
+isCharacters()
+isEndElement()
+isStandalone()
+isStartElement()
+isWhiteSpace()
+next()
+nextTag()
Figura 3.42: Diagrama UML de FCM.
Esta figura presenta mediante un diagrama UML los métodos más destacados de la
implementación realizada y se puede comparar con la Figura 2.6, Figura 2.13 y Figura
2.19, del capítulo anterior donde se presenta la jerarquía de interfaces del nivel 2 de
DOM, las interfaces de SAX 2.0, y la API para StAX, respectivamente.
La implementación ha tenido en cuenta el implementar el menor número de clases,
menor número de métodos por clase, menor número de objetos utilizados, a fín de tener
un mejor comportamiento en memoria. Todo ello para hacer un uso menos intensivo de
la memoria en el proceso de análisis de un documento XML.
3.10 Dependencia del estado.
Como ya se ha detallado en el capítulo anterior, a priori, los modelos basados en eventos
requieren menos memoria que los modelos basados en árboles. Si bien se pueden
construir el árbol DOM y recorrerlo siguiendo un orden para generar eventos a partir de
él proporcionando de esta forma una interfaz basada en eventos a partir del árbol DOM.
Push necesita menos carga de procesamiento que el modelo DOM. Push está
orientado hacia un procesamiento independiente del estado, donde los elementos que se
Capítulo 3. Modelo propuesto.
87
manejan no son dependientes de los eventos que se han producido con anterioridad. El
modelo Pull, por otra parte, está orientado hacia un procesamiento dependiente del
estado. En el procesamiento dependiente del estado, el programa (o aplicación) puede
realizar operaciones dependiendo según el estado (o evento) en el que esté (se genere).
Expresado de otra forma, los métodos que se pueden invocar en los modelos Pull
dependerán del evento generado. Esta característica se mantiene para la implementación
realizada y se detalla en la Figura 3.43. En esta figura se presentan las operaciones que
se pueden realizar para todos los estados generados en el análisis del documento.
Operaciones sobre todos los estados
public final boolean hasNext()
public final void close() throws XMLFCMException
public final String getNamespaceURI(String prefix)
public final boolean isStartElement()
public final boolean isEndElement()
public final boolean isCharacters()
public final boolean isWhiteSpace()
public final NamespaceContext getNamespaceContext()
public final int getEventType()
public final Location getLocation()
public final boolean hasText()
public final boolean hasName()
public final void setCursorToRoot()
public final void setCursorToPreviousSibling()
public final void setCursorToParent () throws XMLFCMException
public final boolean hasParent ()
public boolean hasPreviousSibling ()
Figura 3.43: Métodos para todos los estados.
Como se ha indicado anteriormente, hay métodos especificos de un determinado
estado. La Figura 3.44 muestra los métodos que se pueden invocar para los estados:
START_ELEMENT, END_ELEMENT, START_DOCUMENT y END_DOCUMENT.
Estado
START_DOCUMENT
Operaciones sobre el estado
public final int next() throws XMLFCMException
public final String getEncoding()
public final String getVersion()
public boolean isStandalone()
public final boolean standaloneSet()
public final String getCharacterEncodingScheme()
public final int nextTag() throws XMLFCMException
88
Contribución al análisis XML para la mejora en las prestaciones de memoria.
START_ELEMENT
public final int next() throws XMLFCMException
public final QName getName()
public final String getLocalName()
public final boolean hasName()
public final String getPrefix()
getAttributeXXX()
public final boolean isAttributeSpecified(int index)
getNamespaceXXX(),
public final String getElementText()
throws XMLFCMException
public final int nextTag() throws XMLFCMException
END_ELEMENT
public final int next() throws XMLFCMException
public final QName getName()
public final String getLocalName()
public final boolean hasName()
public final String getPrefix()
getNamespaceXXX()
public final int nextTag() throws XMLFCMException
END_DOCUMENT
public final void close() throws XMLFCMException
Figura 3.44: Métodos para todos los estados START_ELEMENT, END_ELEMENT,
START_DOCUMENT y END_DOCUMENT.
La Figura 3.45 presenta los métodos para los estados ATTRIBUTE,
NAMESPACE, PROCESSING_INSTRUCTION, ENTITY_REFERENCE y DTD.
Estados
ATTRIBUTE
Operaciones sobre el estado
public final int next() throws XMLFCMException
public final int nextTag() throws XMLFCMException
getAttributeXXX()
public final boolean isAttributeSpecified(int index)
NAMESPACE
public final int next() throws XMLFCMException
public final int nextTag() throws XMLFCMException
getNamespaceXXX()
PROCESSING_
public final int next() throws XMLFCMException
INSTRUCTION
public final String getPITarget()
public final String getPIData()
public final int nextTag() throws XMLFCMException
ENTITY_
REFERENCE
public final int next() throws XMLFCMException
public final String getLocalName()
public final String getText()
public final int nextTag() throws XMLFCMException
Capítulo 3. Modelo propuesto.
DTD
89
public final int next() throws XMLFCMException
public final String getText()
public final int nextTag() throws XMLFCMException
Figura 3.45: Métodos para todos los estados ATTRIBUTE, NAMESPACE,
PROCESSING_INSTRUCTION, ENTITY_REFERENCE y DTD.
La Figura 3.46 presenta los métodos para los estados ATTRIBUTE,
NAMESPACE, PROCESSING_INSTRUCTION, ENTITY_REFERENCE y DTD.
Estados
SPACE
COMMENT
CDATA
CHARACTERS
Operaciones sobre el estado
public final int next() throws XMLFCMException
XXX getTextXXX(),
public final int nextTag() throws XMLFCMException
Figura 3.46: Métodos para todos los estados SPACE, COMMENT, CDATA y CHARACTERS.
Otros métodos parcialmente especificados anteriormente se detallan en la Figura
3.46.
Metodo
Operaciones sobre el estado
public final NamespaceContext getNamespaceContext()
getNamespaceXXX()
public final int getNamespaceCount()
public final String getNamespacePrefix(int index)
public final String getNamespaceURI(String prefix)
public final String getNamespaceURI(String prefix)
public final int getTextStart()
getTextXXX()
public final String getText()
public final char[] getTextCharacters()
public final int getTextCharacters(int sourceStart,
char[] target,
int targetStart,
int length)
public final int getTextLength()
public final int getAttributeCount()
getAttributeXXX()
public final String getAttributeLocalName(
int index)
public final QName getAttributeName(int index)
public final String getAttributeNamespace(
int index)
public final String getAttributePrefix(int index)
public final String getAttributeValue(int index)
public final String getAttributeValue(
String namespaceURI,
String localName)
90
Contribución al análisis XML para la mejora en las prestaciones de memoria.
Figura 3.47: Otros métodos parcialmente especificados.
4 Conclusiones.
En el presente capítulo se ha presentado el nuevo modelo de análisis de documentos
XML, que propone extender la interfaz Pull a todo el documento, permitiendo realizar
un análisis en el sitio donde se encuentra la información. De esta forma se propone
mantener la representación serializada de la información XML, que podría ser la fuente
de donde provienen los datos, de tal forma que no se necesite una representación arbórea
como con el modelo DOM, y a diferencia de los modelos previos basados en eventos
(Push y Pull) se pueda acceder a toda la información previamente analizada.
o Se introducen los requisitos de partida y la valoración de los modelos de
análisis existentes.
o Se proporcionan las especificaciones de diseño, entre las cuales destacan:
Movimiento del cursor hacia atrás.
Realizar un análisis de la documentación en el lugar donde se
encuentran los datos.
o Describe el funcionamiento básico, así como el modelo de
comportamiento de cada una de los elementos que intervienen en el
modelo productor/consumidor.
o Describe las nuevas operaciones que ofrece el nuevo modelo, FCM.
Dicho modelo proporciona el movimiento del cursor no sólo hacia
delante mediante un proceso de iteración como el modelo Pull, sino que
permite el movimiento de cursor hacia atrás
o El mantener la representación serializada de la información XML hace el
proceso iteración hacia delante pueda realizarse sin el análisis de los
elementos hijos de un cierto elemento mediante el método
skipWithoutParseChilds(), teniendo un control del análisis del
documento XML.
o Se presenta un ejemplo de utilización de FCM, en código Java
La extensión de la interfaz Pull a eventos en la parte del cliente, dan al cliente un
mayor control ampliando el rango de aplicación de un analizador XML. El mantener una
representación serializada de todo el documento permite la posibilidad de generar
eventos al estilo Pull, añadiendo nuevas posibilidades sobre dicho modelo. Los actuales
analizadores del modelo Pull sólo implementan parcialmente una interfaz Pulleverything, y muchos son data-copying. Según como los datos son devueltos, los
analizadores copian toda la información del documento XML en objetos,
devolviéndolos al cliente. Los analizadores in-situ, en la medida de lo posible, indican
donde los datos fueron encontrados en el documento analizado. Según que información
Capítulo 3. Modelo propuesto.
91
es devuelta al cliente, la estructura de los elementos y propiedades, y datos que
contienen la información se puede proporcionar, y los datos que contienen la
información. La información de la entidad externa y la posibilidad del cliente de
participar en la resolución de la entidad.
En este capítulo se ha presentado una implementación Java para el modelo Pull
extendiendo la interfaz Pull a todo el documento. La plataforma de Java, J2ME, es una
plataforma donde se proporcionan unos paquetes obligatorios y unos opcionales debido
a que son dispositivos con recursos limitados, y las aplicaciones sobre esta plataforma
deben de tenerlo presente a la hora de realizar sus implementaciones.
Teniendo en cuenta estos puntos, se ha presentado una implementación de un
analizador XML para la plataforma J2ME.
o Se han detallado las clases mínimas para realizar la implementación.
o Se ha presentado como se realiza la detección del esquema de
codificación que soporta la implementación del nuevo modelo.
o Se analiza qué estructura se utiliza y el tamaño para realizar el
mantenimiento de la representación serializada de la información XML.
o Se presentan modelos válidos para poder implementar la característica de
“bien formados” de los documentos XML, mostrando la opción elegida.
o Se presenta la representación de un elemento dentro de la estructura de
representación de la información XML y de la relación entre los distintos
elementos.
o Se detalla la composición de la interfaz XMLFCMConstant.
o Se especifica la estructura de directorios y las clases contenidas en ellos.
o Se especifica los métodos que se implementan en las clases para el
análisis de los documentos.
En el siguiente capítulo se comprueba cúal es el funcionamiento del modelo, y las
carácterísticas específicas que tiene la implementación realizada.
CAPÍTULO 4.
Análisis Comparativo del Rendimiento del Modelo
En el capítulo previo se ha presentado el modelo propuesto para el análisis XML, con
detalles para la implementación sobre la plataforma Java para dispositivos móviles. Esta
plataforma presenta características específicas en los recursos memoria disponibles. En
este capítulo se presenta las medidas del funcionamiento de la implementación realizada
para el prototipo implementado. Se presenta el funcionamiento del modelo
implementado. Se compara con otros analizadores para la misma plataforma para la que
se ha realizado la implementación del capítulo previo. Se presenta la codificación
soportada por la implementación comparada con otras implementaciones.
1 Introducción
Algunos analizadores XML implementados en el lenguaje de programación Java
inicialmente se diseñaron para uso de aplicaciones para la J2EE/J2SE, entre los cuales
se incluyen los applets de Java, y con algunas modificaciones, se pueden utilizar en la
plataforma J2ME. MIDP es un entorno de recursos limitados. Éstos fueron
originalmente diseñados para la J2SE, y se han modificado para J2ME MIDP y pueden
ejecutarse como MIDlets.
En el entorno de la J2ME MIDP, los desarrolladores deberían constantemente tener
cuidado con la memoria utilizada en su aplicación. Los analizadores XML usados deben
ser de un tamaño de 10KB a 30KB, aunque en algunos casos su tamaño sea menor.
La mayor parte de las pruebas se han realizado sobre el emulador Wireless Toolkit,
la implementación se ha realizado para esta plataforma y las medidas comparativas se
orientan a mostrar los resultados comparativos en esta plataforma. El escenario es un
PC, con el emulador que pide un fichero XML al servidor, el fichero es descargado y
procesado y analizado con la herramienta de prueba. Para evaluar el funcionamiento de
los analizadores se observa la evolución temporal de la memoría utilizada.
Se evalúan los diferente analizadores eligiendolos como representación de los
modelos de análisis vistos en los capítulos previos. El tamaño de los fichero XML es un
parámetro que se cambia para ver el comportamiento de los modelos.
Para evitar la degradación de las medidas de memoria realizadas, la aplicación no
mantiene ninguna estructura de los datos. Los datos se obtienen y se muestran enla
94
Contribución al análisis XML para la mejora en las prestaciones de memoria
pantalla del dispositivo, de esta forma la medida que se obtiene es de la memoria de los
datos XML que utiliza el analizador.
2 Entorno para realizar medidas
El entorno para las medidas del funcionamiento de los analizadores XML en la
plataforma J2ME que se ha utilizado va enfocado a utilizar las capacidades que ofrece el
emulador Wireless Toolkit.
El entorno es, para realizar las medidas del funcionamiento de los analizadores
XML. La mayor parte de las pruebas se han realizado con el siguiente escenario: un PC,
con el emulador que pide un fichero XML al servidor, el fichero es descargado y
procesado. Para evaluar el funcionamiento de los analizadores se puede ver la evolución
temporal de la memoría. Se evalúan los diferente modelos de análisis. El tamaño de los
fichero XML es un parámetro que puede cambiar para ver el funcionamiento.
3 Funcionamiento de la implementación de FCM
El nuevo modelo de análisis presenta características especificas difeentes al resto de los
modelos. En este apartado se explica el funcionamiento de la implementación realizada.
3.1 Introducción
Para comprobar el funcionamiento de la implementación realizada, se ha usado un
fichero XML de tamaño 17024 Bytes. La Figura 4.48 muestra una pantalla del emulador
Wireless Toolkit. En ella se representa en el eje y la memoria utilizada, y en el eje x la
evolución temporal en el proceso de ejecución.
Figura 4.48: Funcionamiento del analizador FCM en el WTK.
En el procesamiento de un documento XML para el análisis con la implementación
FCM podemos distinguir varias fases:
1 Inicialización de los objetos.
2 Lectura de los datos.
3 Análisis de la información.
Capítulo 4. Análisis comparativo del rendimiento del modelo.
95
Estos puntos se detallan en los siguiente subapartados.
3.2 Inicialización de objetos
En la primera se realiza la inicialización de los objetos. Esta fase presenta un
crecimiento y un decrecimiento posterior. Es la parte izquierda de en la representación
gráfica. Esta fase no contiene ninguna información relevante de cara al funcionamiento
del analizador. En todos los casos y con todos los analizadores presenta el mismo
comportamiento.
3.3 Lectura de los datos
Una segunda fase en la que se dimensiona la estructura de datos en la que se va a
insertar los datos leídos del flujo de entrada, que en este caso es utilizando una conexión
HTTP. La estructura se dimensiona al principio y no existe redimensionado, a fín de
realizar un uso eficiente de la memoria utilizada. Sino se realizara este proceso se
debería de realizar un redimensionado de las estructuras.
El tiempo de lectura de los datos procedente del flujo de entrada es de 1652
milisegundos. Esta es una zona “plana” no existe un incremento en la memoria
utilizada, la memoria se dimensiona al principio el tamaño utilizado es la representación
del “escalón”, y posteriormente se produce la inserción de los datos en la estructura.
Los datos se leen de la red, de forma similar al funcionamiento de los métodos de la
clase DataInputStream, es decir, realizando una composición de los caracteres leídos y
recomponiéndolos, en un byte, o dos byte dependiendo del esquema de codificación
(basado en 8 bits como UTF-8, ASCII, …; o 16-bit, como UTF-16, UTF-16BE, UTF16LE; los esquemas basados en 32 bits UCS-4, se transforman en unidades de 16 bits,
ya que el tamaño de los caracteres soportadas en el lenguaje de programación Java es de
16 bits). Esta estructura representa la representación serializada del analizador.
3.4 Fase de análisis
En la tercera fase se analiza el documento XML. En la representación gráfica es la parte
derecha de la figura. El tiempo de duración del análisis en el análisis del documento
XML es de 570 milisegundos. Este tiempo puede verse reducido ya que este modelo
permite realizar un análisis selectivo de la información XML.
En la figura se representa como una “rampa”. La memoria utilizada se incrementa a
medida que se realiza el análisis de los distintos elementos de los que consta el archivo
XML. Es importante ver como este modelo separa claramente la memoria utilizada en la
representación serializada del documento XML del análisis de dicha información esto
puntos se analizan el siguiente apartado.
96
Contribución al análisis XML para la mejora en las prestaciones de memoria
4 Comparación del funcioncionamiento con otros
analizadores
En este apartado se presentan las pruebas de la implementación realizada con otros
analizadores XML, sobre el lenguaje Java, y para la misma plataforma. Se han elegido
analizadores que representen los diferentes modelos de análisis presentados en capítulos
previos, estos son, DOM, Push y Pull. Se muestran las pruebas realizadas con ficheros
de varios tamaños. Hay que reseñar que todos los analizadores que se presentan tienen
un tamaño del fichero ejecutable incluida la aplicación suficientemente pequeño para
que se pueda ejecutar en este tipo de dispositivos. Por otra parte, que algunos de ellos
son versiones reducidas de otros modelos de análisis adaptados para esta plataforma. Y
que todos ellos intentan optimizar la ejecución en memoria.
4.1 Xparse-J 1.0
Xparse-J 1.0 [Xparse-J] es una analizador que sigue el paradigma de modelo de objeto
(like-DOM), y se implementó con la idea de ser la implementación con menor tamaño
en el planeta, tal y como dice en su página web. Este analizador no lee, ni procesa las
DTD, (algo bastante común en esta plataforma) y el manejo de errores es mínimo,
pretendiendo que los documentos se hayan verificado previamente, es decir, en la parte
del servidor.
4.2 TAMparser
Tiny API for Markup (TAMparser) [St.Laurent ] proporciona una pequeña interfaz para
el análisis XML y documentos similares, en la plataforma J2ME. TAM está diseñado
para ofrecer lo que el analizador encuentra, dejando a la aplicación hacer algo (como por
ejemplo interpretar la DTD) si se necesitara.
TAM está basado en un subconjunto de SAX2, el cual ha sido ligeramente
expandido. TAM usa los métodos de llamada similar a SAX, y una aproximación
similar, pero ha sido reducido para encontrar las necesidades de los pequeños proyectos,
y expandido ligeramente para reflexjar que el ananlizador TM no requiera el
procesamiento de una DTD.
El analizador devuelve elementos y nombre de los atributos tanto prefijos como
nombres locales, J2ME no incluye la clase StringTokenizer. Este analizador no soporta
los nombres cualificados, QNames.
TAM es de forma deliberada pequeño y no está pensado para ser extensible. Esto
debería ser posible en aplicaciones para usar la información proporcionada aquí para
exteder su funcionalidd hacia el soporte completo de XML 1.0, pero este trabajo se deja
como un ejercicio de aplicación. En particular, TAM deja procesamiento de la
Capítulo 4. Análisis comparativo del rendimiento del modelo.
97
declaración DOCTYPE y las entidades detrás de estas el construirlas en XML 1.0 a la
parte de la aplicación.
Las secciones CDATA y de comentario se proporcionan por el manejador lexico
ext de SAX2.
4.3 kXML
kXML [kXML2] es un proyecto mantenido por la organización Enhydra (actualmente
cerrado), con el soporte de espacio de nombre, que sigue el modelo Pull, y
opcionalmente soporte para DOM y WAP. El tamaño del fichero ejecutable puede
considerarse de un tamaño bastante grande para esta aplicación, más de 40K. Contiene
dos formas de trabajar:
Manipulando árbol DOM, donde el árbol XML entero se analiza en
estructuras de nodos que residen en memoria y se pueden atravesar el árbol
con un programa.
Capturando eventos al estilo pull, don se atraviesan los datos XML y
mediante sus correspondientes llamadas.
4.4 Medidas con ficheros de tamaño 1728 bytes
En una primera medida el tamaño del fichero XML es de 1728 bytes. Las pruebas se han
realizado para los cuatro analizadores mostrados, kXML usado como Pull, TAMparser
como representación del modelo Pull, Xparse-J 1.0 como DOM (like-DOM) y el nuevo
modelo presentado FCM. La Tabla 4.12 presenta los resultados en el consumo de
memoria para el análisis de los archivos.
KXML
FCM
TAMparser
Xparse-J 1.0
44 300 bytes
47 032 bytes
116 384 bytes
280 464 bytes
Tabla 4.12: Resultados numéricos para el fichero de 1728 bytes.
El comportamiento de los analizadores en memoria es bastante diferente para los
modelos basados en árboles a los modelos basados en eventos, ya que los de eventos
consumen menos memoria. El analizador kXML presenta el menor consumo de
memoria, mientras que el modelo Xpare-J 1.0 presenta el peor comportamiento. Se
puede observar además, que Xparse-J 1.0 consume más de 6 veces la memoria
consumida por el analizador kXML. Mientras que la diferencia entre el analizador
kXML y FCM es muy pequeña. Estos resultados se pueden ver de forma gráfica en la
Figura 4.49.
98
Contribución al análisis XML para la mejora en las prestaciones de memoria
500000
450000
400000
Bytes
350000
300000
250000
200000
150000
100000
50000
0
kXML
FCM
TAMparser
Xparse-J
Figura 4.49: Medidas de los analizadores con un fichero de 1728 bytes.
4.5 Funcionamiento de los distintos modelos
Las cuatro figuras siguientes muestran el funcionamiento de los analizadores que
representan los cuatro modelos: Xparse-J 1.0, TAMparser, kXML y FCM. La fase de
inicialización es similar para los cuatro, sin embargo FCM se diferencia del resto en que
separa claramente la fase de lectura del documento de la fase de análisis.
Model
Xparse-J 1.0
Size 1728 Bytes
Figura 4.50: Xparse-J 1.0 con ficheros de 1728 bytes.
Push
TAMparser
Size 1728 Bytes
Capítulo 4. Análisis comparativo del rendimiento del modelo.
99
Figura 4.51: TAMparser con ficheros de 1728 bytes.
Pull
kxml2
Size 1728 Bytes
Figura 4.52: Funcionamiento de kXML con ficheros de 1728 bytes.
FCM
Size 1728 Bytes
Figura 4.53: FCM con ficheros de 1728 bytes.
4.5 Medidas con ficheros de tamaño 24458 bytes
El siguiente grupo de pruebas se han realizado con archivos de un tamaño
considerablemente mayor, 24458 bytes. Los resultados de la memoria utilizada medidos
en el emulador Wireless Toolkit se presentan en la Tabla 4.13.
kXML
239 140 bytes
FCM
352 204 bytes
TAMparser
XXXX
Xparse-J 1.0
XXXX
Tabla 4.13: Resultados para el fichero de 24458 bytes.
Los analizadores Xparse-J 1.0, y TAMparser consumen toda la memoria disponible
para realizar las pruebas sobre el emulador (500 000 bytes). Los otros dos analizadores
kXML y FCM no consumen toda la memoria disponible por el emulador. Presentan
mejor comportamiento en relación a la memoria utilizada.
Todas las medidas realizadas han sido hechas teniendo en cuenta las peores casos
para el analizador FCM. FCM permite un análisis parcial del documento, esto
disminuiría el tamaño de la memoria utilizada. Por otra pare kXML admite el cargar
todo el documento en memoria, esta característica no se ha utilizado, y en este caso su
funcionamiento sería considerablemente peor.
En la Figura 4.54 presenta gráficamente los resultado de memoria y medidos en el
emulador WTK.
100
Contribución al análisis XML para la mejora en las prestaciones de memoria
500000
450000
400000
Bytes
350000
300000
250000
200000
150000
100000
50000
0
kXML FCM TAM Xparser-J
Figura 4.54: Medidas de los analizadores con un fichero de 24458 bytes.
FCM
Size 24458 Bytes
Figura 4.55: FCM con ficheros de 24458 bytes.
El comportamiento de FCM se caracteriza por mantener una representación
serializada del documento XML. La fase de lectura de la información del flujo HTTP
está claramente separada del proceso de análisis. Además se comprueba que el coste de
mantener una representación serializada de todo el documento XML es menor
comparada con el tamaño de la memoria utilizada para realizar el proceso de análisis.
Capítulo 4. Análisis comparativo del rendimiento del modelo.
101
Pull
kxml2
Size 24458 Bytes
Figura 4.56: Funcionamiento del kXML con ficheros de 24458 bytes.
En las Figuras 4.57 y 4.58 se muestra gráficamente el consumode toda la memoria
disponible y la ejecución del "garbage collector".
Push
TAMparser
Size 24458 Bytes
Figura 4.57: Funcionamiento de TAMparser con ficheros de 24458 bytes.
Figura 4.58: Funcionamiento de Xparse-J 1.0 con ficheros de 24458 bytes.
102
Contribución al análisis XML para la mejora en las prestaciones de memoria
Figura 4.59: Captura del fichero descargado.
4.6 Codificación soportada por los distintos analizadores
El siguiente conjunto de pruebas muestran los esquemas de codificación soportada
por los distintos analizadores en la lectura de los documentos. La Tabla 4.14 muestra de
forma esquemática un resumen de estas pruebas.
En esta tabla se puede comprobar que todos lo analizadores soportan la codificación
ASCII.
ASCII
UTF-8
UTF-16BE
UTF-16 LE
UCS-4
kXML
Si
No
No
No
No
FCM
Si
Si
Si
Si
Si
TAMparser
Si
Si
No
No
No
Xparse-J
Si
Si
No
No
No
Tabla 4.14: Formatos de codificación soportados por los analizadores.
La prueba realizada para UTF-8, se realiza con el Byte Order Mark (BOM), es decir
la secuencia 0xEF 0xBB 0xBF, al comienzo de fichero que marca esta codificación. Los
caracteres del fichero XML sigue siendo el mismo. Todos los analizadores menos el
kXML soportan la codificación para UTF-8. kXML genera una excepción. En la
ventana del emulador aparece la siguiente información,
Error:org.xmlpull.v1.PullParserException: PI must
not start with xml (position:unknown @1:7 in
java.io.InputStreamReader@d590dbc)
Indicando que se ha producido un error en la Instrucción de Procesamiento. Este
mismo error se repite para el resto de codificación que se emplee en el archivo XML.
Los ficheros XML codificados según UCS-4 se han utilizado las clases para
escritura de archivos XML que proporciona la implementación de FCM. Para generar
los ficheros XML codificados según UTF-8, UTF-16BE y UTF-16LE, han sido
Capítulo 4. Análisis comparativo del rendimiento del modelo.
103
generados con los editor “Block de Notas de Windows XP” guardando con la opción
UTF-8, Unicode big endian, Unicode, respectivamente. La implementación FCM se ha
diseñado para soportar todos los esquemas de codificación especificados en la
recomendación XML.
5 Características de Funcionamiento de los Modelos
Se pueden establecer unas características para determinar las diferencias entre los
distintos modelos de análisis de los documentos XML, que recoja la facilidad de uso de
la interfaz, donde la mayor dificultad puede residir en la gestión de los métodos que
manejan la extracción de la información del documento XML.
La capacidad de utilizar XPath utilizando un analizador la determina la posibilidad
que presenta el modelo de mantener toda la información relacionada con el documento
XML, y esta posibilidad reside en los modelos DOM y FCM. Otro aspecto que se valora
es la eficiencia en memoria que será mayor en los modelos basados en eventos, es decir,
en Push, Pull y FCM. El análisis del documento sólo hacia delante se presenta en los
modelos Push y Pull. El mantener el documento en memoria por parte de los modelos
DOM y FCM permite el análisis hacia atrás.
Todos los modelos presentan la capacidad de lectura y todos ellos tienen la
capacidad de escritura y por tanto de bidireccionalidad salvo el modelo Push que no
tienen capacidad de escritura.
Todos estos puntos se presentan de forma esquemática en la siguiente Tabla 4.15.
Facilidad de uso
Capacidad de XPath
Eficiencia en Memoria
Análisis sólo hacia adelante
Lectura XML
Escritura XML
DOM
Alta
Si
Mala
No
Si
Si
Push
Medio
No
Buena
Si
Si
No
Pull
Alta
No
Buena
Si
Si
Si
FCM
Alta
Si
Buena
No
Si
Si
Tabla 4.15: Comparación de las características de los modelos.
6 FCM en la J2SE
Los objetivos marcados para al realizar esta Tesis Doctoral es el de realizar un prototipo
para la Java ME. Pero se ha llevado el prototipo implementado para la J2ME a la J2SE,
realizando una comparativa del rendimiento con otros analizadores de la J2SE.
Al igual que en los casos anteriores, el parámetro a medir es la memoria utilizada.
Las medidas son los modelos DOM y SAX que se proporcionan en la Java(TM) 2
Runtime Environment, Standard Edition (build 1.4.2_03-b02). El modelo Pull se ha
medido para sus dos implementaciones, en el estilo iterador y cursor. Estas medidas se
comparan con el comportamiento de la implementación de FCM. Las medidas
realizadas es con el archivo (libros.xml) con el que se han explicado los conceptos en el
104
Contribución al análisis XML para la mejora en las prestaciones de memoria
capítulo 2, su su tamaño es de 342 bytes. Las medidas se han realizado con la diferencia
de resultados del método freeMemory(), antes y despues de realizar el procesamiento.
FCM
79552
Push
83784
DOM
95400
StAX-iterator
102704
StAX-cursor
248136
Tabla 4.16: Medidas sobre la J2SE.
La Figura 4.60 muestra de forma gráfica las medidas realizadas sobre la J2SE.
Donde se comprueba que FCM presenta un buen comportamiento en el uso de la
memoria.
En la gráfica se puede ver como la memoria utilizada en el caso de DOM es mayor
que la de Push. El modelo implementado tiene un buen comportamiento en memoria,
mejor que el modelo Push.
Sin embargo resulta sorprendente como la implementación StAX tiene un mayor
uso de memoria que el análisis DOM. Ya los analizadores basados en eventos suelen
presentar un mejor comportamiento en memoria comparado con los analizadores del
estilo DOM. Esto podría deberse a que se genera el árbol para generar la secuencia de
eventos en la forma que la que JDOM y DOM4J generan eventos de tipo SAX a partir
de la estructura generada con DOM.
300000
250000
bytes
200000
150000
100000
50000
0
FCM
Push
DOM
Pull-Iterador
Pull-Cursor
Figura 4.60: Medidas sobre la J2SE.
7 Otras medidas sobre la J2SE
Este apartado presenta más medidas sobre la plataforma J2SE, si bien el prototipo ha
sido implementado pensando en su funcionamiento sobre la plataforma Java ME, y este
es el objetivo de la Tesis Doctoral, al final del capítulo de validación del prototipo
implementado se mostraron medidas para la plataforma J2SE.
Capítulo 4. Análisis comparativo del rendimiento del modelo.
105
Las siguientes medidas buscan desbordar las estructuras utilizadas en el proceso de
análisis. Difícilmente encontraremos documentos XML con una profundidad entorno al
centenar, sin embargo sí en cuanto al tamaño del archivo en relación con los recursos
disponibles, tal y como ya se ha presentado en capítulos previos. La misma idea es
aplicable al número de atributos utilizados por un elemento; el número de ellos puede
considerarse un mal uso en la composición de archivos XML. A pesar de esto, el
redimensionado de estructura puede suponer un problema cuando el tamaño de las
estructuras y el consumo en memoria sea grande. Las siguentes medidas tienen en
cuenta el dimensionado de las estructuras utilizadas y se mide al igual que antes su
comportamiento en memoria.
7.1 Programas para la generación de documentos XML
Para obtener las medidas se han realizado dos programas que generan archivos XML de
distintos tamaños, según el parámetro proporcionado en línea de comandos. Estos
programas se muestran en las Figuras 4.61 y 4.62. Las pruebas se han realizado sobre
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02). Los
analizadores sobre los que se han realizado las medidas son los que proporciona Java en
su edición estándar para SAX y DOM. También se han medido StAX en ambos estilos
Iterador y Cursor.
import
import
import
import
java.io.DataOutputStream;
java.io.OutputStream;
java.io.FileOutputStream;
java.io.IOException;
public class TesisMasPruebas{
public static void main(String args[]){
try{
FileOutputStream output =
new FileOutputStream ("prueba"+args[0]+".xml");
DataOutputStream out = new DataOutputStream(output);
int top = Integer.parseInt(args[0]);
top = 3;
out.writeBytes("<?xml version='1.0'?>");
out.writeBytes("<root>\n");
StringBuffer local = new StringBuffer("a");
// 'a' = 97
// 'z' = 122
int posiciones = local.length() -1;
while(posiciones < Integer.parseInt(args[0])){
out.writeBytes("<"+ local.toString() +">");
posiciones = local.length() -1;
char caracter = local.charAt(posiciones);
//Incrementa en uno
local.setCharAt(posiciones, ++caracter);
int recorre = posiciones;
while(recorre > -1 && local.charAt(recorre)==('z' + 1) ){
local.setCharAt(recorre, 'a');
Contribución al análisis XML para la mejora en las prestaciones de memoria
106
if(recorre == 0)
local.append("a");
else{
recorre--;
caracter = local.charAt(recorre);
//Incrementa en uno
local.setCharAt(recorre, ++caracter);
}
}
}
posiciones = local.length() -1;
while( posiciones >= 0){
char caracter = local.charAt(posiciones);
//Incrementa en uno
local.setCharAt(posiciones, --caracter);
int recorre = posiciones;
while ((local.length()> 0) && (recorre > -1)
&& (local.charAt(recorre) == ('a' - 1)) ){
local.setCharAt(recorre, 'z');
if(recorre == 0){
local.setLength((local.length() -1));
}else{
recorre--;
caracter = local.charAt(recorre);
//Incrementa en uno
local.setCharAt(recorre, --caracter);
}
}
posiciones = local.length() -1;
if(local.length()> 0){
out.writeBytes("</"+ local.toString() +">");
}
}
out.writeBytes("</root>");
out.close();
}catch(IOException e){
System.err.println("Error en ejecución ");
e.printStackTrace();
}
}
}
Figura 4.61: Programa para generar archivos de medidas para la profundidad.
import
import
import
import
java.io.DataOutputStream;
java.io.OutputStream;
java.io.FileOutputStream;
java.io.IOException;
public class MasPruebasAtributos{
public static void main(String args[]){
try{
FileOutputStream output =
new FileOutputStream ("atributos"+args[0]+".xml");
DataOutputStream out = new DataOutputStream(output);
int top = Integer.parseInt(args[0]);
Capítulo 4. Análisis comparativo del rendimiento del modelo.
107
top = 3;
out.writeBytes("<?xml version='1.0'?>");
out.writeBytes("<root>\n");
System.out.println("\n<root>");
StringBuffer local = new StringBuffer("a");
// 'a' = 97
// 'z' = 122
int posiciones = local.length() -1;
out.writeBytes("<abc ");
while(posiciones < Integer.parseInt(args[0])){
out.writeBytes(" "+ local.toString() +
"='"+local.toString()+"'");
posiciones = local.length() -1;
char caracter = local.charAt(posiciones);
local.setCharAt(posiciones, ++caracter);
int recorre = posiciones;
while (recorre > -1 &&
local.charAt(recorre) == ('z' + 1) ){
local.setCharAt(recorre, 'a');
if(recorre == 0)
local.append("a");
else{
recorre--;
caracter = local.charAt(recorre);
//Incrementa en uno
local.setCharAt(recorre, ++caracter);
}
}
}
out.writeBytes(" />");
out.writeBytes("</root>");
out.close();
}catch(IOException e){
System.err.println("Error en ejecución ");
e.printStackTrace();
}
}
}
Figura 4.62: Programa para generar archivos de medidas para los atributos.
7.2 Resultados
Las pruebas que se presetan muestran las medidas realizadas para la profundidad del
documento XML y el número de atributos en un elemento utilizando los programas del
apartado anterior. Esta es la clasificación que siguen los dos siguientes subapartados.
108
Contribución al análisis XML para la mejora en las prestaciones de memoria
7.2.1 Profundidad del archivo
La forma de invocar al intérprete de Java para la generación de los archivos con los que
realizar las medidas para obtener resultados de la profundidad de un documento XML,
es de la siguiente forma:
java TesisMasPruebas X
Con X, uno de los siguientes valores: 0, 1, 2, y 3.
Ficheros generados son los siguientes se muestran en la Figura 4.63.
Nombre del fichero
Tamaño en byte
prueba0.xml
35
prueba1.xml
226
prueba2.xml
6.312
prueba3.xml
199.650
Figura 4.63: Nombre y tamaño de los ficheros.
Las medidas del consumo de memoria para cada uno de los casos se muestran en las
siguientes tablas. El valor de los datos de todas las tablas son en bytes.
Para prueba0.xml:
FCM
69576
Push
80848
DOM
88464
StAX-iterator
86880
StAX-cursor
246552
Tabla 4.17: Medidas sobre la J2SE para prueba0.xml.
Para prueba1.xml:
FCM
69952
Push
83008
DOM
92760
StAX-iterator
93704
StAX-cursor
249704
Tabla 4.18: Medidas sobre la J2SE para prueba1.xml.
Para prueba2.xml:
FCM
82128
Push
137104
DOM
X
StAX-iterator
288912
StAX-cursor
352976
Tabla 4.19: Medidas sobre la J2SE para prueba2.xml.
Para prueba3.xml:
FCM
364968
Push
219584
DOM
X
StAX-iterator
1121272
StAX-cursor
1068456
Tabla 4.20: Medidas sobre la J2SE para prueba3.xml.
Los ejemplos con los ficheros prueba2.xml y prueba3.xml, fallan para el modelo
DOM.
En
concreto,
salta
una
excepción
"
Error:
java.lang.ArrayIndexOutOfBoundsException: 200", que induce a pensar que la
profundidad de los elementos de un documento XML la mantiene internamente en un
array de la dimensión indicada.
Estos resultados se pueden ver gráficamente las Figuras 4.64, 4.65, 4.66, y 4.67.
Capítulo 4. Análisis comparativo del rendimiento del modelo.
300000
bytes
250000
200000
150000
100000
50000
0
FCM
Push
DOM Pull-Iter Pull-Cursor
Figura 4.64: Medidas de prueba0.xml.
300000
bytes
250000
200000
150000
100000
50000
0
FCM
Push
DOM Pull-Iter Pull-Cursor
Figura 4.65: Medidas de prueba1.xml.
500000
bytes
400000
300000
200000
100000
0
FCM
Push
DOM Pull-Iter Pull-Cursor
Figura 4.66: Medidas de prueba2.xml.
1200000
bytes
1000000
800000
600000
400000
200000
0
FCM
Push
DOM Pull-Iter Pull-Cursor
Figura 4.67: Medidas de prueba3.xml.
109
110
Contribución al análisis XML para la mejora en las prestaciones de memoria
7.2.2 Número de atributos
La forma de invocar al intérprete de Java para la generación de los archivos con los que
realizar las medidas para obtener resultados relacionados con el número de atributos de
un documento XML, es de la siguiente forma:
java MasPruebasAtributos X
Con X, uno de los siguientes valores: 0, 1, 2, y 3.
Ficheros generados son los siguientes
Nombre del fichero
Tamaño en byte
atributos0.xml
43
atributos1.xml
207
atributos2.xml
5.617
atributos3.xml
181.379
Figura 4.68: Nombre y tamaño de los ficheros.
Las medidas del consumo de memoria para cada uno de los casos se muestran en las
siguientes tablas. El valor de los datos de todas las tablas son en bytes.
Para atributos0.xml:
FCM
69592
Push
80944
DOM
88624
StAX-iterator
87080
StAX-cursor
246624
Tabla 4.21: Medidas sobre la J2SE para atributos0.xml.
Para atributos1.xml:
FCM
69920
Push
87800
DOM
97160
StAX-iterator
104600
StAX-cursor
250144
Tabla 4.22: Medidas sobre la J2SE para atributos1.xml.
Para atributos2.xml:
FCM
80736
Push
276472
DOM
326392
StAX-iterator
281928
StAX-cursor
344320
Tabla 4.23: Medidas sobre la J2SE para atributos2.xml.
Para atributos3.xml:
FCM
328424
Push
X
DOM
1079544
StAX-iterator
1038288
StAX-cursor
X
Tabla 4.24: Medidas sobre la J2SE para atributos3.xml.
300000
bytes
250000
200000
150000
100000
50000
0
FCM
Push
DOM Pull-Iter Pull-Cursor
Capítulo 4. Análisis comparativo del rendimiento del modelo.
111
Figura 4.69: Medidas de atributos0.xml.
300000
bytes
250000
200000
150000
100000
50000
0
FCM
Push
DOM Pull-Iter Pull-Cursor
Figura 4.70: Medidas de atributos1.xml.
400000
bytes
300000
200000
100000
0
FCM
Push
DOM Pull-Iter Pull-Cursor
Figura 4.71: Medidas de atributos2.xml.
1200000
bytes
1000000
800000
600000
400000
200000
0
FCM
Push
DOM Pull-Iter Pull-Cursor
Figura 4.72: Medidas de atributos3.xml.
De todas estas gráficas podemos decir que los modelos basados en eventos tienen
un buen comportamiento en memoria. El modelo DOM presenta peor comportamiento
en memoria que el modelo Push y FCM.
Push mejora a FCM solo en la prueba Figura 4.73 del fichero prueba3.xml. El
modelo Push no mantiene ninguna estructura relacionada con la información analizada,
por esto cuando el tamaño del fichero es considerablemente grande su uso es bueno. Su
dimensionamiento se ve desbordado en la prueba de la Figura 4.72, para el fichero
atributos3.xml.
112
Contribución al análisis XML para la mejora en las prestaciones de memoria
Puede sorprender que el modelo Pull en sus dos formas, Iteración y Cursor tengan
un comportamiento peor que el modelo DOM. Esto podría deberse a que se genera el
árbol para generar la secuencia de eventos en la forma que la que JDOM y DOM4J
generan eventos de tipo SAX a partir de la estructura generada con DOM.
Puede deducirse de las medidas que simplemente se obtiene información del punto
a partir del cual las estructuras están dimensionadas en cada implementación, con
independencia del modelo utilizado. Por lo tanto se está considerando los detalles de la
implementación particular y no del modelo general que es el patrón buscado al realizar
las medidas. Sin embargo remarcar que tales dimensiones no son habituales en
documentos XML.
8 Conclusiones
En este capítulo se ha mostrado el análisis comparativo del rendimiento del modelo. Se
ha presentado la evolución temporal del funcionamiento de la implementación realizada
para el nuevo modelo FCM. Se ha comparado con el funcionamiento de otros
analizadores. Se pueden extraer varias conclusiones:
Se separa claramente en la implementación el soporte de la representación
serializada de la información XML de la memoria utilizada en el análisis de dicha
información.
El tamaño de la memoria utilizada para mantener la representación serializada de la
información XML es considerablemente menor que el tamaño en el procesamiento de
dicha información. Con esto se puede justificar el mantener una representación
serializada de la información XML, de tal forma que mediante el uso de eventos se
pueda manipular la información XML bajo el control de la aplicación. FCM puede
mover no solo hacia delante como lo realizan los modelos Push y Pull, sino que al
mantener la representación serializada de la información XML permite mover hacia
atrás el cursor, y volver a generar nuevos eventos.
Este capítulo presentan además que el tamaño de los archivos es crítico en esta
plataforma y que puede degradar considerablemente el funcionamiento de la aplicación.
Se ha presentando los métodos de codificación soportados por el prototipo
implementado y comparado con otras implementaciones.
FCM se ha implementado para tener un buen funcionamiento en la plataforma Java
ME, aunque se han realizado pruebas sobre la plataforma J2SE. El funcionamiento de la
implementación realizada sobre esta plataforma presenta unos resultados excelentes.
CAPÍTULO 5.
Conclusiones y Líneas Futuras
En el capítulo 3 se ha presentado el modelo de análisis, y el capítulo 4 presenta medias
comparativas con otras implementaciones. En este capítulo se resumen los puntos más
importantes de la Tesis Doctoral, destacando sus contribuciones y proponiendo líneas de
continuación del trabajo realizado.
1 Conclusiones
En el primer capítulo se expuso el entorno, motivación y objetivos de la presente Tesis
Doctoral. En concreto:
Se introdujeron las razones principales que han llevado a plantear nuevos
modelos de análisis de los documentos XML, en plataformas con
recursos limitados.
Se resaltó como ventaja competitiva de los modelos que utilizan sólo
analizadores basados en eventos.
El motivo de la realización de la presente Tesis Doctoral es proporcionar
un modelo de análisis de la información XML que considere como punto
esencial la memoria
o tanto en ejecución de la aplicación,
o como el de la propia aplicación.
El ámbito del estudio se orienta a proporcionar servicios Web XML para
la plataforma Java para móviles, J2ME.
Una vez establecidos el ámbito y motivos de la Tesis, en el capítulo 2 se presentó el
Estado del Arte de los modelos de análisis de los documentos XML. Se presentan
características que hacen diferentes a los analizadores bajo el punto de vista del
funcionamiento. La selección de un determinado modelo de análisis de la información
XML es clave para un uso eficiente y robusto en los dispositivos limitados. En
particular:
o Se introdujeron los conceptos fundamentales sobre el análisis de los datos
XML.
o Se introdujeron los conceptos fundamentales sobre la representación y uso
de la memoria que se realiza en el proceso de análisis de la información
XML.
114
Contribución al análisis XML para la mejora en las prestaciones de memoria
o Se llevó a cabo un estudio del funcionamiento de los distintos modelos de
análisis de la información XML, particularizando en las interfaces de dichos
modelos. Estás son, las interfaces basadas en árboles y las interfaces basadas
en eventos.
o Se detallaron las interfaces para los modelos de análisis DOM, Push y Pull.
o Se detallaron que existen diferencias en cuanto a si el análisis de los datos se
realiza mediante la extracción de los elementos de información, o bien, se
realizan en el lugar en el que los datos se han encontrado (in-situ).
o Se detallaron diferencias en los analizadores XML en función de cómo la
información es devuelta a la aplicación.
o Se detallaron diferencias en cuanto a la relación que existen entre el cliente
y el analizador.
El modelo para el análisis de los documentos XML propone el mantener la
representación serializada de la información XML, que podría ser la fuente de donde
provienen los datos, de tal forma que no se necesite una representación arbórea como
con el modelo DOM, y a diferencia de los modelos previos basados en eventos (Push y
Pull) se pueda acceder a toda la información previamente analizada.
o Se introducen los requisitos de partida y la valoración de los modelos de
análisis existentes.
o Se proporcionan las especificaciones de diseño, entre las cuales destacan:
o Movimiento del cursor hacia atrás.
o Duplicar la menor cantidad de memoria.
o Describe el funcionamiento básico, así como el modelo de comportamiento
de cada una de los elementos que intervienen en el modelo
productor/consumidor.
o Describe las nuevas operaciones que ofrece el nuevo modelo, FCM. Dicho
modelo proporciona el movimiento del cursor no sólo hacia delante
mediante un proceso de iteración como el modelo Pull, sino que permite el
movimiento de cursor hacia atrás
o El mantener la representación serializada de la información XML hace el
proceso iteración hacia delante pueda realizarse sin el análisis de los
elementos hijos de un cierto elemento mediante el método
skipWithoutParseChilds(), teniendo un control del análisis del documento
XML.
o Se presenta un ejemplo de utilización de FCM, en código Java.
En el capítulo 3 se presentó la implementación del modelo. En concreto:
o Se presenta una implementación para la plataforma Java para móviles,
J2ME.
Capítulo 5. Conclusiones y líneas futuras.
115
o Se detalla las clases mínimas para realizar la implementación.
o Se presenta la detección del esquema de codificación que soporta la
implementación del nuevo modelo.
o Se analiza qué estructura se utiliza y el tamaño para realizar el
mantenimiento de la representación serializada de la información XML.
o Se presenta modelos válidos para poder implementar la característica de
“bien formados” de los documentos XML, mostrando la opción elegida.
o Se presenta la representación de un elemento dentro de la estructura de
representación de la información XML y de la relación entre los distintos
elementos.
o Se detalla la composición de la interfaz XMLFCMConstant.
o Se especifica la estructura de directorios y las clases contenidas en ellos.
o Se especifica los métodos que se implementan en las clases para el análisis
de los documentos.
El funcionamiento del analizador FCM necesita la representación del documento
XML entero, para tener la posibilidad de realizar el movimiento del cursor a lo largo de
esta representación, conocida como representación serializada.
La necesidad de mantener la estructura serializada, hace que se separe la memoria
utilizada para la representación serializada del documento XML, de la memoria
utilizada para el procesamiento de dicho documento.
o El tamaño de la memoria para la representación serializada es menor que el
tamaño de la memoria que se utiliza para el análisis de la información. Por
lo que una conclusión de este método es que se “justifica” el uso y
mantenimiento de toda la estructura serializada.
o El mantener esta estructura serializada hace que, mediante el
direccionamiento hacia dicha estructura, se pueda realizar un análisis de
dicha información bajo demanda del “consumidor”, sin la necesidad de
construir el árbol del modelo DOM, por lo que no existen las penalizaciones
de memorias de dicho modelo.
o El tamaño de la memoria relacionada con el análisis del documento XML
puede reducirse mediante el uso del método skipWithoutParseChilds(), que
no analiza los elementos hijos de dicho elemento.
La aplicación de este modelo supone un avance en el análisis de la información
XML, debido a:
o Supone un uso eficiente de la memoria utilizada en el análisis de los
documentos XML.
o Si se tiene conocimiento de la estructura de la información a analizar, lo
cual suele ser habitual en los servicios Web, se puede realizar un análisis
116
Contribución al análisis XML para la mejora en las prestaciones de memoria
selectivo de la información, ya que el método skipWithoutParseChilds()
realiza un movimiento del cursor hacia delante sin el utilizar.
o No mantiene una estructura arbórea de objetos que representen el
documento XML, pero puede acceder a información contenida en el
documento XML previamente analizada, o realizar un movimiento hacia
atrás del cursor para analizarla.
o Permite realizar un análisis de la información XML a petición bajo demanda
de la aplicación.
o Permite el uso de esquemas de codificación basados en 8 bits, 16 bits y 32
bits.
2 Líneas de Avance
A continuación se presentan una serie de líneas de avance sobre los trabajos
realizados. Algunos de ellos ya publicados, otros propuestos por los revisores de este
trabajo:
Formatos de transformación universales para plataformas con 16 bits
(como por ejemplo Java) que optimicen la memoria utiliza
representación XML serializada:
o Para algunos casos, se optimiza el número de unidades si se
utilizan cambio de página (page-shift). El algoritmo propuesto es
UTF-I16S [Sierra b], donde la conmutación se realizaría
utilizando dos valores para el cambio de página. Las páginas van
asociadas al uso de una unidad de 16 bits o dos unidades de 16
bits.
o Un formato de transformación de UCS-4, llamada UTF-I16. Los
caracteres se codifican usando secuencias de 1 a 3 unidades de
código. Una unidad de código está formada por 16 bits.
El análisis “in-situ” es una buena propuesta para pequeños dispositivos y
tiene otras aplicaciones. Por ejemplo, permite usar XML con formato de
datos “nativo” interno en un editor de texto de XML apropiado [Wilmott
a].
Uso del analizador para la invocación de un servicio Web con SOAP.
StASOAP [Sierra c] es una propuesta para utilizar SOAP con un
analizador basado en el nuevo modelo FCM.
El nuevo modelo de análisis de la información XML ofrece, un gran
abanico de posibilidades para la implementación de tecnologías que usan
XML como punto de partida de alguna forma, tales como XPath, XQuery
y Transformación. Queda por verificar si estas implementaciones son lo
Capítulo 5. Conclusiones y líneas futuras.
117
suficientemente ligeras para plataformas con recursos limitados en los
que se presenta esta Tesis Doctoral.
Apéndice A.
Autodetección de la Codificación de Caracteres
XML codifica funciones para declarar la codificación empleada con una etiqueta interna
en una entidad, indicando la codificación de caracteres se está utilizando. Un analizador
XML puede leer las etiquetas internas que determinan la codificación utilizada, aunque,
aparentemente se sabe qué codificación de caracteres se está utilizando, y es lo que la
etiqueta interna debería indicar. En general, esto es lo deseable. Pero podría no ser del
todo deseable en XML, aunque, XML limita el caso general a dos formas:
cada implementación se supone que soporta sólo un conjunto finito de
codificación de caracteres, y
la declaración de la codificación XML no está restringida al
posicionamiento de la etiqueta, y con la caracterización de su contenido,
sino que se puede autodetectar la codificación de caracteres utilizada y
expresada en cada entidad.
En algunos casos otras fuentes de información están disponibles además del flujo de
datos XML. En otros casos las fuentes de información están disponibles además para el
propio flujo de datos. Dos casos podrían distinguirse, dependiendo de si la entidad XML
se presenta para el procesador sin o con cualquier acompañamiento (externo) de
información. Se considera el primer caso primero.
1 Detección de la codificación
Ya que cada entidad no va acompañada de una información externa de información y no
debería comenzar con una declaración de codificación XML con UTF-8 y UTF-16, en el
cual los primeros caracteres debería ser '<?xml', cualquier analizador lo puede detectar,
después de dos o cuatro octetos de entrada, se puede saber qué codificación se utiliza.
Leyendo esta secuencia, podría ayudar a conocer cual de ellos se está utilizando, estos
pueden ser por ejemplo, el carácter ‘<’ se codifica en UCS-4 de la siguiente forma
“#x0000003C”,y el carácter ‘?’ se codifica en UCS-4 de la siguiente forma
“#x0000003F”, y el Byte Order Mark necesitado de UTF-16 en el flujo de datos es
“#xFEFF”. La notación ## se usa para representar cualquier valor del byte excepto los
de dos consecutivos ##s no pueden ser ambos 00.
Los bytes de dirección (BOM) para cada codificación se representan en la Tabla
A.25.
120
Contribución al análisis XML para la mejora en las prestaciones de memoria
Secuencia
00 00 FE FF
FF FE 00 00
00 00 FF FE
FE FF 00 00
Codificación
UCS-4, big-endian (orden 1234)
UCS-4, little-endian (orden 4321)
UCS-4, octeto no usual (2143)
UCS-4, octeto no usual (3412)
FE FF ## ##
UTF-16, big-endian
FF FE ## ##
UTF-16, little –endian
EF BB BF
UTF-8
Tabla A.25: Byte Order Mark para los distintos formatos de codificación.
Sin Byte Order Mark:
Secuencia
00 00 00
3C 00 00
00 00 3C
00 3C 00
00 3C 00
3C
00
00
00
3F
3C 00 3F 00
3C 3F 78 6D
4C 6F A7 94
Otro
Codificación
UCS-4 o cualquier otra codificación en unidades de 32 bits y caracteres ASCII
codificados como valores ASCII, en big endian, (1234), little endian (4321) y dos
ordenaciones no habituales (2143 y 3412). La declaración de codificación debería
leerse para determinar qué codificación se aplica.
UTF-16BE o big-endian ISO-10646-UCS-2 u otra codificación con unidades de 16
bits con orden big-endian y caracteres codificados como valores ASCII (la
declaración de codificación debería ser leída para poder determinarla).
UTF-16LE, little-endian ISO-10646-UCS-2 u otra codificación con unidades de 16
bit con orden little y caracteres ASCII codificados como valores ASCII (la
declaración debería leerse para determinarla)
UTF-8, ISO 646, ASCII, algunos ISO 8859, Shift-JIS, EUC, o cualquier otro de 7
bit, 8bit, o codificación de anchura variable que asegure que los caracteres ASCII
tienen una posición y valor normal, se debería leer la declaración de codificación
para detectar cual de ellos se aplica, ya que todos estos usan el mismo patrón de bit
para los caracteres ASCII relevantes, la declaración de codificación debería ser
leida.
EBCDIC (la declaración de codificación debería leers para saber el código de
página en uso)
UTF-8 sin declaración de codificación, o sino el flujo de datos está mal etiquetado,
fragmentado, corrupto, o envuelto en cualquier otro.
Tabla A.26: Secuencia de los primeros bytes para archivos XML sin el uso de BOM.
En los casos en los que no se necesitara leer la declaración para determinar
codificación, la sección 4.3.3 de la recomendación XML dice que la declaración de
codificación, si está presente, debe ser leída y el nombre de la codificación debe
coincidir con la codificación de la entidad. También, es posible una nueva codificación
diferente a las consideradas arriba y en este caso necesariamente se necesita la
declaración de la codificación para poder determinarla, en casos donde esto no se
requiera se debe determinar de forma explícita.
Este nivel de autodetección debe ser suficiente para leer la declaración de la
codificación XML y analiza la identificación de la codificación empleada, lo cual es
todavía necesario para distinguir los miembros individuales en cada familia de
Apéndice A.
121
codificación (es decir, UTF-8 de 8859, y las partes 8859 de cada una de ellas, o para
distinguir el código de página actual en EBCDIC, entre otros).
Ya que el contenido de la declaración de codificación se ha restringido a caracteres
del repertorio ASCII, un analizador puede realizar la lectura de la declaración de la
codificación tan pronto como sea detectada qué familia de codificación se está usando.
Ya que en la práctica, el rango de caracteres que se pueden codificar está dentro de
alguna de las categorías de arriba, la declaración de codificación XML permite
razonablemente realizar un etiquetado de esquemas de codificación, siempre y cuando
las fuentes de información externas en el sistema operativo o nivel de protocolo de
transporte no lo puedan realizar. Los caracteres de codificación tales como UTF-7 que
hacen sobrecargar el uso de valores de byte ASCII podrían caer en la realización
detectada.
Después de detectar la codificación usada, se puede actuar apropiadamente,
mediante invocar una rutina de entrada separada para cada caso, o mediante llamada a la
propia función de conversión en cada carácter de entrada.
Como cualquier sistema de autoetiquetado, la declaración de codificación XML no
trabaja si hay cualquier cambio software en la configuración de la entidad de
codificación sin una actualización de la declaración de codificación. Los
implementadotes de las rutinas de la codificación de caracteres se debería tener cuidado
para asegurar la correcta información de la etiqueta externa de la entidad, y de la interna.
2 Prioridades para la información externa de la codificación
El segundo caso ocurre cuando la entidad XML está acompañada por la
información de codificación, como en algunos sistemas de ficheros y algunos protocolos
de red. Cuando muchas fuentes de información están disponibles, su prioridad relativa y
el método preferido de manejo de conflictos debería ser especificada como parte del
protocolo de alto nivel usado para entregar el XML. En particular, se refiere a RFC 3023
[RFC 3023] o su sucesor, el cual define los tipos MIME text/xml y
application/xml, y proporciona algunos consejos. Para garantizar la
interoperabilidad, sin embargo, se recomienda usar la siguiente regla:
Si una entidad XML está en un fichero, el Byte-Order Mark y la declaración de
codificación se deben usarse para determinar la codificación de caracteres.
Apéndice B.
UTF-I16S
ISO 10646 Universal Character Set (UCS) y Unicode cubren la mayoría de los símbolos
de los alfabetos existentes. Hay varios formatos de transformación para UCS. UTF-I16S
es un formato de transformación con cambio de página para la codificación de los 4
octetos usados en UCS-4, para plataformas y entornos de 16 bits.
1 Introducción
Los formatos de transformación con unidades de 8 bits, tales como UTF-8 si se utilizan
en plataformas de 16 bits desaprovechan el byte superior. Los formatos de
transformación de 16 bit, han seguido los criterios de transformación marcados por
UTF-16. UTF-16 presenta varios problemas como son rango, ordenación de la
transformación y el marcar una región con caracteres que no puede transformar.
2 Formato de Transformación de UTF-I16S
El formato consta de dos páginas:
Dos bytes.
La página con dos bytes codifica valores en del BMP, es decir, valores
(0x0000)-(0xFFFF).
Cuatro Byte
La página con cuatro bytes codifica valores fuera del BMP, es decir,
valores (0x10000)-(0x7FFFFFFF).
La siguiente tabla muestra el mapeado de UCS-4 en unidades de 16 bits según
UTF-I16S. En la Tabla B.19 se establece una relación entre el rango de valor asociado al
carácter UCS-4 y el número de unidades en el que se realizará la transformación. El
valor de UCS-4 en el rango de 0 a FFFF (en hex.) se corresponde con una unidad de 16
bits. Y los valores en el rango 10000 y 7FFFFFFF (en hex.) se corresponden con dos
unidades de código de 16 bits.
UCS-4 rango (Hex)
0000 0000-0000 FFFF
0001 0000-7FFF FFFF
Función
XXXX
XXXX XXXX
Tabla B.27: Mapeo de UCS-4 en unidades de 16 bits según UTF-I16S.
Los valores numéricos del carácter para realizar el código de página se muestra en la
Tabla B.21.
124
Contribución al análisis XML para la mejora en las prestaciones de memoria
Código
0xE (ShiftInput)
0xF (ShiftOutput)
Función
Cambio a página 1
Cambio a página 0
Tabla B.28: Códigos para el cambio de página en UTF-I16S.
3 Codificación de UCS-4 en UTF-I16S
Para realizar la transformación de UCS-4 a UTF-I16S se procede de la siguiente forma:
o Primero: Se determina el número de la unidad de código necesitadas
para el valor del carácter y la primera columna de la Tabla D1. Es
importante tener en cuenta que las filas de la tabla son mutuamente
exclusivas, es decir, hay solo una forma válida de obtener un carácter
UCS-4.
o Segundo: Se determina la página actual (inicialmente el código de
página es ShiftInput).
o Tercero: Si el código de página no está asociado con el número de
código de pagina determinado en el primer paso, entonces hay cambio de
página, y se necesita el código de cambio de página.
o Cuatro: Se codifica el valor del carácter en una o dos unidades de
código, siguiendo el criterio establecido en el primer paso.
4 Decodificación de UTF-I16S
Para decodificar de UTF-I16S a UCS-4 se procede como sigue:
o Primero: Se inicializa el número de valor del carácter UCS-4.
o Segundo: Se determina cual es la página actual.
o Tercero: Se determina si el actual valor es para cambiar de página.
o Cuarto: Se distribuyen los bits de la secuencia en el carácter UCS-4.
5 Implementación de UTF-I16S en Java
Java utiliza una codificación de los caracteres en unidades de 16 bits. Es pues un
entorno en el que resulta apropiada realizar una implementación del método de
transformación UTF-I16S.
Cada página usa una anchura fija para la codificación de caracteres. Cuando se codifica
en la página 0, y cambia a la página 1 usa el código de control UTFI16S.ShiftInput.
Apéndice B.
125
Cuando el contexto está en 4-byte (página 1), cambia a la página 0 usa el código de
control UTFI16S.ShiftOutput. Estos valores se representan en la Figura B.74.
public interface UTFI16S {
final static int ShiftOutput=0xE; //Shift -Out
final static int ShiftInput = 0xF; //Shift -In
}
Figura B.74: Interfaz UTFI16S.
Las dos siguientes figuras muestran los métodos intToUtfi16s y utfi16sToInt,
para realizar la transformación de UTF-I16S a su valor entero y viceversa.
public int intToUtfi16s(int code[], int count, char seq[]){
int p = 0;
int i = 0; int max = 0;
if((code != null)&&(seq != null)){
max =((code.length < count)
? code.length
: count); seq[i] = UTFI16SConstants.ShiftInput;
}else
throw new IllegalArgumentException();
for(;i < max;){
if((mode == UTFI16SConstants.ShiftInput) &&(code[i] < 0x10000)){
seq[p++] = (char)code[i++];
}else if((mode == UTFI16SConstants.ShiftInput) &&(code[i] >
0xFFFF)){
mode = UTFI16SConstants.ShiftOutput;
seq[p++]=(char)UTFI16SConstants.ShiftOutput;
seq[p++]=(char)((code[i]&0x7FFF0000)>>16);
seq[p++]=(char)((code[i++]&0xFFFF));
}else if((mode==UTFI16SConstants.ShiftOutput) &&(code[i] <
0x10000)){
mode = UTFI16SConstants.ShiftInput;
seq[p++]=(char)UTFI16SConstants.ShiftInput;
seq[p++]=(char)code[i++];
}else if((mode == UTFI16SConstants.ShiftOutput) &&(code[i] >
0xFFFF)){
seq[p++]=(char)((code[i]&0x7FFF0000)>>16);
seq[p++]=(char)((code[i++]&0xFFFF));
}
}
return p;
}
Figura B.75: Método intToUtfi16s.
126
Contribución al análisis XML para la mejora en las prestaciones de memoria
public int utfi16sToInt(char code[], int count, int seq[]){
int p = 0; int i = 0; int max = 0;
mode = UTFI16SConstants.ShiftInput;
if((code != null)&&(seq != null)){
max =((code.length < count)?code.length:count);
seq[i] = UTFI16SConstants.ShiftInput;
}else throw new IllegalArgumentException();
for(;i < max;){ if(mode == UTFI16SConstants.ShiftInput){
switch(code[i]){
case UTFI16SConstants.ShiftInput:
i++; seq[p++] = (code[i++]&0xFFFF); break;
case UTFI16SConstants.ShiftOutput:
mode = UTFI16SConstants.ShiftOutput; i++; break;
default: seq[p++] = (code[i++]&0xFFFF); break;
}
}else if(mode == UTFI16SConstants.ShiftOutput){
int local = 0;
local = ((code[i++]&0x7FFF)<<16);
local += (code[i++]&0xFFFF);
switch(local){
case UTFI16SConstants.ShiftInput:
mode = UTFI16SConstants.ShiftInput; break;
case UTFI16SConstants.ShiftOutput:
int tmp = 0; tmp = ((code[i++]&0x7FFF)<<16);
tmp += (code[i++]&0xFFFF); eq[p++] = tmp; break;
default: seq[p++] = local; break;
} }else throw new IllegalStateException(); }
return p;
}
Figura B.76: Método utfi16sToInt.
Apéndice C.
DTD
Una de las principales ventajas de SGML y XML sobre otros métodos de representación
de documentos es la idea de que para un tipo de documento existen unas condiciones de
validez definidas por el usuario que pueden formularse explícitamente, y esta validación
puede ser automáticamente evaluados. Las estrategias para comprender, analizar e
implementar estas restricciones son básicas para los usuarios de las tecnologías de los
lenguajes de marcas.
1 Introducción
La recomendación XML incluye un lenguaje de modelado de documento, llamado DTD
(Document Type Definition). Este lenguaje tiene una larga historia, y ha sido
ampliamente usado.
El estándar SGML introdujo el concepto de DTDs, y necesita una DTD para todas
las instancias de documentos que cumplan las normas de este lenguaje.
Los modelos de documento pueden ser traducidos de uno a otro formato. Una DTD
puede ser convertida en un esquema de definición. Aunque, el inverso no siempre es
cierto debido a las limitaciones de las DTDs.
Sin embargo las DTDs en XML son opcionales y son más simples que las DTDs de
SGML. El lenguaje de modelado DTD,
Es el más extendido, y está siempre plenamente soportado;
Es un pequeño lenguaje que facilita una validación muy rápida;
Ofrece buenas ventajas.
2 Document Type Definitions: Fundamentos
La posibilidad de validar instancias de un documento XML bien formado contra un
modelo de documento es uno de los aspectos que se plantea en el horizonte de los
lenguajes de marcas. Un modelo de documento puede tomar varias formas. Una DTD se
construye con un conjunto de instrucciones que proporcionan una sintaxis. La DTD
define los tipos de elementos, atributos y entidades permitidas, y puede expresar algunas
limitaciones para combinarlos.
128
Contribución al análisis XML para la mejora en las prestaciones de memoria
Los documentos que se ajustan a su DTD, se denominan “válidos”. Un documento
“bien formado” respecta la estructura y sintaxis definida por la especificación de XML.
Un documento “bien formado” puede además ser “válido” si cumple las reglas de una
DTD determinada. Una DTD puede residir en un fichero externo, tal vez compartido por
varios de documentos. O bien, puede estar contenido en el propio documento XML,
como parte de su declaración de tipo de documento. Un ejemplo se ilustra en la Figura
C.77 y C.78.
<! DOCTYPE etiqueta[
<!ELEMENT etiqueta (nombre, calle, ciudad, pais, codigo)>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT calle (#PCDATA)>
<!ELEMENT ciudad (#PCDATA)>
<!ELEMENT pais (#PCDATA)>
<!ELEMENT codigo (#PCDATA)>
]>
Figura C.77: Ejemplo de DTD.
<etiqueta>
<nombre>Antonio J. Sierra</nombre>
<calle>c/ Camino de los Descubrimientos, s/n</calle>
<ciudad>Sevilla</ciudad>
<pais>España</pais>
<codigo>41092</codigo>
</etiqueta>
Figura C.78: XML asociado a la DTD.
La declaración del tipo de documento empieza en la primera línea y termina con
"]>". Las declaraciones DTD son las líneas que empiezan con "<!ELEMENT" y se
denominan declaraciones de tipo elemento. También se pueden declarar atributos,
entidades y anotaciones para una DTD. En el ejemplo anterior, todas las declaraciones
DTD se definen "etiquetas" residen dentro del documento. Parsed character data
(PCDATA) es un tipo de dato que ocurre en un contexto donde el texto es analizado y
marcado para su reconocimiento. A diferencia de character data (CDATA) que son tipos
de datos en SGML y XML para datos que no incluyen marcas o entidades de referencia.
3 Lenguajes de Modelado Alternativos
Las características de la DTD son heredadas del estándar SGML, aunque las DTDs del
lenguaje SGML son más sofisticadas que el lenguaje de modelado DTD de XML.
Durante el desarrollo del estándar XML, se eliminaron muchas características que
estaban redundantes o que no tenían mucho uso, y otras que fueron consideradas
Apéndice C.
129
demasiado complejas para el propósito de implementación de los analizadores. Algunas
contribuciones y partes interesadas argumentaron que las DTDs no eran del todo
necesarias. Otras sin embargo indicaron que solo eran necesarias sino que deberían ser
más potentes que las DTDs de SGML. Aunque ninguno de los grupos ganó en su
argumentación y el estándar XML se pensó para ser más simple que su predecesor.
Algunos principios básicos fueron compartidos mediante mucho de los esfuerzos
para reemplazar a las DTDs, y han sido ampliamente aceptadas que cualquier
sustitución debería
Ser funcionalmente compatible con las características de la DTD (esto es
que podría ser aplicado a los documentos existentes y que las viejas DTD
pudieran ser automáticamente convertidas al nuevo lenguaje de modelado);
Usar la sintaxis de los documentos de tal forma que herramientas XML
pudieran ser usadas para crear, validar, procesar, y presentar modelos
documentos;
Recuperar las características usadas de las DTD de SGML que fueron
eliminadas en la versión de XML;
Extender la funcionalidad para modelar documentos centrados en los datos.
Un gran número de propuestas se han plateado para dar solución. Algunas de ellas
caen dentro de los criterios establecidos y otras se han incorporado con otros propósitos.
El campo está ahora ampliamente reducido a estos:
XML Schemas, que se consideran en el siguiente apéndice.
RELAX NG [Clark 01b] (una propuesta que nace de las predecesoras
RELAX[Clark 01c] y TREX [Clark 01d])
Schematron [Schematron] es un lenguaje de validación de la estructura
XML usando patrones en árboles. Schematron es un Language simple y
potente de tipo Schema para las estructuras, que está bajo consideración
para convertirse en un estándar ISO (ISO/IEC 19757 - DSDL Document
Schema Definition Language - Part 3: Rule-based validation Schematron)
Una DTD, en SGML o XML, es una definición forma de los elementos y la relación
entre los elementos de datos (la estructura) para un tipo específico de documento.
La palabra “schema” ha aparecido en el nombre de varias propuestas. Este término
está definido en el Diccionario de Inglés de Oxford como “una representación de un
plan o teoría en la forma de perfil o modelo”.
Apéndice D.
XML Schema
1 Introducción
Un esquema, al igual que una DTD, define la “apariencia” de un conjunto de uno o más
documentos XML; esto es, qué elementos y atributos pueden contener y en qué orden y
cuál puede ser su contenido. De hecho, podríamos calificar las DTD como un tipo de
esquema, en el amplio sentido de la palabra.
Un esquema puede ser considerado como una colección (o vocabulario) de
definiciones de tipos y declaraciones de elementos cuyos nombres pertenecen a un
determinado espacio de nombres llamado espacio de nombres de destino. Los espacios
de nombres de destino hacen posible la distinción entre definiciones y declaraciones de
diferentes vocabularios.
2 Fundamentos
La recomendación XML Schema es uno de los últimos intentos para mejorar las
características de las DTD. Se publicó en 2001 por el W3C y la soportan un gran rango
de analizadores y aplicaciones XML.
Este sofisticado estándar emplea 42 elementos y 37 atributos (ver la Sección 20.2 y
la Sección 20.3 para la lista de elementos y atributos), definidos en una gran
especificación desarrollada por un amplio comité (con 35 contribuciones adicionales).
Se puede argumentar que no es un estándar especialmente elegante, sino que es
indudablemente poderoso. Este estándar está definido en tres partes, de las cuales la
primera sirve como una introducción a las otras dos, y es relativamente fácil de leer pero
no es exhaustivo en las características del lenguaje.
3 Características de XML Schema
La recomendación XML Schema fue desarrollado para superar a su predecesora en el
proceso de validación, DTD. XML Schema debe ser compatible con las características
de la DTD, usar sintaxis XML, recuperar características de las DTDs de SGML, y añade
características para validar los documentos.
Las instrucciones de XML Schema parecen bastante diferentes de las reglas de las
DTD. El estándar XML Schema es una aplicación XML, y cada regla es además un
132
Contribución al análisis XML para la mejora en las prestaciones de memoria
fragmento de documento XML. El fragmento de DTD podría traducirse en su
equivalente Schema, tal y como se muestra en la siguiente Figura.
<!ELEMENT Capitulo (titulo,seccion+)>
Figura D.79: Fragmento de DTD.
<element name=”Capitulo”>
<complexType>
<sequence>
<element ref=”B:titulo” />
<element ref=”B:seccion” minOccurs=”1”
maxOccurs=”unbounded” />
</sequence>
</complexType>
</element>
Figura D.80: Ejemplo de XML Schema.
Cualquier modelo de documento que pueda ser codificado con una DTD puede ser
especificado con el estándar XML Schema. Y además es posible automatizar la
conversión de una DTD en un equivalente documento XML Schema.
4 Definición
Un XML schema definition (XSD), o schema definition en breve, es una modelo de
documento que cumple un XML Schema. XSD es un documento XML que perfila y
modela el modelo de documento definido en el estándar XML Schema. Este modelo
incluye estructuras XML que declaran elementos y atributos, define tipos de datos y
permite comentarios para poder insertarse.
La gente que crea un XSD no es normalmente la misma gente que crea una
instancia del documento que la cumple. El término schema definition author puede
usarse para describir el que lo ha formado, y document instance author para describir un
ejemplo.
5 Procesadores de Schema
Un analizador XML con validación que incluya un procesador de schema puede validar
una instancia de un documento utilizando una definición de un esquema. Normalmente,
el procesador de esquema está integrado en el software de análisis del documento.
6 Tipos de Datos
Una característica importante del lenguaje XML Schema es la posibilidad de crear y
utilizar tipos de datos. Un tipo de dato restringe un valor a un rango o conjunto de
posibilidades que se deseen. Este concepto no añade nada nuevo en la construcción del
Apéndice D.
133
lenguaje XML, de esta forma un valor que realiza a un tipo de dato continúa
expresándose como un valor de atributo o como contenido de un elemento.
Hay dos tipos de datos soportados por el estándar:
Un tipo de dato simple que hace que una marca que no cumpla un valor y
tipo no se pueda asignar. El estándar incluye un número de tipos de datos
simples como “string” (“hola mundo”), “integer” (123), y “date” (“2002-0517”). Pero en la definición de un esquema se podrían crear tipos de datos
simples más específicos.
Un tipo de dato complejo que permite estructurar la información de una
forma más compleja. No hay tipos de datos complejos construidos, y para
utilizarlos habría que crearlos.
Asumiendo que una aplicación puede acceder e interrogar a la definición de un
esquema, este puede identificar estructuras comunes siempre y cuando estén definidas
en declaraciones de elementos separadas. Por ejemplo, podría ser posible, usando el
estándar XML Query, para contar todas las direcciones de e-mail sin conocer todos los
elementos usados en estas direcciones.
7 Elemento raíz
Un esquema es un documento XML que solo contiene texto y aparece con la extensión
.xsd. Comienza con una declaración XML estándar, seguida de una declaración del
espacio de nombre de XML esquema.
<?xml versión=”1.0“ ?>
<xsd:schema
xmnls:xsd=http://www.w3.org/2000/10/XMLSchema>
<!-- reglas del esquema -->
</xsd:schema>
Figura D.81: Elemento raíz en XSD.
El comienzo de un XML Schema es igual que el de cualquier documento XML,
<?xml versión=”1.0 “?>. El elemento raíz es <xsd:schema. Con
xmnls:xsd=“http://www.w3.org/2000/10/XMLSchema” se declara el
espacio de nombre del “esquema de esquemas. A partir de ahora cualquier documento o
escritura que aparezca con el prefijo xsd: delante será reconocido como si procediera de
este espacio de nombre.
8 XML Schema frente a DTD
Un esquema escrito con XML Schema es similar a una DTD, en la medida que se usa
para establecer el esquema de una clase de documentos XML. Al igual que ocurre con
134
Contribución al análisis XML para la mejora en las prestaciones de memoria
las DTD, el papel de los Esquemas XML consiste en describir los elementos y sus
modelos de contenido, de forma que los documentos puedan ser validados. No obstante,
XML Schema irá mucho más allá que las DTD, permitiendo asociar tipos de datos con
elementos y, finalmente, también con atributos.
En una DTD, el contenido de los elementos se limita a cadenas y a otros tipos de
datos primitivos. XML Esquemas soporta una amplia gama de tipos de datos, como
enteros, números de coma flotante, fechas y horas. XML Schema también incluye
soporte para otras características, como el modelo de contenido abierto y la integración
para espacios de nombres. Aparte de ofrecer estas características, XML Schema
contrasta mucho con las DTD, ya que se apoya en XML para marcar los documentos de
esquemas; digamos que un XML Schema que define la “apariencia” de un documento
XML está escrito con el propio lenguaje XML. Se trata de una mejora importante en
comparación con las DTD, ya que no implica tener que aprender un lenguaje críptico.
Sólo habrá que a aprender a usar el vocabulario XML Esquemas.
A continuación se muestra una lista de las principales ventajas que ofrece XML
Esquemas en comparación con las DTD:
XML Schema se basa en XML y no en una sintaxis especializada.
XML Schema puede ser analizado sintácticamente y manipulado como
cualquier otro documento XML.
XML Schema soporta la integración de los espacios de nombre, lo cual le
permite asociar nodos individuales de un documento con las declaraciones
de tipo de un esquema.
XML Schema soporta grupos de atributos, lo que le permite lógicamente
combinar atributos.
A pesar de todas estas ventajas, actualmente está más difundido el uso de las DTD,
seguramente por costumbre y facilidad. Pero, no es de extrañar que en un futuro no muy
lejano el uso de Esquemas reemplace al uso de las DTD.
Apéndice E.
Espacio de Nombres en XML
XML es un lenguaje que permite la creación de marcas formado elementos totalmente
personalizados. Esto es, el programador es el que dará nombre a todas las marcas de su
archivo XML, y estas marcas pueden llevar cualquier nombre (siempre que sea válido).
Cuando se crean elementos personalizados en un entorno cerrado no hay ningún
problema, ya que podemos elegir nosotros los nombres y asignar marcas con distinto
nombre de las ya utilizadas. El problema aparece cuando se mezclan muchos
vocabularios XML. Es aquí donde aparecen los espacios de nombres (XML
Namespaces) que se consideran en este apéndice.
1 Introducción
Supongamos que, por alguna razón, tenemos que mezclar dos (o más) documentos XML
en uno de mayor tamaño. Alguno de los elementos ubicados en los distintos archivos
pueden tener un mismo nombre. Los programadores necesitan un medio para poder
disponer de todos los elementos en un único documento de mayor tamaño. Para
solucionar esto es para lo que se crearon los espacios de nombres (namespace).
XML Namespaces es una iniciativa del W3C que no formaba parte de la
especificación XML 1.0 original. En esa época, el W3C todavía estaba terminando los
detalles sobre los espacios de nombre y cómo había que estructurarlos y usarlos en
XML. XML Namespaces consiguió el estatus de recomendación del W3C en enero de
1999, por lo que es una tecnología posterior. Sin embargo, ha sido adoptada con
prontitud, principalmente porque es necesaria, ya que la mayoría de desarrolladores
desean evitar el conflicto de nombres en documentos XML.
Un espacio de nombre puede tener el siguiente sintaxis:
<prefijo:nombreElemento />
prefijo hace referencia al espacio de nombres. Un espacio de nombre es un medio
diferente de nombrar los elementos, de tal manera que los elementos que tengan
nombres duplicados puedan diferenciarse unos de otros.
136
Contribución al análisis XML para la mejora en las prestaciones de memoria
2 Sintaxis
Puesto que estamos intentando solucionar el problema de tener dos elementos iguales
habrá que garantizar de alguna manera que los nombres de los elementos y atributos
XML que asignamos son completamente únicos. Para esto se utilizarán los
Identificadores de Recursos Universales (URI) [RFC 3986].
Se declara el espacio de nombre:
<cualquierElemento xmlns:nombreLocal= “URI”>
Para utilizar un espacio de nombre se deben manejar dos elementos: un nombre
local y un nombre real. Por ejemplo:
<documento xmlns:prefijo=”http://trajano.us.es/~antonio/">
El nombre local es utilizado en el documento XML (eso es precisamente el prefijo
que vimos en el apartado anterior, un nombre local del espacio de nombre, en este caso
“prefijo”). El nombre real de un espacio de nombre es el URI. Las URI tienen la
misma sintaxis que los URL, aunque no son lo mismo. Un URL debe apuntar a algún
recurso en Internet, mientras que un URI es simplemente una cadena de texto con el
aspecto de un URL; puede estar realmente apuntando a algo, o no. El nombre real de un
espacio de nombres debe ser único, en esa dirección no puede haber otro espacio de
nombres que tenga el mismo nombre real.
Dos referencias URI que identifican espacios de nombres son idénticas si son
exactamente las mismas carácter a carácter. Las referencias URI pueden contener
caracteres no permitidos en nombres, de modo que no pueden utilizarse directamente
como prefijos de espacios de nombres. Por tanto, el prefijo de espacio de nombres actúa
como intermediario de una referencia URI.
El nombre real también puede ser un URN [RFC 2141] (Universal Resource
Name), y la sintaxis sería como sigue:
<documento
xmlns:prefijo=”urn:http://trajano.us.es/~antonio/:mas">
Un Nombre de Recurso Uniforme (Uniform Resource Name, URN) es un Uniform
Resource Identifier (URI) que usa el esquema urn, y no contiene relación asociada con
la de identificación del recurso. Ambos URNs (nombre) y URLs (localizadores) son
URIs, y algún URI podría ser un nombre y un recurso a la vez.
Un URN sirve como identificador persistente, independiente de un recurso y está
diseñado para hacer más fácil el mapeo con otros espacios de nombres en el espacio
URN. La sintaxis URN proporciona un significado para codificar caracteres de datos en
una forma que puedan enviarse en los protocolos existentes, y que puedan escribirse en
distintos teclados, etc.
Apéndice E.
137
3 Declaración de espacios de nombres
Un espacio de nombres se declara usando una familia de atributos reservados. El
nombre de tales atributos debe o bien ser xmlns, o bien tener xmlns: como prefijo. Estos
atributos, como cualquier otro atributo XML, se pueden proporcionar directamente o
pueden tener un valor por defecto. Los espacios de nombre se declaran en los
documentos XML de la siguiente forma:
xmlns:Prefix=”NameSpace”
La palabra clave xmlns alerta a un procesador XML de que se está declarando un
espacio de nombre. Prefix sirve como referencia del espacio de nombres a lo largo del
alcance del elemento en el que se declara el espacio de nombres. Sin embargo, este
Prefix es opcional, y dependerá de si queremos usar un elemento cualificado o no
cualificado.
Un ejemplo de declaración de espacio de nombres, que asocia el prefijo de espacio
de
nombres
Tesis
con
el
nombre
de
espacio
de
nombres
http://trajano.us.es/~antonio/:
<x xmlns:Tesis='http://trajano.us.es/~antonio/'>
<!-- el prefijo "Tesis" está ligado
a http://trajano.us.es/~antonio/
para el elemento "x" y sus contenidos -->
</x>
Los prefijos que comiencen con la secuencia de tres letras x, m, l, en cualquier
combinación de mayúsculas y minúsculas, están reservados para su uso por las
especificaciones de XML y las relacionadas con ellas.
Un nombre cualificado es aquel que incluye la porción prefix en la declaración del
espacio de nombres. Consta de dos partes: el prefijo y la porción local del nombre. Para
utilizar nombres cualificados hay que incluir el prefix en la declaración del espacio de
nombres.
Según la norma un nombre cualificado sigue la siguiente sintaxis:
[6]
[7]
[8]
QName
Prefix
Prefix
(Prefix':')?LocalPart
NCName
NCName
Figura E.82: Sintaxis de los nombres cualificados.
En la tabla anterior el Prefix (prefijo) proporciona la parte del prefijo del espacio de
nombres del nombre cualificado, y debe estar asociado mediante una referencia URI a
un espacio de nombres en una declaración de espacio de nombres. LocalPart
proporciona la parte local del nombre cualificado.
Un nombre no cualificado es aquel que no incluye un prefijo, y está asociado con un
espacio de nombre predeterminado o no está asociado con ninguno. No se necesita el
138
Contribución al análisis XML para la mejora en las prestaciones de memoria
prefix de la declaración del espacio de nombre al declarar un espacio de nombre
predeterminado.
La porción NameSpace es donde se identifica el propio espacio de nombres. Será
un URI, para garantizar la singularidad en los elementos y atributos que se utilizan en el
ámbito de la declaración de espacios de nombre. La decisión de utilizar nombres
cualificados o nombres no cualificados determinará la forma en que declararemos los
espacios de nombre. Existen dos soluciones distintas para declarar espacios de nombre:
El espacio de nombres se declara sin prefijo, y se hace referencia a todos los
nombres y atributos que haya en su ámbito con nombres no cualificados y se presupone
que éstos se encuentran en el espacio de nombres, esto es: el elemento que declara el
espacio de nombre y todos sus descendientes son considerados parte de este espacio de
nombre predeterminado, aunque no lleve prefijo y parezcan un XML normal. Es la
solución más sencilla, y es útil cuando se quiere aplicar un espacio de nombre a un
documento completo o a una sección de un documento. Si la referencia URI de la
declaración de un espacio de nombres por defecto está vacía, entonces se considera que
los elementos sin prefijo pertenecientes al ámbito de la declaración no están en ningún
espacio de nombres. Obsérvese que los espacios de nombres por defecto no se aplican
directamente a atributos.
El espacio de nombres se declara con un prefijo, y todos los nombres de elementos
y atributos que estén asociados con el espacio de nombres deberán usar el prefijo como
parte de sus nombres cualificados. Este tipo de declaración resulta útil a la hora de crear
un documento que se apoya en múltiples espacios de nombre. El prefijo de una
declaración explícita se emplea como notación en el espacio de nombres que hay en el
ámbito donde se declara el espacio de nombres. Es decir, el prefijo se empareja con el
nombre del elemento o atributo locales, para formar un nombre cualificado de la forma:
Prefix:Local.
4 Qué son y qué no son los espacios de nombres
Los espacios de nombre son:
Contenedores para nombres de elementos y atributos: no contienen los
elementos mismos sino sus nombres.
Un sistema de denominación en dos partes, pues todos tienen un nombre
local y un nombre de espacio de nombre (URI). No existen realmente
como entidades físicas o conceptuales; no hacen nada excepto renombrar
ciertos elementos.
Los espacios de nombre no son…
Apéndice E.
139
Una vía para combinar documentos XML, ni un instrumento para lo mismo.
Es posible utilizar los espacios de nombre con este fin, sin embargo los
espacios de nombre en si mismos no lo son.
“punteros” a un sitio web. El URI de un espacio de nombre no apunta a
nada, son sólo identificadores, no páginas web ni archivos. No intente
ejecutar el URI: lo mejor que puede pasar es que no pase nada.
Lo mismo que los espacios de nombre tradicionales. Éstos son un grupo de
cero o más nombres únicos. Cada nombre es único y sigue reglas (si existen)
que gobiernan su apariencia.
No tienen una estructura. Son solamente un conjunto de nombres. Aunque
se defina un espacio de nombre para un grupo de elementos XML, y este
grupo tenga una estructura, el espacio de nombre mismo ni siquiera ve la
estructura. Conocerá su alcance (scope, se verá a continuación), pero no
verá la estructura de los descendientes del elemento.
Los elementos no se colocan automáticamente en un espacio de nombre. Si
no se define un espacio de nombres, los elementos no formarán parte de él.
Ciertos programas-instrumentos consideren el atributo xmlns como una
“declaración de espacio de nombre”, mientras que otros sólo lo ven como un
atributo. Por ejemplo, las DTD no ven los espacios de nombre, por tanto,
xmlns es considerado como un atributo más. Sin embargo, los documentos
de XML Esquema reconocen xmlns como una declaración de espacio de
nombre.
Apéndice F.
Servicios Web XML
Este apéndice define y muestra los estándares relacionados con los Servicios Web XML.
La premisa de las tecnologías de los servicios Web forma el siguiente paso lógico en la
evolución de la programación distribuida. Una de las razones de peso para adentrarse en
el mundo del desarrollo de los servicios Web es su alto nivel de interoperabilidad. La
llamada a un servicio Web es una operación independiente de la plataforma y lenguaje,
por lo que un cliente utilizando un lenguaje de programación puede llamara a un
servicio Web que utilice otro lenguaje.
1 Introducción
Según el W3C, un Servicio Web es un sistema software identificado mediante una URI
[RFC 2396], cuyas interfaces públicas asociadas se definen y describen usando XML.
Esta definición puede ser descubierta por otros sistemas software. Estos sistemas
podrían interactuar con los servicios Web de una forma preestablecida mediante su
definición, usando mensajes basados en XML con protocolos de Internet.
Los Servicios Web XML son una aproximación basada en estándares para la
integración e interoperabilidad, y es una evolución de los sistemas distribuidos. Un
Servicio Web XML se caracteriza por tres estándares.
1 Web Services Description Language (WSDL [WSDL ]) para definir un
Servicio Web.
2 Simple Object Access Protocol (SOAP[Haas 03] [Gudgin 03a] [Gudgin 03b])
para transportar el Servicio Web.
3 Universal Discovery Description and Integration (UDDI [UDDI v3.0]) para
catalogar o descubrir Servicios Web para reutilizarlos.
2 SOAP
Con la aparición de XML hacia la segunda mitad de los 90, los desarrolladores se
encontraron con la posibilidad de expresar una rica estructura de información y
mensajes de manera uniforme y autodescriptiva, lo que dio pie al uso de XML para
aplicar un formato a los mensajes de formato correcto entre sistemas de manera
142
Contribución al análisis XML para la mejora en las prestaciones de memoria
autodocumentada, autodescriptiva y extensible, independientemente del sistema
operativo o del entorno de lenguaje de los sistemas operativos.
Una de las implementaciones de protocolos de comunicaciones basados en XML
más conocidas es XML-RPC (XML-Remote Procedure Call), que permite llamar a
procedimientos de equipos remotos sin necesidad de tener en cuenta los detalles de sus
sistemas operativos o entornos de lenguaje. Estos equipos pueden encontrarse en
cualquier punto de Internet o dentro de la red interna del usuario mientras estén
conectados por HTTP. XML-RPC es pionero en su campo, aunque la mayoría de los
proveedores optaron por su sucesor SOAP (Simple Object Access Protocol).
SOAP es un protocolo ligero entendido para realizar el intercambio de información
descentralizada en un entorno distribuido. El transporte de SOAP puede realizarse con
una variedad de protocolos, que incluye HTTP, SMTP y FTP.
3 WSDL
WSDL proporciona la posibilidad de describir los servicios Web, permitiendo así su
proliferación. A pesar de que SOAP proporcionan una manera estándar de transportar
mensajes para el uso de servicios Web, no proporciona ninguna manera para describir el
formato que esos mensajes deberían tener en un determinado servicio Web.
Al comienzo de la especificación SOAP, cuando los desarrolladores empezaron a
implementar servicios Web basados en SOAP, se dieron cuenta de que el único modo de
que alguien conociera la manera de invocar un servicio Web era publicando una muestra
de documento SOAP que ilustrar una llamada al servidor Web en cuestión. El problema
con esta téncia es que no describía la manera de llamar al servicio Web. Por ejemplo, si
se piensa en un servicio Web de estilo RPC como una biblioteca a la que se quiera
llamar, con obtener simplemente un ejemplo de un documento SOAP equivaldría a que
alguien entregara una librería C++ y un código de ejemplo, pero sin un archivo de
encabezado o un servidor Java sin un IDL correspondiente.
WSDL surgió de los esfuerzos de Microsoft e IBM para paliar este problema.
WSDL busca la definición y descripción de servicios Web. WSDL proporciona una
gramática para la descripción de servicios como un conjunto de puntos finales que
intercambian mensajes. Uno de los conceptos principales detrás de estas descripciones
es la idea de que existe una diferencia entre la definición abstracta de un mensaje y la
manera concreta en al cual esos mensajes se asignan a un transporte específico y a un
protocolo de codificación de datos.
4 UDDI
Un servicio Web es una aplicación o componente independiente que tiene las
características de que se describe en un lenguaje de descripción de servicios y esta
Apéndice G.
143
descripción se puede publicar. Los programas clientes pueden encontrar estas
descripciones, unirse al servicio descrito y finalmente invocar a los servicios. UDDI
proporciona la pieza de registro en esta pila. UDDI define los criterios para los registros
basados en la Web. Las compañías pueden registrar la información en estos registros
acerca de sí mismas, sobre los servicios que ofrecen y la información técnica cómo se
puede acceder a estos servicios. También pueden buscar el registro de otras compañías o
proveedores de servicios. Estos registros pueden ser de un ordenador privado o el
registro global de UDDI Business Registry.
Tres empresas, IBM, Microsoft y Ariba empezaron con la iniciativa UDDI. Su
objetivo era definir criterios para permitir que las empresas se descubriesen las unas a
las otras, que interactuasen y compartieran información en un registro global.
Se pretendía basar UDDI en estándares y que se utilice entre plataformas. Se
construye sobre estándares existentes de Internet de XML, HTTP y DNS (Domain Name
System). desde entonces, otras compañías se han unido
UDDI se diseñó para solucionar los problemas en las interacciones empresaempresa (B2B), proporciona un mecanismo para realizar una “búsqueda inteligente” de
servicios Web y permitir una agregación más sencilla de los servicios. UDDI utiliza
SOAP como su dimensión de transporte.
Apéndice G.
Otras Medidas
1 Introducción
Este apéndice presenta otras medidas obtenidas en la validación del modelo del
prototipo implementado. Se presenta, en primer lugar el número de objetos que se
generan en el análisis de los documentos de distinto tamaño para los analizadores
eligidos en las pruebas presentadas en el capítulo de validación del modelo.
2 Número de objetos
El número de objetos que se utilizan para realizar para el fichero de 1728 bytes.
10000
9000
8000
Objectos
7000
6000
5000
4000
3000
2000
1000
0
kXML
FCM
TAMparser
Xparse-J
Figura H.83: Número de objetos utilizados en ficheros de 1728 bytes.
Los analizadores son, al igual que antes kXML2, como representación del modelo Pull;
TAMparser como representación del modelo Push; y Xparse-J para el modelo DOM.
Estas medidas se comparan con la implementación realizada.
146
Contribución al análisis XML para la mejora en las prestaciones de memoria
10000
9000
8000
Objetos
7000
6000
5000
4000
3000
2000
1000
0
kXML
FCM
TAMparser
Xparse-J
Figura H.84: Número de objetos utilizados en ficheros de 24458 bytes.
Existe una gran correlación entre la cantidad de memoria utilizada y el número de
objetos utilizado. Aunque la cantidad de memoria utilizada si es un factor crítico el
número de objetos lo es en cuanto a la repercusión que tiene en cuanto a la memoria que
se utiliza. La implementación kXML2 presenta el menor número de objetos generados
en el proceso de análisis. La implementación Xparse-J presenta el mayor número de
objetos creados en comparación con los otros analizadores. La implementación
realizada presenta un número de objetos cercano al analizador kXML2.
Referencias
1. Introducción
Las referencias están clasificadas dependiendo de su soporte web o no y de los
organismos que lo mantienen. Primero se presentan las referencias de libros,
posteriormente congresos/revistas, las siguen las referencias del autor, referencias
mantenidas por los organismos (W3C, ISO, Unicode OASIS, RFC), luego las
referencias a software y por último las referencas web.
2. Libros
[Andersson 01]
Christoffer Anderson (2001). GPRS and 3G wireless applications. John
Wiley & Sons. ISBN: 0471414050.
[Behme 98]
Henning Behme, Stefan Mintert. XML in der Praxis: Professionelles
Web-Publishing mit der Extensible Markup Language. Bonn: Addison
Wesley Longman, 1998.. ISBN 3-8273-1330-9.
[Born 01]
Günter Born, Compendium HTML: con XHTML, DHTML, CSS, XML,
XSL y WML. Barcelona: Marcombo, 2001. ISBN: 8426713084.
[Bradley 03]
Neil Bradley, The XML schema companion. Addison-Wesley, 2003
ISBN: 0-321-13617-9.
[Bray 99]
Jennifer Bray and Charles F. Sturman, Bluetooth: Connect without
cables. Prentice Hall PTR, cop. 2002 ISBN: 0-13-066106-6.
[Bradley 98]
Neil Bradley, The XML Companion. Harlow, Essex: Addison Wesley
Longman, 1998. ISBN: 0-201-41999-8.
[Cohen 90]
Daniel I.A. Cohen, Introduction to Computer Theory, John Wiley &
Sons, Inc., 1990. ISBN: 0-471-51010-6.
[Connolly 97]
Dan Connolly. XML: Principles, Tools, and Techniques. World Wide
Web Journal [edited by Rohit Khare] Volume 2, Issue 4. Sebastopol, CA:
O'Reilly & Associates, Inc., Fall 1997. ISBN: 1-56592-349-9. ISSN:
148
Contribución al análisis XML para la mejora en las prestaciones de memoria
1085-2301.
[Chen 00]
Zhinqun Chen, Java Card Technology for Smart Cards: architecture and
programmer’s guide. Addison-Wesley, 2000.ISBN: 0-201-70329-7.
[DeRose 97]
Steven J. DeRose. The SGML FAQ Book: Understanding the Foundation
of HTML and XML. Electronic Publishing Series, Number 7.
Dordrecht/Boston/London: Kluwer Academic Publishers, 1997. ISBN: 07923-9943-9.
[DuCharme 99]
Bob DuCharme. XML: The Annotated Specification. The Charles F.
Goldfarb Series on Open Information Management. The Definitive XML
Series from Charles F. Goldfarb. Upper Saddle River, NJ: Prentice Hall
PTR, 1999. ISBN: 0-13-082676-6.
[Gibb 03]
Brian Gibb, Suresh Damodaran, ebXML: concepts and application,
Indianapolis, IN: Wiley, cop. 2003. ISBN: 0-764-54960-X.
[Feng 01]
Yu Feng and Jun Zhu, Wireless Java Programming with Java 2 Micro
Edition, Indianapolis, IN: Sams, cop.2001. ISBN: 0-672-32135-1.
[Flynn 98]
Peter Flynn, Understanding SGML and XML Tools. Practical Programs
for Handling Structured Text.. Foreword by Steve DeRose. Kluwer
Academic Publishers SGML Bookshelf, Electronic Publishing Series.
Dordrecht, Boston, & London: Kluwer Academic Publishers, 1998.
ISBN: 0-7923-8169-6.
[Friedl]
Jeffrey E. F. Friedl, Mastering Regular Expressions, O'Reilly. ISBN:
0596002890.
[Goldfarb 04]
Charles F. Goldfarb, Paul Prescod, XML Handbook, Prentice-Hall PTR,
2004, ISBN 0130497657.
[Graham 02]
Steve Graham, Dimeon Simeonov, Toufic Boubez, Doug Davis, Glen
Daniels, Yuichi Nakamura, Ryo Neyama, Building web services with
Java : making sense of XML, SOAP, WSDL, and UDDI, Indianapolis,
Referencias.
149
Ind. : Sams, 2002. ISBN: 0-672-32181-5.
[Graham 99]
Ian Graham ad Liam Quin, XML Specification Guide. John Wiley and
Sons (1999), ISBN: 0471327530.
[Graham 95]
Ian S. Graham, The HTML Sourcebook, John Wiley and Sons, (1995),
ISBN: 0-471-11849-4.
[Gray 69]
James Gray, Precedence Parsers for Programming Languages, Ph. D.
Thesis. Department of Computer Science University of California,
Berkeley, California, 1969.
[Holman 02]
G. Ken Holman, Definitive XSLT and Xpath. Upper Saddle River, NJ :
Prentice Hall PTR, cop.2002 ISBN: 0-13-065196-6.
[Holma 00]
Harri Holma, Antti Toskala, WCDMA for UMTS: radio access for third
generation mobile communications. John Wiley and Sons, 2000. ISBN:
0-471-72051-8.
[Holub 90]
Allen I. Holub, Compiler Design in C, Englewood Cliffs, N.J. PrenticeHall International, 1990. ISBN: 0-13-155151-5.
[Jelliffe 98]
Rick Jelliffe.The XML and SGML Cookbook. Recipes for Structured
Information. The Charles F. Goldfarb Series on Open Information
Management. Upper Saddle River, NJ: Prentice Hall PTR, May 1998.
ISBN: 0-13-614223-0.
[JVM]
The Java(TM) Virtual Machine Specification (2nd Edition) by Tim
Lindholm, Frank Yellin, http://java.sun.com/docs/books/vmspec/.
[Kaaranen 01]
Heikki Kaaranen, UMTS networks: Architecture, mobility and services
John Wiley and Sons, cop.2001. ISBN: 0-471-48654-X.
[Knuth 73]
Knuth, Donald, Stacks, Queues and Dqueues, in The Art of Computer
Programming, Volume 1, Addison-Wesley, 1973.
[Knudsen 03]
Jonathan Knudsen, Wireless Java: developing with J2ME. Berkeley, CA:
Apress, cop.2003. ISBN: 1-59059-077-5.
[Kotok 03]
Alan Kotok, David R. R. Webber, ebXML: The New Global Standard for
150
Contribución al análisis XML para la mejora en las prestaciones de memoria
Doing Business Over the Internet. Sams, 2001, ISBN-10: 0-7357-1117-8.
[Leventhal 98]
Michael Leventhal, David Lewis, and Matthew Fuchs; with contributions
from Stuart Culshaw and Gene Kan Designing XML Internet
Applications. Prentice Hall PTR, 1998. ISBN: 0-13-616822-1.
[Lobin 99]
Henning Lobin, Informationsmodellierung in XML und SGML.
Berlin/Heidelberg: Springer-Verlag, 1999. ISBN: 3-540-65356-2.
[Light 97]
Richard Light, Simon North, Charles Allen (et al.). Presenting XML.
Indianapolis, IN: SAMS.NET 1997. ISBN: 1-57521-334-6.
[McGrath 98]
Sean McGrath. XML by Example. Building E-Commerce Applications.
The Charles F. Goldfarb Series on Open Information Management. The
Definitive XML Series from Charles F. Goldfarb. Upper Saddle River,
NJ: Prentice Hall PTR, June 1998. ISBN: 0-13-960162-7
[Megginson 98] David Megginson. Structuring XML Documents. Charles F. Goldfarb
Series on Open Information Management. The Definitive XML Series
from Charles F. Goldfarb. Upper Saddle River, NJ: Prentice Hall PTR,
[March] 1998. ISBN: 0-13-642299-3.
[Makoto 98]
Murata Makoto, Atsuhito Momma, and Kyoichi Arai. Introduction to
XML. 1998. ISBN: 4-532-14610-0.
[Nagappan 03]
Ramesh Nagappan, Robert Skoczylas, Rima Patel Sriganesh;
“Developing java web services: Architecting and developing secure web
services using java”, Wiley, 2003. ISBN: 0-471-23640-3.
[Nicholas 03]
Nick Nicholas, John Cowan, What Is Lojban?: .i la lojban. mo . Logical
Language Group 2003. ISBN is 0-9660283-1-7.
[Piroumian 02]
Vartan Piroumian, Wireless J2ME platform programming, Palo Alto,
Calif.: Sun Microsystems, 2002. ISBN:0-130-44914-8.
[Révész 91]
György E. Révész. Introduction to formal languages. Dover Publications,
Referencias.
151
Inc., New York. 1991. ISBN: 0-486-66697-2
[Riggs 01]
Roger Riggs, Antero Taivalsaari, Mark VandenBrink, editor, foreword by
James Gosling. Programming wireless devices with the Java 2 platform,
micro edition: J2ME Connected Limited Device Configuration (CLDC),
Mobil Information Device Profile (MIDP). Boston MA [etc] : AddisonWesley, 2001. ISBN: 0-201-74627-1.
[Singhal, 01]
Singhal, S. WAP the Wireless Application Protocol: Writing
Applications for the Mobile Internet. Addison-Wesley. 2001. ISBN:
0201703114
[Skonnard 02]
Aaron Skonnard, Martin Gudgin. Essential XML quick reference: a
programmer's reference to XML, XPath, XSLT, XML Schema, SOAP,
and more. Boston, Addison-Wesley, 2002. ISBN: 0201740958.
[Stayton 05]
Bob Stayton, DocBook XSL: The Complete Guide (3rd Edition) Sagehill
Enterprises, 2005. http://www.sagehill.net/docbookxsl/.
[St. Laurent 01]
Simon St. Laurent, Joe Johnston, Edd Dumbill. Programming web
services with XML-RPC. O'Reilly, 2001. ISBN: 0596001193.
[St. Laurent 98]
Simon St. Laurent, XML A Primer. Foster City, CA: MIS Press/IDG
Books, 1998. ISBN: 1-5582-8592-X.
[St. Laurent 99a] Simon St. Laurent y Robert Biggar Inside XML DTDs: Scientific and
Technical. New York, NY: McGraw-Hill, 1999. ISBN: 0-07-134621-X.
[St. Laurent
Simon St. Laurent y Ethan Cerami, Building XML Applications. New
99b]
York, NY: McGraw-Hill, (May) 1999. ISBN: 0-07-134116-1.
[St. Laurent 05]
Simon St. Laurent, Michael Fitzgerald. XML Pocket Reference, Third
Edition. 2005. ISBN: 0-596-10050-7.
[Taivalsaari 01]
Antero Taivalsaari, Mark VandenBrink, Jim Holliday. Programming
wireless devices with the Java 2 platform, micro edition: J2ME
152
Contribución al análisis XML para la mejora en las prestaciones de memoria
Connected Limited Device Configuration (CLDC), Mobil Information
Device Profile (MIDP). Addison-Wesley, 2001. ISBN: 0-201-74627-1.
[Topley 02]
Kim Topley, J2ME in a nutshell: a desktop quick reference. O'Reilly,
2002. ISBN: 0-596-00253-X.
[Walsh 06]
Norman Walsh and Leonard Muellner. DocBook: The Definitive Guide
V2.0.13. Beijing ; Sabastopol, CA : O'Reilly & Associates, 2006, ISBN:
1-565-92580-7.
[White 02]
Chuck White. Mastering XSLT. Sybex, cop. 2002, ISBN: 0-782-14094-7.
[Wong 01]
Hinkmond Wong, Developing Jini applications using J2ME technology.
Boston: Addison-Wesley, 2002. ISBN: 0-201-70244-4.
[Tittel 98]
Ed Tittel, Norbert Mikula, and Ramesh Chandak, XML for Dummies.
Foster City, CA: IDG Books Worldwide, Inc., 1998. ISBN: 0-7645-0360X.
Referencias.
153
3. Revistas, Congresos
[Beck 00]
Brian Beck, Stuart Gill, Norbert Lindenberg and John O'Conner, Java
Internationalization Roadmap, Sixteenth International Unicode
Conference, Amsterdam, Holland, March 27-30, 2000.
[Bisdikian, 01]
Bisdikian, C. An Overview of the Bluetooth Wireless Techonology. IEEE
Communications Magazine, pages 86-94, 2001.
[Brzozowski]
Brzozowski, J., Derivatives of regular expressions. Journal of the ACM,
11(4):481–494, Oct. 1964.
[Carroll 01]
Carroll, Jeremy J., CoParsing of RDF & XML, HP Laboratories Bristol,
2001
[Chiu 02]
Kenneth Chiu, Madhusudhan Govindaraju, Randall Bramley,
Investigating the limits of SOAP Performance for Scientific Computing,
11th IEEE International Symposium on High Performance Distributed
Computing HPDC-11 2002, p. 256. IEEE Computing Society, July 2002.
[Conway 63]
Conway, Melvin E., Design of a Separable Transition-Diagram Compiler,
CACM Vol 6 No. 7, July 1963.
[Conway 93]
Alan Conway, Page grammars and page parsing. A syntactic approach o
document layou recognition, In Proc. of 2nd International Conference on
Document Analysis and Recognition (ICDAR '93), pages 761-4, Los
Alamitos, CA, 1993. IEEE Compu. Soc. Press.
[Coombs 87]
Coombs, J. H., Renear, A. H., and DeRose, S. J., Markup systems and the
future of scholarly text processing, Communications of the Association
for Computing Machinery 30, 11 (1987), 933–947.
[Davids 98]
E. Davids, Java object serialization in parsable ascii, 1998. AUUGVic/CAUUG: Summer Chapter Technical Conference 98.
154
Contribución al análisis XML para la mejora en las prestaciones de memoria
[Lécluse 96]
Christophe Lécluse, Event Driven or Tree Manipulation Approaches to
SGML Transformation, You should not have to Choose, SGML'96 GCA
conference, 18-24 Nov 96, Boston
[Davis 90]
Davis M., Collins L., Unicode. Conference Proceedings. IEEE
International Conference on Systems, Man and Cybernetics, 4-7 Nov. pp.
499, 1990.
[DeRose 99]
Steven J. DeRose, Andries van Dam, Document structure and markup in
the FRESS hypertext system, Markup Languages: Theory & Practice,
Publisher: MIT Press, 1999.
[Farreres 02]
Javier Farreres, Cristian Tornador, Further development of OpenJade,
Extreme Markup Language 2002.
[Fowler 02]
Fowler, Martin, Public versus Published Interfaces, IEEE Software,
March-April 2002, pp. 18-19.
[Gong, 01]
Gong, L., JXTA: A Network Programming Evnironment. IEEE Internet
Computing, pages 88-85, 2001.
[Gorman 04]
Ian E. Gorman.Generic XML Stream Parser API: An Easier Way to Use
SAX and Xerces. Extreme Markup Language 2004.
[Graham 02]
Steve Graham, Building web services with Java: making sense of XML,
SOAP, WSDL, and UDDI. Indianapolis, Ind.: Sams, 2002. ISBN 0-67232181-5.
[Guo 03]
By Ping Guo, Julie Basu, Mark Scardina, and K. Karun, Parsing XML
Efficiently. Choose the right XML parsing technique for your Java
applications. Oracle Magazine September/October 2003.
[Krupnikov 03]
K. Ari Krupnikov, STnG — a Streaming Transformations and Glue
framework, Extreme Markup Languages 2003.
[Harold 04]
Elliotte R. Harold, XOM Design Principles, Extreme Markup Languages
Referencias.
155
2004.
[Helal, 02a]
Sumi Helal. “Pervasive Java”. IEEE Pervasive Computing, pages 82-85,
2002.
[Helal, 02b]
Sumi Helal, Pervasive Java. Part II, IEEE Pervasive Computing, AprilJune 2002, pages 85-89.
[Helal, 02c]
Helal, S. Standards for Service Discovery and Delivery. IEEE Pervasive
Computing, pages 95-100, 2002.
[Herlihy 82]
M. Herlihy and B. Liskov. A Value Transmission Method for Abstract
Data Types. ACM Trans. on Programming Languages and Systems,
4(4):527--551, Oct. 1982. 27.
[Kawaguchi 02]
Kohsuke Kawaguchi Translating Relational Schemas to XML Schemas
Extreme Markup Languages 2002.
[Link 80]
Digital Research Incorporated: Link-80 Operator's Guide, 1980 (A
programmer's guide for the CP/M operating system)
[Lyons 03]
Robert C. Lyons, The difficulty of schema conformance problems,
Extreme Markup Languages 2003.
[Matzen 99]
R.W. Matzen, A new generation of tools for SGML, Markup Languages:
Theory & Practice, Publisher: MIT Press, 1999.
[Murata 97]
M. Murata, Transformation of documents and schemas by patterns and
contextual, In C. Nicholas and D. Wood, editors, Proceedings of the
Third International Workshop on Principles of Document Processing
(PODP 96), pp 153--169, Heidelberg, 1997. Springer-Verlag. Lecture
Notes in Computer Science 1293.
[Murata 98]
M. Murata, Data model for document tranformation and assembly, In
E.V. Munson, C. Nicholas, and D.Wood, editors, Proceedings of the
Fourth International Workshop on Principles of Digital Document.
156
Contribución al análisis XML para la mejora en las prestaciones de memoria
Processing (PODDP 98), pages 140--152, Heidelberg, Germany, 1998.
Springer-Verlag. Lecture Notes in Computer Science 1481.
[Murata 00a]
M. Murata, D. Lee, and M. Mani, Taxonomy of XML schema languages
using formal language theory, Extreme Markup Languages, 2000.
[Murata 00b]
M. Murata. Hedge automata: A formal model for XML schemata. Webpublished manuscript, 2000.
[Murata 01]
M. Murata, Extended path expressions for XML, In Proceedings of the
Twenteenth ACM SIGACT-SIGMOD-SIGART Symposium on
Principles of Database Systems, May 21-23, 2001, Santa Barbara,
California, USA. ACM, 2001.
[Murata 03]
M. Murata, A. Tozawa, M. Kudo, and S. Hada, XML access control
using static analysis, In Proceedings of the 10th ACM conference on
Computer and communication security, pages 73--84. ACM Press, 2003.
[Nakajima 01]
Nobuo Nakajima y Yasushi Yamao, Development for 4th generation
mobile communications, Wireless Communications and Mobile
Computing. Mob. Comp. 2001; 1:3-12
[Opyrchal 99]
Lukasz Opyrchal , Atul Prakash, Efficient Object Serialization in Java.
ICDCS Workshop on Electronic Commerce and Web-Based
Applications, 1999.
[Ortiz 02]
Ortiz, E.C. (2002). A Survey of J2ME Today. Technical report, Wireless
Java.
[Ousterhout 90]
Ousterhout, J. K., TCL: An Embeddable Command Language,
Proceedings of the USENIX Association Winter Conference. 1990.
[Ramalho 02]
Ramalho, José Carlos, Jorge Gustavo Rocha, José João Almeida, y Pedro
Henriques, SGML documents: Where does quality go?, Markup
Languages: Theory & Practice 1.1 (1999): 75-90.
Referencias.
[Renear 01]
157
Renear, A., Raising the bar: Text encoding from a logical point of view.
CLIP 2001: Computers, Literature, Philology, Gerhard-Mercator
University, Duisburg, Germany, 2001.
[Sasaki 05]
Felix Sasaki, Christian Lieske, Andreas Witt, Schema Languages &
Internationalization Issues: A survey, Extreme Markup Language 2005.
[Schatz 96]
Schatz, B., Mischo, W. H., Cole, T. W., Hardin, J. B., Bishop, A. P., and
Chen, H. 1996. Federating diverse collections of scientific literature.
Computer 29 (May 1996), 28–36.
[Simons 97]
Simons, Gary F., Conceptual Modeling versus Visual Modeling: A
Technological Key to Building Consensus, CHum 30.4: 303-319.
[Simons 99]
Simons, Gary F., Using Architectural Forms to Map TEI Data into an
Object-Oriented Database, CHum 33.1-2: 85-101. Originally delivered in
1997 at the TEI 10 conference in Providence, R.I.
[Sperberg-
Sperberg-McQueen, C. M., Text in the Electronic Age: Textual Study
McQueen 01a]
and Text Encoding, with Examples from Medieval Texts, Literary and
Linguistic Computing, 6:1, 34-46.
[Sperberg-
Sperberg-McQueen, C. M., Claus Huitfeldt, and Allen Renear, Meaning
McQueen 01b]
and interpretation of markup, Markup Languages: Theory & Practice 2.3
(2001): 215-234. http://www.w3.org/People/cmsmcq/2000/mim.html
[Sperberg-
Sperberg-McQueen, C. M., Claus Huitfeldt, and Allen Renear. 2001.
Mcqueen 01c]
Practical extraction of meaning from markup, Paper given at ACH/ALLC
2001, New York, June 2001.
[Sperberg-
C. M. Sperberg-McQueen, David Dubin, Claus Huitfeldt and Allen
Mcqueen 02a]
Renear, Drawing inferences on the basis of markup. Extreme Markup
Languages 2002
[Sperberg-
C. M. Sperberg-McQueen, What matters?. Presented at Extreme Markup
158
Contribución al análisis XML para la mejora en las prestaciones de memoria
Mcqueen 02b]
Languages 2002.
[Sperberg-
C. M. Sperberg-McQueen, Logic grammars and XML Schema. Extreme
Mcqueen 03]
Markup Languages 2003.
[Sperberg-
C. M. Sperberg-McQueen, Eric Miller. On mapping from colloquial
Mcqueen 04]
XML to RDF using XSLT. Extreme Markup Languages 2004.
[Sperberg-
Applications of Brzozowski derivatives to XML Schema processing.
Mcqueen 05b]
Extreme Markup Languages 2005.
[Sperberg-
C. M. Sperberg-Mcqueen, XML and Semi-Structured Data, ACM Queue
Mcqueen 05]
vol. 3, no. 8 - October 2005.
[Satyanarayanan
Satyanarayanan, M. (2001). Pervasive computing: Vision and challenges.
01]
IEEE Personal Communications, 8(4):10-17.
[Thompson 01]
Thompson, Henry S., Normal Form Conventions for XML
Representations of Structured Data, Talk at XML 2001, Orlando, 2001.
http://www.ltg.ed.ac.uk/~ht/normalForms.html
[Thompson 03]
Thompson, Henry S., and Richard Tobin, Using finite state automata to
implement W3C XML Schema content model validation and restriction
checking. XML Europe 2003, London. Available online at
http://www.idealliance.org/papers/dx_xmle03/papers/02-02-05/02-0205.html (imperfectly rendered) or at
http://www.ltg.ed.ac.uk/~ht/XML_Europe_2003.html.
[Thompson 05]
Thompson, Henry. MT Pipeline: A Public Service and a New Product.
Presentation at XTech 2005. Amsterdam, Netherlands, 2005.
[Walsh 02]
Norman Walsh, Generalized Metadata in your Palm, Extreme Markup
Language 2002
[Walsh 04]
Norman Walsh, Extreme DocBook, Extreme Markup Language 2004
[Weiser 91]
Weisses M, The computer for the 21st Century, Scientific American,
Referencias.
159
1991.
[Welty 01]
Vorthmann, Scott, and Jonathan Robie. 2001. Beyond schemas: Schema
adjuncts and the outside world, Markup Languages: Theory & Practice
2.3: 281-294.
[Welty 97]
Welty, Christopher, and Nancy Ide, Using the Right Tools: Enhancing
Retrieval from Marked-up Documents, CHumy 33: 59-84. Originally
delivered in 1997 at the TEI 10 conference in Providence, R.I.
[Wilmott c03]
Sam Wilmott, What programming language designers should do to help
markup processing, , Montreal, Canada, Extreme Markup Languages
2003, Agosto 2003
[Wilmott d02]
Sam Wilmott, The Dichotomy of Markup Languages, Montreal, Canada,
Extreme Markup Languages 2002, Agosto 2002,
http://www.mulberrytech.com/Extreme/Proceedings/html/2002/Wilmott0
1/EML2002Wilmott01.html.
[Wilmott e04]
Sam Wilmott, All About Pattern Matching, Montreal, Canada, Extreme
Markup Languages 2004, Agosto 2004,
http://www.mulberrytech.com/Extreme/Proceedings/html/2004/Wilmott0
1/EML2004Wilmott01.html
[Wood 99]
Lauren Wood, Programming marked-up documents, Markup Languages:
Theory & Practice, Publisher: MIT Press, 1999.
[Wu 02]
Wu, P.C. (2002) A Page-shift Transformation Format of ISO 10646.
Software-Practice and Experience.
160
Contribución al análisis XML para la mejora en las prestaciones de memoria
4. Referencias del autor
[Sierra a05]
Antonio J. Sierra, Fco Prieto, A comparative study of delay for
transmission images for a mobile devices over HTTP, IADAT Journal of
advanced technology IADAT.
[Sierra b05]
Antonio J. Sierra, Antonio Albéndiz, Comparative study of methods of
serialization at J2ME, The 14th IASTED International Conference on
APPLIED SIMULATION AND MODELLING ~ASM 2005~ June 1517, 2005 Benalmádena, Spain.
[Sierra c05]
Antonio J. Sierra, Fco Prieto, A comparative study of delay for
transmission images for a mobile devices over HTTP, in IADATmicv2005 International Conference on Multimedia, Image Processing
and Computer Vision, Madrid, pp.68-72, 2005. (ISBN: 84-933971-5-6)
[Sierra 05]
Antonio J. Sierra, Miguel Castanedo, Propuesta de un Modelo de
Generación de Firma digital XML en dispositivos móviles, I SIMPOSIO
ESPAÑOL SOBRE SEGURIDAD INFORMÁTICA (CEDI’2005),
Granada 2005.
[Sierra d05]
Antonio J. Sierra, Alberto Oliva, Propuesta de un Modelo SAML
aplicado a los Servicios Web Seguros para Dispositivos Móviles, I
CONGRESO ESPAÑOL DE INFORMÁTICA (CEDI’2005), Granada
2005.
[Sierra e05]
Antonio J. Sierra, A New Paradigm to Parse XML based on Free Cursor
Mobility, Montreal, Canada, Extreme Markup Languages 2005, Agosto
2005.
[Sierra f05]
Antonio J. Sierra,A Page-Shift Transformation format of ISO 10646 for
16-bits code units , IST2005, International Symposium on
Telecommunications, Shiraz, Iran, 2005.
Referencias.
[Sierra g05]
161
Antonio J. Sierra, StSOAP:Streaming API for SOAP, The Second
International Conference on Innovations in Information Technology
(IIT'05), Dubai, UAE, 2005.
[Sierra h05]
Tutor: Antonio J. Sierra, Autor: Miguel Villalobos, XML2J2ME:
Implementación de los tipos de datos XML Schema para la plataforma
J2ME, Proyecto Final de Carrera.
[Sierra i03]
Tutor: Antonio J. Sierra, Autor: Alberto Fernández Fernández
Implementación de una aplicación de correo electrónico sobre la
plataforma J2ME utilizando el protocolo SOAP", Proyecto Final de
Carrera.
[Sierra j04]
Tutor: Antonio J. Sierra, Autor: Manuel Valenzuela Romero
Implementación de tarjetas inteligentes con tecnología Java Card,
Proyecto Final de Carrera.
[Sierra k05]
Tutor: Antonio J. Sierra, Autor: José Pablo Soriano Canela,
Implementación de los protocolos JXTA sobre la plataforma J2ME
(JXME), Proyecto Final de Carrera.
[Sierra l04]
Tutor: Antonio J. Sierra, Autor: Isaac David Gutiérrez Pulgarín, Estudio
y prueba de una arquitectura Grid de servicios web sobre Jini, Proyecto
Final de Carrera.
[Sierra m03]
Tutor: Antonio J. Sierra, Autor: Javier Feijóo Casas, Emulación de un
puerto serie virtual sobre una conexión Bluetooth, Proyecto Final de
Carrera.
[Sierra n04]
Tutor: Antonio J. Sierra, Autor: Francisco Prieto Piñero, Cliente para la
recepción de imágenes de vídeo en dispositivos móviles usando CLDC
sobre J2ME, Proyecto Final de Carrera.
[Sierra ñ05]
Tutor: Antonio J. Sierra, Autor: David Álvarez Suárez, Cliente para la
recepción de imágenes de vídeo en dispositivos móviles usando CDC
162
Contribución al análisis XML para la mejora en las prestaciones de memoria
sobre J2ME, Proyecto Final de Carrera.
[Sierra o02]
Tutor: Antonio J. Sierra, Autor:Manuel González Martins, Aplicación de
la telefonía de Java utilizando JTAPI, Proyecto Final de Carrera.
[Sierra p04]
Tutor: Antonio J. Sierra, Autor: Antonio Albéndiz Varela, Aplicación de
la serialización sobre J2ME, Proyecto Final de Carrera.
[Sierra q05]
Tutor: Antonio J. Sierra, Autor: Francisco Javier Fernández González,
Aplicación de Jini a entornos domóticos, Proyecto Final de Carrera.
Referencias.
163
5. Recomendaciones W3C
[Adler 01]
Sharon Adler y colaboradores, Extensible Stylesheet Language (XSL)
Version 1.0, W3C Recommendation 15 October 2001,
http://www.w3.org/TR/xsl/.
[Binary]
XML Binary Characterization Working Group Public Page,
http://www.w3.org/XML/Binary/.
[Biron 01]
Paul V. Biron and Ashok Malhotra, XML Schema Part 2: Datatypes, w3c
Recommendation 02 May 2001, http://www.w3.org/TR/2001/RECxmlschema-2-2001/REC-xmlschema-2-20010502/.
[Bray 99]
Tim Bray, Dave Hollander and Andrew Layman, Namespaces in XML,
World Wide Web Consortium 14-January-1999,
http://www.w3.org/TR/REC-xml-names.
[Bray 04a]
Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler, François
Yergeau (editors), W3C. Extensible Markup Language (XML) 1.0 (Third
Edition),W3C Recommendation 04 February 2004,
http://www.w3.org/TR/REC-xml.
[Bray 04b]
Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler, François
Yergeau (editors), Extensible Markup Language (XML), W3C
Recommendation 04 February 2004, edited in place 15 April 2004,
http://www.w3.org/TR/xml11/.
[Clark 99]
James Clark, XSL Transformations (XSLT) Version 1.0, W3C
Recommendation 16 November 1999, http://www.w3.org/TR/xslt.
[CDF 04]
Compund document formats, http://www.w3.org/2004/CDF/.
Cowan, John, and Richard Tobin, ed. 2001. XML Information Set, W3C
[Cowan 01]
Recommendation 24 October 2001. [Cambridge, Sophia-Antipolis,
Tokyo]: World Wide Web Consortium. http://www.w3.org/TR/xml-
164
Contribución al análisis XML para la mejora en las prestaciones de memoria
infoset/
Arnaud Le Hors, Philippe Le Hégaret, Lauren Wood, Gavin Nicol,
[DOM Level 2]
Jonathan Robie, Mike Champion, Steve Byrne, Document Object Model
(DOM) Level 2 Core Specification. Version 1.0, W3C Recommendation
13 November, 2000. http://www.w3.org/TR/DOM-Level-2-Core/javabinding.html
[dom2events 00] Document Object Model (DOM) Level 2 Events Specification, W3C
Recommendation, T. Pixley, ed., 13 November 2000.Available at:
http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113. The
latest version is available at: http://www.w3.org/TR/DOM-Level-2Events.
[Eastlake 02]
Donald Eastlake, Joseph Reagle, David Solo, XML-Signature Syntax and
Processing , W3C Recommendation 12 February 2002.
http://www.w3.org/TR/xmldsig-core/
[Fikes 01]
Fikes, Richard, and Deborah L. McGuinness. 2001. An Axiomatic
Semantics for RDF, RDF-S, and DAML+OIL (March 2001). W3C Note
18 December 2001. World Wide Web Consortium.
http://www.w3.org/TR/daml+oil-axioms
[Gudgin 03a]
Martin Gudgin et al., SOAP Version 1.2 Part 1: Messaging Framework,
w3c Recommendation, 24 June 2003, http://www.w3.org/TR/2003/RECsoap12-part1-20030624/.
[Gudgin 03b]
Martin Gudgin et al., SOAP Version 1.2 Part 2: Adjuncts, w3c
Recommendation, 24 June 2003, http://www.w3.org/TR/soap12-part2/
http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.
[Haas 03]
Hugo Haas, et al., “SOAP Version 1.2:Specification Assertions and Test
Collection, w3c Recommendation, 24 June 2003,
http://www.w3.org/TR/soap12-testcollection/.
[Hugo 04]
Hugo Hass and Allen Brown, Web Services Glossary, W3C Working
Referencias.
165
Group Note 11 de Febrero 2004 http://www.w3.org/TR/ws-gloss/.
[HTML]
HyperText Markup Language (HTML), http://www.w3.org/MarkUp/.
[Marsh 01]
Jonathan Marsh, Microsoft, XML Base. W3C Recommendation 27 June
2001. http://www.w3.org/TR/xmlbase/
[MathML]
Mathematical Markup Language (MathML) Version 2.0 (Second
Edition), http://www.w3.org/Math/.
[McCarron 03]
Shane McCarron (Applied Testing and Technology, Inc.), Steven
Pemberton (CWI/W3C®), T. V. Raman (IBM Corporation), XML
Events. An Events Syntax for XML. W3C Recommendation 14 October
2003. http://www.w3.org/TR/xml-events/.
[Mitra 03]
Nilo Mitra, SOAP Version 1.2 Part 0: Primer, w3c Recommendation, 24
June 2003, http://www.w3.org/TR/soap12-part0/.
[MWI a06]
Mobile Web Initiative Jo Rabin, mTLD Mobile Top Level Domain
(.mobi), Charles McCathieNevile, Opera Software [Early Drafts], Mobile
Web Best Practices 1.0. W3C Working Draft 13 January 2006.
http://www.w3.org/TR/mobile-bp/.
[MWI b05]
Mobile Web Initiative, http://www.w3.org/2005/MWI/.
[Perl]
Perl (Practical Extraction and Report Language), http://www.perl.org/
[Python]
Python Programming Language. http://www.python.org/
[RDF]
Resource Description Framework http://www.w3.org/RDF/
[Security ]
W3C Security Resources http://www.w3.org/Security/.
[Signature]
XML Signature WG, http://www.w3.org/Signature/.
[SVG]
Jon Ferraiolo y colaboradores, Scalable Vector Graphics (SVG) 1.1
Specification, http://www.w3.org/TR/SVG11/.
166
Contribución al análisis XML para la mejora en las prestaciones de memoria
[Thompson 01]
Thompson, Henry, S., David Beech, Murray Maloney and Noah
Mendelsohn. XML Schema Part 1: Structures. W3C Recommendation 2
May 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
[XHTML]
Steven Pemberton y colaboradores, XHTML™ 1.0 The Extensible
HyperText Markup Language (Second Edition),
http://www.w3.org/TR/xhtml1/.
[XPath 99]
James Clark, Steve DeRose,XML Path Language (XPath) Version 1.0
W3C Recommendation 16 November 1999,
http://www.w3.org/TR/xpath.
[XPath20 05]
Anders Berglund, Scott Boag, Don Chamberlin, Mary F. Fernández,
Michael Kay, Jonathan Robie, Jérôme Siméon, XML Path Language
(XPath) 2.0, W3C Working Draft 04 April 2005.
http://www.w3.org/TR/xpath20/.
[W3C a]
Document Object Model, http://www.w3.org/DOM/.
[WICD 05]
WICD Mobile 1.0. W3C Working Draft 19 December 2005.
http://www.w3.org/TR/WICDMobile/.
[WSDL ]
Erik Christensen, Francisco Curbera, Greg Meredith, y Sanjiva
Weerawarana, Web Services Description Language (WSDL),
http://www.w3.org/TR/wsdl.
Referencias.
167
6. Especificaciones Java
6.1 XML
[JSR-5]
Rajiv Mordani, JSR 5: XML Parsing Specification
http://jcp.org/en/jsr/detail?id=5.
[JSR-31]
Joe Fialli, Sekhar Vajjhala, XML Data Binding Specification,
http://www.jcp.org/jsr/detail/31.jsp, http://java.sun.com/xml/jaxb/.
[JSR-63 ]
JAXP 1.1 Java APIs for XML Processing,
http://jcp.org/en/jsr/detail?id=63.
[JSR-67]
V B Kumar Jayanti, JavaTM APIs for XML Messaging 1.0,
http://jcp.org/en/jsr/detail?id=67.
[JSR-93]
Farrukh Najmi, JavaTM API for XML Registries 1.0 (JAXR),
http://jcp.org/en/jsr/detail?id=67.
[JSR-101]
Roberto Chinnici, Java APIs for XML based RPC,
http://www.jcp.org/jsr/detail/101.jsp.
[JSR-102]
Jason Hunter, JDOM 1.0, http://jcp.org/en/jsr/detail?id=102.
[JSR-104]
Anthony Nadalin, XML Trust Service APIs,
http://jcp.org/en/jsr/detail?id=104.
[JSR-105]
Java Specification Request 105: XML Digital Signature APIs.
http://jcp.org/en/jsr/detail?id=105.
[JSR-106]
Java Specification Request 10: XML Digital Encryption APIs.
http://jcp.org/en/jsr/detail?id=106.
[JSR-156]
Mark Little, Java API for XML Transactions,
http://jcp.org/en/jsr/detail?id=156.
[JSR-157]
Himagiri Mukkamala, ebXML CPP/A APIs for Java,
168
Contribución al análisis XML para la mejora en las prestaciones de memoria
http://jcp.org/en/jsr/detail?id=157.
[JSR-173]
Java Specification Request 173: JSR 173: Streaming API for XML,
http://jcp.org/en/jsr/detail?id=173.
[JSR-206]
Jeff Suttor, Norman Walsh, JavaTM API for XML Processing (JAXP)
1.3, http://jcp.org/en/jsr/detail?id=206.
[JSR-280]
Pia Niemela, Ellen Siegel, JSR 280: XML API for JavaTM ME,
http://jcp.org/en/jsr/detail?id=280.
Referencias.
169
6.2 J2ME
[JSR-30]
Antero Taivalsaari, J2ME Connected, Limited Device Configuration,
http://jcp.org/en/jsr/detail?id=30.
[JSR-36]
Hinkmond Wong, J2METM Connected Device Configuration (CDC),
http://jcp.org/en/jsr/detail?id=36.
[JSR-37]
Jim Van Peursem, Mobile Information Device Profile for the J2METM
Platform, http://jcp.org/en/jsr/detail?id=37.
[JSR-46]
Hinkmond Wong, J2METM Foundation Profile,
http://jcp.org/en/jsr/detail?id=46.
[JSR-62]
Jon Courtney, Personal Profile Specification,
http://jcp.org/en/jsr/detail?id=62.
[JSR-75]
Brad Jarvinen y Ken Walker, PDA Optional Packages for the J2METM
Platform, http://jcp.org/en/jsr/detail?id=75.
[JSR-82]
Ravi Viswanathan, JavaTM APIs for Bluetooth,
http://jcp.org/en/jsr/detail?id=82.
[JSR-118]
Mobile Information Device Profile (MIDP) 2.0.
http://jcp.org/jsr/detail/118.jsp.
[JSR-120]
Jan Eichholz, Wireless Messaging API,
http://jcp.org/en/jsr/detail?id=120.
[JSR-135]
Antti Rantalahti, Mobile Media API, http://jcp.org/en/jsr/detail?id=135.
[JSR-139]
Antero Taivalsaari, Sun Microsystems, Inc., JSR 139: Connected Limited
Device Configuration 1.1, http://jcp.org/en/jsr/detail?id=139.
[JSR-172]
Java Specification Request 172: J2ME Web Services Specification,
http://jcp.org/en/jsr/detail?id=172".
170
Contribución al análisis XML para la mejora en las prestaciones de memoria
[JSR-179]
Kimmo Loytana, Location API for J2METM ,
http://jcp.org/en/jsr/detail?id=179.
[JSR-180]
Chris Bouret y Jari Kinnunen, SIP API for J2ME,
http://jcp.org/en/jsr/detail?id=180.
[JSR-184]
Tomi Aarnio, Mobile 3D Graphics API for J2METM,
http://jcp.org/en/jsr/detail?id=184.
[JSR-185]
Harry Burks and John Pampuch, JavaTM Technology for the Wireless
Industry, http://jcp.org/en/jsr/detail?id=185.
[JSR-190]
Allen Lau y Colin Sampaleanu, Event Tracking API for J2ME,
http://jcp.org/en/jsr/detail?id=190.
[JSR-205]
Jochen Sauter (Siemens AG), JSR-205 Wireless Messaging API 2.0,
http://jcp.org/aboutJava/communityprocess/final/jsr205/
[JSR-209]
Hakim Mendjeli, (Vodafone Group Services Limited) JSR 209:
Advanced Graphics and User Interface Optional Package for the J2METM
Platform, http://jcp.org/en/jsr/detail?id=209.
[JSR-217]
Bartley Calder (Sun Microsystems, Inc.), Jon Courtney (Sun
Microsystems, Inc.), http://jcp.org/en/jsr/detail?id=217.
[JSR-226]
Suresh Chitturi, Nokia Corporation, Scalable 2D Vector Graphics API for
J2METM, http://jcp.org/en/jsr/detail?id=226.
[JSR-238]
Nokia Corporation (2004), JSR-238 Mobile Internationalization API.
http://www.jcp.org/en/jsr/detail?id=238.
[JSR-271]
JSRs: Java Specification Requests JSR 271: Mobile Information Device
Profile 3
[JSR-287]
Suresh Chitturi (Nokia Corporation), JSR 287: Scalable 2D Vector
Graphics API 2.0 for Java METM, http://jcp.org/en/jsr/detail?id=287.
Referencias.
[JSR-177]
171
Java Specification Request 177: JSR 177: Security and Trust Services
API for J2ME. http://jcp.org/en/jsr/detail?id=177.
6.3 Otras Especificaciones Java
[JSR-164]
John Buford y Mourad Debbabi, SIMPLE Presence,
http://jcp.org/en/jsr/detail?id=164.
[JSR-165]
John Buford y Mourad Debbabi, SIMPLE Instant Messaging,
http://jcp.org/en/jsr/detail?id=165.
7. The Internet Engineering Task Force (RFC y draft)
[RFC 959]
J. Postel, J. Reynolds, File Transfer Protocol (FTP), (October 1985)
http://www.faqs.org/rfcs/rfc959.html
[RFC 1050]
Sun Microsystems, Inc. RPC: Remote Procedure Call Protocol
specification, (April 1988). http://www.faqs.org/rfcs/rfc1050.html.
[RFC 1157]
J. Case, M. Fedor, M. Schoffstall, J. Davin, A Simple Network
Management Protocol (SNMP), (May 1990),
http://www.ietf.org/rfc/rfc1157.txt.
[RFC1641]
Goldsmith, D., and M. Davis, Using Unicode with MIME, RFC1641,
Taligent, Inc., (July 1994) http://www.faqs.org/rfcs/rfc1641.html.
[RFC 1642]
D. Goldsmith, M. Davis, UTF-7 A Mail-Safe Transformation Format of
Unicode, (Mayo 1997) http://www.ietf.org/rfc/rfc2152.txt.
[RFC 1766]
H. Alvestrand, Tags for the Identification of Languages, (March 1995)
http://www.ietf.org/rfc/rfc1766.txt.
[RFC1815]
Ohta, M., Character Sets ISO-10646 and ISO-10646-J-1, RFC 1815,
Tokyo Institute of Technology, (July 1995).
172
Contribución al análisis XML para la mejora en las prestaciones de memoria
http://www.ietf.org/rfc/rfc1815.txt.
[RFC 1851]
P. Karn, P. Metzger, W. Simpson, The ESP Triple DES Transform,
(Septiembre 1995) http://www.ietf.org/rfc/rfc1851.txt
[RFC 2044]
Yergeau F., UTF-8, a Transformation Format of ISO 10646. (1998).
http://www.ietf.org/rfc/rfc2044.txt.
[RFC 2119]
Scott Bradner, Key words for use in RFCs to Indicate Requirement
Levels, (1997), http://www.ietf.org/rfc/rfc2119.txt.
[RFC 2141]
Moats, R., URN Syntax, RFC 2141, (May 1997),
http://www.ietf.org/rfc/rfc2141.txt.
[RFC 2279]
F. Yergeau, RFC 2279 - UTF-8, a transformation format of ISO 10646,
http://www.faqs.org/rfcs/rfc2279.html.
[RFC 2396]
T. Berners-Lee, R. Fielding, U.C. Irvine, Uniform Resource Identifiers
(URI): Generic Syntax, (Agosto 1998)
http://www.ietf.org/rfc/rfc2396.txt.
[RFC 2608]
E. Guttman, C. Perkins, J. Veizades, M. Day, Service Location Protocol,
version 2, (1999), http://www.faqs.org/rfcs/rfc2608.html.
[RFC 2616]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter and T. BernersLee, Hypertext Transfer Protocol -- HTTP/1.1, (June 1999),
http://www.w3.org/Protocols/rfc2616/rfc2616.html.
[RFC 2732]
L. Masinter Carpenter, B R. Hinden, Format for Literal IPv6 Addresses in
URL's, (1999), http://www.ietf.org/rfc/rfc2732.txt.
[RFC 2781]
Hoffman, P., Yergau, F, UTF-16, an Encoding of ISO 10646, (2000),
http://www.ietf.org/rfc/rfc2781.txt.
[RFC 2818]
E. Rescorla, HTTP Over TLS, (May 2000)
http://www.faqs.org/rfcs/rfc2818.html.
Referencias.
[RFC 3023]
173
M. Murata, S. St.Laurent, D. Kohn, XML Media Types, (2001).
http://www.ietf.org/rfc/rfc3023.txt.
[RFC 3066]
H. Alvestrand, Tags for the Identification of Languages, (Enero 2001)
http://www.ietf.org/rfc/rfc3066.txt.
[RFC 3986]
T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier
(URI): Generic Syntax, (Enero 2005)
http://www.gbiv.com/protocols/uri/rfc/rfc3986.html.
[RFC 3987]
M. Duerst, M. Suignard, Internationalized Resource Identifiers (IRIs),
(Enero 2005) http://www.ietf.org/rfc/rfc3987.txt.
[RFC 4042]
M. Crispin, Request for Comments: 4042, UTF-9 and UTF-18 Efficient
Transformation Formats of Unicode, (1 Abril 2005),
http://panda.com/tops-20/utf9.txt.
[draft-ietf-idn-
Mark Welter, Mark Welter, UTF-6 - Yet Another ASCII-Compatible
utf6-00]
Encoding for IDN, draft-ietf-idn-utf6-00, (November 16, 2000),
http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-idn-utf6-00.txt.
8. Unicode
[Davis 05a]
Mark Davis, Unicode Technical Standard #18. Unicode Regular
Expressions, 2005-05-01. http://www.unicode.org/reports/tr18/.
[Davis 05b]
Mark Davis, Markus Scherer, Unicode Technical Standard #22.
Character Mapping Markup Language (CharMapML),
http://www.unicode.org/reports/tr22/.
[Davis 05c]
Mark Davis, Unicode Technical Standard #35. Locale Data Markup
Language (LDML) 2005-06-02, http://www.unicode.org/reports/tr35/.
[Davis 05d]
Martin Dürst (W3C), Asmus Freytag(Unicode), Unicode in XML and
other Markup Languages. Unicode Technical Report #20. 13 June 2003.
174
Contribución al análisis XML para la mejora en las prestaciones de memoria
[Davis 05e]
Mark Davis, Ken Whistler, Unicode Technical Standard #10. Unicode
Collation Algorithm, 2005-05-05, http://www.unicode.org/reports/tr10/.
[SCSU ]
A Standard Compression Scheme for Unicode,Unicode Technical
Standard #6, http://www.unicode.org/reports/tr6/.
[Umamaheswara V.S. Umamaheswaran, Unicode Technical Report #16. UTF-EBCDIC,
n 02]
2002-04-16, http://www.unicode.org/reports/tr16/.
[Unicode HP]
Unicode Home Page, http://www.unicode.org/
[Unicode]
The Unicode Consortium. The Unicode Standard, Version 4.1. Reading,
Mass.: Addison-Wesley, as updated from time to time by the publication
of new versions. (ISBN 0-321-18578-1) (See
http://www.unicode.org/unicode/standard/versions/ for the latest version
and additional information on versions of the standard and of the Unicode
Character Database).
9. ISO: International Organization for Standardization
ISO 639-2:1998 - Codes for the representation of names of languages -[ISO 639-2]
Part 2: Alpha-3 code - edition 1, 1998-11- 01, 66 pages, prepared by a
Joint Working Group of ISO TC46/SC4 and ISO TC37/SC2.
[ISO 646]
ISO/IEC 646: Information Processing - 7-Bit Coded Character Set for
Information Interchange.
[ISO 1087]
ISO 1087-2:2000. Terminology work - Vocabulary - Part 2: Computer
applications.
[ISO 10744]
ISO 10744: Information Technology - Hypermedia/Time-based
Structuring Language (HyTime). International Organization for
Standardization, 1997.
[ISO 1639]
ISO 639:1988 (E/F) - Code for the representation of names of languages -
Referencias.
175
The International Organization for Standardization, 1st edition, 1988-0401 Prepared by ISO/TC 37 - Terminology (principles and coordination).
[SGML ]
ISO 8879 : Information processing - Tex and office systems – Standard
generalized markup languaje (SGML) = Traitement de l'information Systèmes bureautiques - Language standard généralisé de balisage
(SGML) / International Organization for Standarization, Génève: ISO,
1988.
ISO 3166:1988 (E/F) - Codes for the representation of names of countries
[ISO 3166]
- The International Organization for Standardization, 3rd edition, 198808-15.
[ISO 4873]
ISO/IEC 4873: Information Processing - 8-Bit Code for Information
Interchange - Structure and Rules for implementation.
[ISO 6429]
ISO/IEC 6429: Information Processing - 7-Bit and 8-Bit Coded Character
Sets - Control Functions for Coded Character Sets.
[ISO 8859]
ISO/IEC 8859-xx: Information Processing - 8-Bit Single-Byte Coded
Graphic Character Sets (several parts).
[ISO 10179]
ISO/IEC 10179:1996. Document Style Semantics and Specification
Language, (DSSSL)
[ISO 10646]
ISO (). ISO/IEC 10646-1:2000. Information technology — Universal
Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and
Basic Multilingual Plane and ISO/IEC 10646-2:2001. Information
technology — Universal Multiple-Octet Coded Character Set (UCS) —
Part 2: Supplementary Planes, as, from time to time, amended, replaced
by a new edition or expanded by the addition of new parts. [Geneva]:
International Organization for Standardization. (See http://www.iso.ch
for the latest version.)
[ISO 15000]
ISO 15000 Electronic business eXtensible Markup Language ebXML.
ISO 15000-1:2004 Part 1: Collaboration-protocol profile and agreement
176
Contribución al análisis XML para la mejora en las prestaciones de memoria
specification (ebCPP)
ISO 15000-2:2004 Part 2: Message service specification (ebMS)
ISO 15000-3:2004 Part 3: Registry information model specification
(ebRIM)
ISO 15000-4:2004 Part 4: Registry services specification (ebRS)
ISO 15000-5:2005 Part 5: ebXML Core Components Technical
Specification, Version 2.01(ebCCTS)
[ISO/IEC 19757] ISO/IEC 19757 - DSDL Document Schema Definition Language - Part 3:
Rule-based validation – Schematron.
[ISO/IEC DTR
ISO/IEC DTR 22250-1, Document Description and Processing
22250-1]
Languages -- Regular Language Description for XML (RELAX) -- Part 1:
RELAX Core, 2000 October.
Referencias.
177
10. OASIS
(Organization for the Advancement of Structured Information Standards)
[Clark 01b]
James Clark, Murata Makoto, RELAX NG Specification, Committee
Specification 3 December 2001, http://www.oasisopen.org/committees/relax-ng/spec-20011203.html.
Security Assertion Markup Language (SAML) 2.0 Technical Overview
[SAML
Working Draft 03, 20 February 2005.
overview]
Profiles for the OASIS Security Assertion Markup Language (SAML)
[SAML v2.0]
V2.0 OASIS Standard, 15 March 2005. http://docs.oasisopen.org/security/saml/v2.0/.
[SAML
Interoperability Demonstration Scenarios, Guidelines & Final Report
Scenario]
SAML 2.0 RSA Conference 2005 February 18, 2005 San Francisco, CA.
[UBL 06]
Jon Bosak y Tim McGrath, Universal Business Language 2.0 Public
Review Draft, 19 January 2006, http://docs.oasis-open.org/ubl/prd-UBL2.0/.
[XACML]
OASIS Standard,XACML(eXtensible Access Control Markup
Language), http://www.oasisopen.org/committees/download.php/2406/oasis-xacml-1.0.pdf, 18
Febrero 2003.
178
Contribución al análisis XML para la mejora en las prestaciones de memoria
11. Software
[ASXMLP ]
ASXMLP 020308, http://www.argosytelcrest.co.uk/xmlparser/.
[Bouncy Castle]
The
legion
of
the
http://www.bouncycastle.org/index.html.
[DOM4J]
http://dom4j.org/.
[EXML]
Electric XML,
Bouncy
http://www.webmethods.com/meta/default/folder/0000005452
[Javaguard]
Javaguard, http://sourceforge.net/projects/javaguard/
[JDOM]
http://jdom.org/
[Jobfuscate]
Jobfuscate, http://www.jobfuscator.com/
[JoGa]
JoGa, http://www.nq4.de/
[Jshrink]
Jshrink, http://www.e-t.com/jshrink.html.
[JWSDP]
Java Web Services Developer Pack (Java WSDP) Version 2.0,
http://java.sun.com/webservices/jwsdp/
[Kawaguchi 03]
Sun Multi-Schema XML Validator,
http://www.sun.com/software/xml/developers/multischema/
[kSOAP]
http://ksoap.objectweb.org/.
[kXML2]
kXML2, http://kxml.objectweb.org/.
[Marvin
MarvinObfuscator, http://www.drjava.de/obfuscator/
Obfuscator]
[MinML]
MinML, http://www.wilson.co.uk/xml/minml.htm.
[NanoXML]
NanoXML, http://nanoxml.sourceforge.net/orig/kvm.html.
Castle.
Referencias.
179
[Next]
Next Solution http://www.nextsolution.co.jp/
[OpenJade]
OpenJade: http://sourceforge.net/projects/openjade/
[Proguard]
Proguard, http://proguard.sourceforge.net/.
[Retroguard]
Retroguard, http://www.retrologic.com/retroguard-main.html.
[St.Laurent ]
Simon St.Laurent, TAM - The
http://simonstl.com/projects/tam/.
[Smokescreen ]
Smokescreen, http://www.leesw.com/
[OmniMark]
OmniMark programming language, http://www.stilo.com/
[Xerces]
Xerces2 Java Parser, http://xml.apache.org/xerces2-j/index.html.
[Xparse-J ]
Xparse-J 1.0, http://www.webreference.com/xml/tools/xparse-j.html.
[XPP ]
XmlPull V1 API,
Tiny
API
for
Markup,
http://www.xmlpull.org/v1/doc/api/org/xmlpull/v1/packagesummary.html.
[XPP2]
XML Pull Parser 2, Home page of XML Pull Parser (XPP),
http://www.extreme.indiana.edu/xgws/xsoap/xpp/.
[XML Stream]
XML Stream API, http://edocs.bea.com/wls/docs70/xml/xml_stream.html.
[XMLtp]
XMLtp, http://mitglied.lycos.de/xmltp/
[XP]
http://www.trantor.de/xml/
[XT]
The Expat XML Parser ,http://www.libexpat.org/
[yGuard]
yGuard, http://www.yworks.com/en/products_yguard_about.htm.
[Z Format]
Z Format, http://z.departure.dk/.
[Zelix KlassMaster] Zelix KlassMaster, http://www.zelix.com/klassmaster/
180
Contribución al análisis XML para la mejora en las prestaciones de memoria
[VTD-XML]
Project Homepage of VTD-XML, http://vtdxml.sourceforge.net/VTD.html.
12. Referencias Web
[ACH/ACL/AL
Association for Computers and the Humanities, Association for
LC 94]
Computational Linguistics, and Association for Literary and Linguistic
Computing. 1994. Guidelines for Electronic Text Encoding and
Interchange (TEI P3). Ed. C. M. Sperberg-McQueen and Lou Burnard.
Chicago, Oxford: Text Encoding Initiative, 1994.
http://www.hti.umich.edu/t/tei/.
[Apache]
The Apache Software Foundation, http://www.apache.org/
[Allen 01]
Eric E. Allen, Diagnosing Java Code: Improve the performance of your
Java code, 01 May 2001, http://www106.ibm.com/developerworks/java/library/j-diag8.html.
[Atkinson 02]
Bob Atkinson y colaboradores, Web Services Security (WS-Security),
Version 1.0 05 April 2002, http://www106.ibm.com/developerworks/webservices/library/ws-secure/.
[Álvarez 02]
G. Álvarez, Ofuscación del código,
http://www.cs.arizona.edu/~collberg/Teaching/620/2002/Handouts/Hand
out-13.pdf, 18 Febrero 2002.
[Batik]
Batik SVG Toolkit, Apache Software Foundation.
http://xml.apache.org/batik/
[BEAXmlStrea]
BEA WebLogic XML Streaming API, http://edocs.bea.com/wls/docs70/xml/xml_stream.html
[CafeBabe]
CafeBabe,
http://www.geocities.com/CapeCanaveral/Hall/2334/Programs/cafebabe.
html.
Referencias.
[Chakraborty ]
181
Dipanjan Chakraborty y Harry Chen, Descubrimiento de Servicios para
Comercio Móvil en el Futuro,
http://www.acm.org/crossroads/espanol/xrds7-2/service.html.
[Clark 01a]
Kendall Grant Clark, DOM and SAX are Dead, Long Live DOM and
SAX, http://www.xml.com/lpt/a/2001/11/14/dom-sax.html.
[Clark 01c]
James Clark, TREX - Tree Regular Expressions for XML,
http://www.thaiopensource.com/trex/.
[Collberg]
Christian Collberg, Clark Thomborson, Douglas Low, A Taxonomy of
ObfuscatingTransformations,
http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergTho
mborsonLow97a/index.html
[Collberg 02]
C.S. Collberg, Security Through Obscurity,
http://www.cs.arizona.edu/~collberg/Teaching/620/2002/Handouts/Hand
out-13.pdf
[Collberg 02a]
C.S. Collberg, y C. Thomborson, Watermarking, Tamper-Proofing, and
Obfuscation-Tools for Software Protection, IEEE Transactions on
Software Engineering, Vol. 28, no. 6, June 2002,
http://www.cs.auckland.ac.nz/~cthombor/Pubs/112393-2a.pdf.
[Connolly]
Dan Connolly, Rohit Khare, Adam Rifkin, The Evolution of Web
Documents. The Ascent of XML,
http://www.xml.com/pub/a/w3j/s3.connolly.html.
[DocBook 06]
DocBook, http://nwalsh.com/docbook/index.html
[DOM PPP]
DOM Pull Parser for Python,
http://www.prescod.net/python/pulldom.html.
[DuCharme 05]
Bob DuCharme, Push, Pull, Next!,
http://www.xml.com/pub/a/2005/07/06/tr.html.
182
Contribución al análisis XML para la mejora en las prestaciones de memoria
[ebXML]
http://www.ebxml.org/
[Edd 04]
Dumbill, The State of XML,
http://www.xml.com/pub/a/2004/04/21/state.html.
[EDGE]
Enhanced Data Rates for GSM Evolution (EDGE), Nokia
Telecommunications Oy, Nokia white paper, March 1999,
http://www.nokia.com/BaseProject/Sites/NOKIA_MAIN_18022/CDA/C
ategories/Business/Technologies/EDGE/_Content/_Static_Files/nokia_ed
ge_evolution_wp.pdf.
[Giguere 02]
Eric Giguere, Understanding J2ME Application Models, October 2002,
http://developers.sun.com/techtopics/mobility/midp/articles/models/.
[Haustein ]
Stefan Haustein. XML pull wrapper for SAX parsers
http://www.trantor.de/xml/
[Heath ]
Jim Heath and Larry Welsch, Difficulties in Parsing SGML,
DOCPROCS '88 Proceedings of the ACM conference on Document
processing systems, http://portal.acm.org/citation.cfm?id=62520.
[HotSpot]
The
CLDC
HotSpot
Implementation
Virtual
Machine
http://java.sun.com/products/cldc/wp/CLDC_HI_WhitePaper.pdf.
[Java EE]
Java Platform, Enterprise Edition (Java EE) http://java.sun.com/javaee/
[Java ME]
Java 2 Micro Edition (1999). Java 2 Platform Micro Edition.
http://java.sun.com/j2me/index.jsp.
[Java SE ]
Java Platform, Standard Edition (Java SE) http://java.sun.com/javase/
[J2ME05]
J2ME Devices, Sun developers network, Products and Technologies,
Technical Topics,
http://developers.sun.com/techtopics/mobility/device/device.
[J2MEpolish]
Device Database, http://www.j2mepolish.org/devices-overview.html.
Referencias.
183
[Jade]
Jade – James’s DSSSL Engine. http://www.jclark.com/jade/
[JARV]
A vendor-neutral, implementation-independent and schema language
independent interface for XML validators. http://isorelax.sourceforge.net/JARV/
[Knudsen 02a]
Jonathan Knudsen, Parsing XML in J2ME
http://developers.sun.com/techtopics/mobility/midp/articles/parsingxml/,
2002.
[Knudsen 02b]
Jonathan Knudsen, Obfuscating MIDlet Suites with Proguard,
http://developers.sun.com/techtopics/mobility/midp/ttips/proguard, 23
Agosto 2002.
[Kuhn]
Markus Kuhn, UTF-8 and Unicode FAQ for unix/linux,
http://www.cl.cam.ac.uk/~mgk25/unicode.html.
[KVM 05]
White Paper, Sun Microsystems, The K Virtual Machine (KVM),
http://java.sun.com/products/cldc/wp/.
[kXML1]
Stefan Haustein, kXML Project,
http://kxml.enhydra.org/software/downloads/index.html
[kXML2]
Stefan Haustein, kXML 2, http://www.kxml.org/
[Lai ]
Hongying Lai, A comparative survey of Java obfuscator,
http://www.cs.auckland.ac.nz/~cthombor/Students/hlai/hongying.pdf.
[libxml]
The XML C parser and toolkit of Gnome, libxml, http://xmlsoft.org/.
[Low ]
Douglas Low, Protecting Java Code Via Code Obfuscation,
http://www.cs.arizona.edu/~collberg/Research/Students/DouglasLow/obf
uscation.html.
[Marples 01]
Marples and Kriens, (2001). The Open Services Gateway Initiative: An
Introduction Overview. IEEE Communications Magazine, pages 110-
184
Contribución al análisis XML para la mejora en las prestaciones de memoria
114.
[Marroquín]
W. A. Marroquín, Ofuscadores (De la protección relativa del código
intermedio),
http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art14
6.asp. Publicado originalmente por Universal Thread Magazine
(www.UTMag.com/Spanish).
[Megginson ]
David Megginson et al., SAX 2.0: The Simple API for XML,
http://www.saxproject.org.
[Microsoft's
Microsoft's XML Reader,
XML Reader]
http://msdn.microsoft.com/library/default.asp?url=/library/enus/cpref/html/frlrfsystemxmlxmlreaderclasstopic.asp.
[NekoPull]
Andy Clark, CyberNeko Pull Parser
http://www.apache.org/~andyc/neko/doc/pull/
[OracleStAX]
Oracle StAX Pull Parser Preview
http://otn.oracle.com/tech/xml/xdk/staxpreview.html
[PullPatterns]
Aleksander Slominski, XML pull parsing patterns
http://www.extreme.indiana.edu/~aslom/xmlpull/patterns.html
[Rijndael]
AES algorithm (Rijndael) apecification.
http://csrc.nist.gov/CryptoToolkit/aes/rijndael/
[SAX]
http://www.saxproject.org/sax1-history.html
[APISAX20]
http://sourceforge.net/project/showfiles.php?group_id=29449
[SAXF]
SAX Filters. http://www.saxproject.org/?selected=filters
[Saxon]
Kay, Michael. Saxon XSLT processor. http://saxon.sourceforge.net/
[SaxonP]
Saxon preview mode.
http://saxon.sourceforge.net/saxon7.4/extensions.html#saxon:preview
Referencias.
185
[STX]
Streaming Transformations for XML. http://stx.sourceforge.net/
[Schematron]
The Schematron, An XML Structure Validaton Language using Patterns
in Trees, http://xml.ascc.net/resource/schematron/schematron.html.
[serialTOC ]
Java Object Serialization Specificationversion 1.5.0,
http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTOC.ht
ml.
[Shirwaikar ]
Rohan Shirwaikar, SGML/XML Parser for FLORA-2
http://flora.sourceforge.net/docs/floraXML.pdf.
[Slomiski 04]
Aleksander Slomiski, On Using XML Pull Parsing Java APIs, 2004,
http://www.xmlpull.org/history/index.html
[Sosnoski 01]
Dennis M. Sosnoski, XML and Java technologies: Document models,
Part 1: Performance, 1 September 2001, http://www106.ibm.com/developerworks/xml/library/x-injava/.
[StAX javadoc]
https://stax-utils.dev.java.net/nonav/javadoc/api/overview-summary.html.
[Talens-Oliag]
Seguridad en Java. Talens-Oliag, Sergio.
http://www.uv.es/~sto/cursos/seguridad.java/html/sjava-1.html
[TD-SCDMA]
TD-SCDMA Standards, http://www.cwts.org.
[UDDI v3.0]
Luc Clement, Andrew htely, Claus von Riegen y Tony Rogers, Universal
Description, Discovery and Integration (UDDI) version 3.0.2,
http://uddi.org/pubs/uddi_v3.htm.
[StAXCodehaus] StAX RI at codehaus http://stax.codehaus.org/
[Xerces2]
Apache Foundation. Xerces Java Parser 2, http://xml.apache.org/xerces2j/
[XMLIO]
Paul T. Miller. XMLIO – An XML input/output library for C++
applications http://www.fxtech.com/xmlio/.
186
Contribución al análisis XML para la mejora en las prestaciones de memoria
[XmlPerf]
Aleksander Slominski, On Performance of Java XML Parsers
http://www.cs.indiana.edu/˜aslom/exxp/.
[XniPull]
XMLPullParserConfiguration described in http://xml.apache.org/xerces2j/xni-config.html
[XPP1]
Aleksander Slominski, XML Pull Parser Version 1 (XPP1)
http://www.extreme.indiana.edu/xgws/xsoap/xpp/xpp1/
[XPP2]
Aleksander Slominski, XML Pull Parser Version 2 (XPP2),
http://www.extreme.indiana.edu/xgws/xsoap/xpp/xpp2/
[XPP3]
Aleksander Slominski, MXP1: Xml Pull Parser 3rd Edition (XPP3),
http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/
[XSLTC]
XSLT Compiler. http://xml.apache.org/xalan-j/xsltc/
[TR550]
Aleksander Slominski, TR550: Design of a Pull and Push Parser System
for Streaming XML, http://www.cs.indiana.edu/cgibin/techreports/TRNNN.cgi?trnum=TR550
[XPP]
XML Pull Parsing,http://www.xmlpull.org/.
[Veillard]
Daniel Veillard, The XML C library for Gnome (libxml)
http://xmlsoft.org/
[WAP]
Wireless Application Protocol Specification,
http://www.wapforum.org/what/technical.htm.
[Wilmott a05]
Sam Wilmott, What’s all this About Different Kinds of XML Parsers?,
Poster at Montreal, Canada, Extreme Markup Languages 2005, Agosto
2005.
http://www.wilmott.ca/conferences/extreme2005/xmlparserposter.pdf.
[Wilmott b]
Sam Wilmott, AFL -- Another Fun Language
http://www.wilmott.ca/afl/index.html.
Referencias.
[Zhang 04a]
187
Jimmy Zhang, Improve XML Processing with VTD-XML,
http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/code/211657.htm
[Zhang 04b]
Jimmy Zhang, Non-Extractive Parsing for XML, 2004.
http://www.xml.com/pub/a/2004/05/19/parsing.html.
188
Contribución al análisis XML para la mejora en las prestaciones de memoria
13. Otras recomendaciones XML
[Clark 01d]
James Clark, RELAX (Regular Language description for XML)
http://www.xml.gr.jp/relax/.
[Clark 01e]
James Clark. TREX - Tree Regular Expressions for XML. Thai Open
Source Software Center, 2001.
[cXML]
Commerce XML, http://www.cxml.org/.
[ebXML]
Electronic Business using eXtensible Markup Language,
http://www.ebxml.org/.
[WS-I ]
WS-I Basic Profile (WS-I BP) http://www.ws-i.org.
Referencias.
189
14. Otras recomendaciones y especificaciones
[3GPP, 02]
3GPP, Tech. Spec. Group, Svcs. and Sys. Aspects, General Packet Radio
Service (GPRS); Service Description, Tech. Spec. 3G TS 23.060 v. 5.4.0
(2002–12), 2002.
[3GPP, 02a]
3GPP2 C.S0002-C, Physical Layer Standard for cdma2000 Spread
Spectrum Systems, Rel. C v1.0, May 2002.
[3G TS 21.101,
3G TS 21.101 (2000). Digital cellular telecommunications system (Phase
2000]
2+) (GSM); Universal Mobile Telecommunications System (UMTS);
3rd Generation mobile system Release 1999 Specifications.
[3G TS 21.101,
3G TS 21.102 (2001). Universal Mobile Telecommunications System
2000]
(UMTS); 3rd Generation mobile system Release 4 Specifications.
[3G TS 21.102,
3G TS 21.102 (2002). Universal Mobile Telecommunications System
2002]
(UMTS); 3rd Generation mobile system Release 5 Specifications.
[3G TS 21.051,
3G TS 43.051 (2002). Digital cellular telecommunications system (Phase
2002]
2+); GSM/EDGE Radio Access Network (GERAN) overall description;
Stage 2.
[GSM 02.60,
GSM 02.60 (1997). Digital cellular telecommunications system (Phase
1997]
2+); General Packet Radio Service (GPRS); service description; Stage 1.
[ASCII]
ASCII - ANSI Standard X3.4; also the International Reference Version of
ISO/IEC 646 – 1993.
[Bluetooth v1.1,
Bluetooth v1.1 (2001). Specificationo of the Bluetooth System v.1.1.
2001]
http://www.bluetooth.com/dev/specifications.asp.
[CDMA2000]
3GPP2 www.3gpp2.org.
ECMA (European Computer Manufacturers Association) ECMAScript
[ECMAScript]
Language Specification. Available at
190
Contribución al análisis XML para la mejora en las prestaciones de memoria
http://www.ecma.ch/ecma1/STAND/ECMA-262.HTM
[IANA-
Internet Assigned Numbers Authority, Official Names for Character Sets,
CHARSETS]
ed. Keld Simonsen et al. (See http://www.iana.org/assignments/charactersets.)
[OMGIDL]
OMG (Object Management Group) IDL (Interface Definition Language)
defined in The Common Object Request Broker: Architecture and
Specification, version 2.3.1, October 1999. Available from
http://www.omg.org/
[SDP, 2001]
SDP (2001). Bluetooth Specification v1.1, Part E: Service Discovery
Protocol (SDP). http://www.bluetooth.com/dev/specifications.asp.
[UML]
Unified Modeling Language, http://www.uml.org/
Acrónimos
2G
Segunda Generación
3G
Tercera Generación
3GPP
3rd Generation Partnership Project
3GPP2
Third Generation Partnership Project
ANSI
American National Standards Institute
API
Application Program Interface
ASCII
American Standard Code for Information Interchange
ASN.1
Abstract Syntax Notation One
AWT
Abstract Windowing Toolkit
B2B
Business-to-Business
BMP
Basic Multilingual Plane
BNF
Backus Normal Form o Backus Naur Form
BOM
Byte Order Mark
CCITT
Comité Consultatif International Télégraphique et Téléphonique
CDC
Connected Device Configuration
CJK
Chinese, Japanese y Korean
CJKV
Chinese, Japanese, Korean, y Vietnamese
192
Contribución al análisis XML para la mejora en las prestaciones de memoria
CLDR
Common Locale Data Repository
CLDC
Connected Limited Device Configuration
COM
Component Object Model
CORBA
Common Object Request Broker Architecture
CRC
Cyclic Redundancy Check
CSS
Cascading Style Sheets
cXML
Commerce XML
DES
Data Encryption Standard
DOM
Document Object Mode
DSA
Digital Signature Algorithm
DSSSL
Document Style Semantics and Specification Language
DTD
Document Type Definition
EAI
Enterprise Application Integration
EBCDIC
Extended Binary-Coded Decimal Interchange Code
EDGE
Enhanced Data Rates for GSM Evolution
EPS
Encapsulated PostScript
EUC
Extended Unix Code
FCM
Free Cursor Mobility
FDF
Forms Data Format
FSA
Finite State Automata
Acrónimos.
FSS-UTF
File System Safe UCS Transformation Format
FTP
File Transfer Protocol
GFC
Generic Connection Framework
GPL
Gnu Public Licence
GPRS
General Packet Radio Service
GSM
Global System Mobile
GUI
Graphical User Interface
BMP
Basic Multilingual Plane
BOM
Byte Order Mark
GML
Generalized Markup Language
HTML
HyperText Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transer Protocol Secure
IDL
Interface Definition Language
IIOP
Internet Inter-Orb Protocol
ITU
International Telecommunication Union
ITU-T
ITU Telecommunication Standardization Sector
ISO
International Standards Organization
J2EE
Java 2 Platform, Enteprise Edition
J2ME
Java 2 Platform, Micro Edition
193
194
Contribución al análisis XML para la mejora en las prestaciones de memoria
J2SE
Java 2 Platform, Standard Edition
JAD
Java Application Descriptor
JAR
Java Archive
JAXB
Java Architecture for XML Binding
JAXP
Java API for XML Processing
JCP
Java Community Process
JDBC
Java Data Base Connectivity
JDOM
Herramienta de análisis y salida Java, definida sobre la API DOM.
JSR
Java Specification Request
JUnit
Entorno de escritura y ejecución automatizada de pruebas.
JVM
Java Virtual Machine
JWTI
Java Technology for the Wireless Industry
JXME
JXTA for J2ME
JXTA
Juxtapose. Diferente al modelo Cliente/Servidor (peer to peer).
Java WSDP
Java Web Services Developer Pack
i18n
Internationalisation. (i + [18 letras] + n = i18n)
ISO
International Standards Organization
KVM
K Virtual Machine
l10n
Localization (l + [10 letras] + n = l10n)
LDML
Locale Data Markup Language
Acrónimos.
195
MathML
Mathematical Markup Language
MIDP
Mobile Information Device Profile
MIME
Multipurpose Internet Mail Extensions
MMAPI
Mobile Media API
OASIS
Organization for the Advancement of Structured Infromation Standards
ODA
Open Document Architecture
ORB
Object Request Broker
OTA
Over The Air
PBP
Personal Basis Profile
PDA
Personal Digital Assistant
PDF
Portable Document Format
RDF
Resource Description Framework
RELAX
Regular Language Description for XML
RELAX NG Lenguage de Schemas basado en TREX y RELAX
RFC
Request For Comments
RMI
Remote Method Invocation
RMS
Record Management System
RPC
Remote Call Procedure
SAAJ
SOAP with Attachments API for Java
196
Contribución al análisis XML para la mejora en las prestaciones de memoria
SAML
Security Assertion Markup Language
SATSA
Security and Trust Services API for J2ME
SAX
Simple API for XML
SCSI
Small Computer System Interface
SCSU
Standard Compression Scheme for Unicode
SDK
Software Development Kit
SGML
Standard Generalized Markup Language
SQL
Structured Query Language
SSL
Secure Sockets Layer
SVG
Scalable Vector Graphics
StAX
Streaming API for XML
SOA
Service-Oriented Architecture
StASOAP
Streaming API for SOAP
SOAP
Simple Object Access Protocol
StAX
Streaming API for XML
TCP
Transmission Control Protocol
TREX
Tree Regular Expressions for XML
UBL
Universal Business Language
UCA
Unicode Collation Algorithm
UCS
Universal Multiple-Octet Coded Character Set
Acrónimos.
UDDI
Universal Description, Discovery, and Integration
UDP
User Datagram Protocol
UML
Unified Modeling Language
UMTS
Universal Mobile telecommunications System
URI
Uniform Resource Identifier
URL
Uniform Resource Locator
URN
Uniform Resource Name
UTF
UCS Transformation Format
VRML
Virtual Reality Modeling Language
XHTML
Extensible HyperText Markup Language
XACML
eXtensible Access Control Markup Language
Xlink
XML Linking Language
XML
eXtensible Markup Language
XPath
XML Path Language
XPointer
XML Pointer Language
XQuery
XML Query Language
XSD
XML Schema Definition
XSL
Extensible Stylesheet Language
XSLT
XSL Transformation
197
198
Contribución al análisis XML para la mejora en las prestaciones de memoria
W3C
World Wide Web Consortium
WAP
Wireless Application Protocol
WCDMA
Wideband Code Division Multiple Access
WMA
Wireless Messaging API
WML
Wireless Markup Language
WSDL
Web Sevices Description Language
WTK
Wireless Toolkit
