reales - EXI(intercambio XML eficiente)... ¿Están listas las API XML?

libro de android studio en español pdf (5)

EXI de W3 (intercambio XML eficiente) va a ser estandarizado. Se dice que es "el último estándar binario".

Es un estándar para almacenar datos XML optimizados para procesamiento y almacenamiento, se incluye con el esquema XML (lo que hace que los datos sean fuertemente tipados y fuertemente estructurados). Bueno, hay muchas ventajas reclamadas. Me impresionaron más las mediciones de procesamiento y de eficiencia de la memoria.

Me pregunto, ¿qué va a pasar con todas las API XML establecidas?

Hay un párrafo relacionado con mi pregunta:

4.2 API de procesamiento XML existentes
Como EXI es una codificación de XML Infoset, una implementación de EXI puede admitir cualquiera de las API XML de uso común para el procesamiento de XML, por lo que EXI no tiene un impacto inmediato en las API XML existentes. Sin embargo, el uso de una API XML existente también requiere que todos los nombres y textos que aparecen en el documento EXI se conviertan en cadenas. En el futuro, se podría lograr una mayor eficiencia si las capas superiores pudieran usar directamente estos datos como valores tipeados que aparecen en el documento EXI. Por ejemplo, si una capa superior necesita datos escritos, al pasar por su forma de cadena puede producir una penalización de rendimiento, por lo que una API extendida que admita datos tipeados directamente podría mejorar el rendimiento cuando se usa con EXI.
de: http://www.w3.org/TR/exi-impacts/

Lo entiendo como sigue: "¿Usar EXI con las API existentes? ¡Sin ganancia de rendimiento! (A menos que las reescribas todas)"

Tomemos el ecosistema de Java como ejemplo:

Tenemos muchas API XML en la última JDK 6 (Con cada versión importante de JDK, se agregaron más y más). Por lo que puedo juzgar, la mayoría (si no todas) de ellas están usando árboles DOM en memoria, o representación serializada ("textual") para transformar / procesar / validar / ... datos XML.

¿Qué piensan ustedes, qué va a pasar con estas API con la introducción de EXI?

Gracias a todos por sus opiniones.

Para aquellos que no conocen EXI: http://www.w3.org/XML/EXI/

Personalmente, preferiría no usar EXI en absoluto. Parece que está tomando todas las cosas pesadas y torpes sobre XML, y atiborrándolas en un formato binario, que básicamente elimina la gracia salvadora de XML (formato de texto sin formato).

Parece que la tendencia general de la industria es avanzar hacia modelos de transferencia de datos más livianos (HTTP REST, por ejemplo), y alejarse de los modelos de gran peso como SOAP. Personalmente, no estoy muy entusiasmado con la idea de XML binario.

Todo lo que dice ser "el último estándar binario" probablemente sea incorrecto.

El problema con EXI es que debe abstraerse del código de su aplicación. Trabajo en un producto de middleware donde la naturaleza humana legible de XML es clave en ciertos aspectos (registro, búsqueda de fallas, etc.) pero puede sacrificarse en otras áreas (comunicación entre aplicaciones internas para limitar la carga de E / S).

Actualmente utilizamos SOAP para la comunicación entre aplicaciones cliente, middleware y aplicaciones web de proveedores. Me gustaría reemplazar esto con EXI, conservando XML legible para humanos en otras áreas. Para reemplazar la comunicación SOAP con EXI, necesito:

Espere hasta que EXI se haya incorporado a las pilas de SOAP existentes (Axis / SAAJ), o
Reemplazar las implementaciones existentes de cliente / proveedor de Axis / SAAJ SOAP con mi propio protocolo SOAP-ish además de EXI

La comparación entre JSON y EXI es justa, pero los casos de uso para los dos son diferentes. No existe un estándar para metadatos para JSON, mientras que XML-Schema para XML. Con XML, hay varios cuerpos de estándares que definen esquemas para el intercambio de datos para industrias específicas. También hay una gama de protocolos / estándares que se construyen sobre XML, como SOAP, XML-Signature, XML-Encryption, WS-Security, SAML, etc. Esto no existe para JSON.

Por lo tanto, XML es una mejor opción para el intercambio de mensajes B2B y otros casos en los que necesita integrarse con sistemas externos utilizando estándares de la industria. EXI puede aportar algunos de los beneficios de JSON en este mundo, pero debe incorporarse a las API XML existentes antes de que se pueda llevar a cabo una adopción generalizada.

No necesita nuevas API para obtener el rendimiento de EXI. Todas las pruebas EXI y las mediciones de rendimiento que el W3C ha llevado a cabo utilizan las SAX API estándar integradas en el JDK. Para las últimas pruebas, vea http://www.w3.org/TR/exi-evaluation/#processing-results . El análisis de EXI fue en promedio 14.5 veces más rápido que XML en estas pruebas sin ninguna API especial.

Un día, si la gente piensa que vale la pena, podemos ver que surgen algunas API XML a máquina. Si eso sucede, obtendrás un rendimiento aún mejor de EXI. Sin embargo, esto no es necesario para obtener un rendimiento excelente como el informado por el W3C.

Veamos EXI como un "mejor GZIP para XML". FYI, no tiene ningún impacto en las API ya que todavía puedes usarlas todas (DOM, SAX, StAX, JAXB ...). Solo que para obtener EXI debe obtener un secuenciador que lo escriba o un lector de archivos que lo lea.

La forma más eficiente de realizar EXI es StAX. Pero es cierto que podría surgir una nueva API debido a EXI. Pero ¿quién dijo que DOM es eficiente y está bien diseñado para los idiomas modernos ;-)

Si está manejando grandes archivos XML (obtuve algunos que son pocos cientos de MB), definitivamente sabe por qué necesita EXI: ahorra muchísimo espacio, ahorrando gran cantidad de memoria y tiempo de procesamiento.

Esto no es nada diferente a la finalidad de la codificación de contenido HTTP: no está obligado a usarlo, simplemente si ambas partes lo entienden, es una forma muy eficiente de realizar el intercambio.

Por cierto, EXI se convertirá en la forma preferida de contenido: repetir cualquier XML sobre HTTP en mi humilde opinión debido a SOAT bloat ;-) Tan pronto como EXI se instale en los navegadores, también podría beneficiar a cualquier usuario final: transferencia más rápida, análisis más rápido = mejor experiencia ¡siempre para la misma máquina!

EXI no desaprueba la representación de cadenas, solo la hace un poco diferente. Ah, y por cierto, al hacer UTF (piense por defecto UTF8, por ejemplo), ya está usando una "codificación de compresión" para el punto de código Unicode de 32 bits ... esto significa que en el cable los datos no son los mismos que los datos reales ya ;-)

Estoy lidiando con EXI ahora mismo.

No hay una buena herramienta universal para procesar EXI. Una vez que entra en las entrañas de EXI, se da cuenta de que hay un montón de delimitadores innecesarios en la secuencia binaria que son absolutamente y completamente innecesarios con un esquema. Algo de eso es gracioso.

¿Cómo crees que se codificará lo siguiente en EXI si se especifican ambos valores?

<xs:complexType name="example"> <xs:sequence> <xs:element name="bool1" type="xs:boolean" minOccurs="0" /> <xs:element name="bool2" type="xs:boolean" minOccurs="0" /> </xs:sequence> </xs:complexType>

¿Crees que podría ser un máximo de 4 bits? 1 bit para indicar si bool1 está definido, y que el valor de bool1, seguido de otro bit para indicar si bool2 está definido, entonces el valor de bool2?

¡Qué bueno, no!

Bueno, déjame decirte chicos y chicas. Así es como está codificado

+---- A value of 0 means this element (bool1) is not specified, | 1 indicates it is specified |+--- A value of x means this element is undefined, || 0 means the bool is set to false, 1 is set to true ||+-- A value of 0 means this element (bool2) is not specified, ||| 1 indicates it is specified |||+- A value of x means this element is undefined |||| 0 means the bool is set to false, 1 is set to true |||| 0x0x 4 0100 # neither bools are specified 0x10 8 00100000 # bool1 is not specified, bool2 is set to false 0x11 8 00101000 # bool1 is not specified, bool2 is set to true 100x 9 000000010 # bool1 is set to false, bool2 is not specified 110x 9 000010010 # bool1 is set to true, bool2 is not specified 1010 13 0000000000000 # bool1 is set to false, bool2 is set to false 1011 13 0000000001000 # bool1 is set to false, bool2 is set to true 1110 13 0000100000000 # bool1 is set to true, bool2 is set to false 1111 13 0000100001000 # bool1 is set to true, bool2 is set to true ^ ^ +-encoding--+ Which can be represented with this tree 0-0-0-0-0-0-0-0-0-0-0-0-0 (1010) / / / / / | | | | 1-0-0-0 (1011) | | | | | | | 1-0 (100x) | | | | | 1-0-0-0-0-0-0-0-0 (1110) | | / / | | | 1-0-0-0 (1111) | | | | | 1-0 (110x) | | | 1-0-0-0-0-0 (0x10) | / | 1-0-0-0 (0x11) | 1-0-0 (0x0x)

Un mínimo de 4 bits, MINIMO para no definir tampoco. Ahora estoy siendo un poco injusto, porque estoy incluyendo delimitadores, delimitadores que son completamente innecesarios.

Entiendo cómo funciona esto, ahora. Aquí está la especificación:

https://www.w3.org/TR/exi/

¡Diviértete leyendo eso! ¡Fue una GRAN OFERTA DE DIVERSIÓN PARA MÍ !!!! @@ ##! @

Ahora esto es solo con un esquema, y la especificación EXI dice específicamente que usted todavía puede codificar XML que NO se conforma con un esquema. Lo cual es gracioso porque se supone que es para pequeños dispositivos web pequeños. ¿Qué hace con los datos inesperados que no tiene disposiciones para manejar en un dispositivo integrado?

Por qué, solo mueres, por supuesto. No hay recuperación para algo que no esperas. No es que estas cosas tengan una pantalla, tengo suerte si puedo acceder a ella a través de un puerto serie.

He usado 4 generadores / analizadores de XML / generadores XSD diferentes. 3 de ellos se atragantaron con el esquema que tengo que usar. La recopilación de datos para C y C ++ (recuerde que esto es para el sistema EMBEDDED con muy poca memoria y potencia de CPU) son terribles.

XSD describe básicamente una arquitectura de clase o estructura y no hay una sola herramienta que pueda encontrar que simplemente cree las clases. El ejemplo de XSD que di más arriba debería crear una estructura con 4 bools, 2 bools son los valores y 2 bools indican si están definidos.

Pero, ¿eso existe? Bueno diablos, no.

Me gusta XML, para describir documentos. Realmente lo hago, pero esto es lo que odio de XML: para un estándar ampliamente adoptado, las herramientas disponibles son absolutamente terribles. Simplemente leer un esquema es algo difícil de hacer cuando está distribuido en múltiples espacios de nombres y documentos.

Rant rant, huff huf

La única razón por la que estamos usando esto es algún comité de normas insistió en ello. Lo que se hace es crear un monopolio para un pequeño grupo de empresas que ya lo implementaron, ese es el único propósito.

EXI no es un estándar ampliamente adoptado, XML es un encapsulador pobre para datos numéricos, y es complicado implementarlo y no hay herramientas decentes para él. EXIP está en la versión 5.0, todo lo que funciona que es de código abierto está en Java, al menos eso tengo.

Para mi campo de trabajo, EXI es solo una mala decisión de diseño. He trabajado en toneladas de protocolos de comunicación en varios sistemas integrados. Trabajé en DOCSIS, que usan todos los modernos módems de cable: usan un protocolo simple, extensible, tipo / longitud / valor con disposiciones para tratar con tipos no reconocidos, por lo que siempre se incluye la longitud. Es simple, lleva literalmente días implementar toda la pila.

EXI es muy difícil de codificar a mano, no hay procesadores decentes para él, y lo peor de todo es que todos los procesadores que he encontrado que realmente funcionan bien con él, simplemente lo transforman de EXI <-> XML, lo cual es totalmente inútil.

He recurrido a la escritura de mi propio analizador XSD, lo que significa que tengo que entender al menos toda la especificación XML para las partes de este diseño que lo usan, y eso es extenso. Lo que me hubiera tomado 2 semanas para hacer con cualquier especificación razonable, me llevó 10. Nadie en mi mundo va a usar esto a menos que se los meta en la garganta y no deberían, es una clavija cuadrada para un agujero redondo.