EXI (intercambio eficaz de XML) por venir ... ¿Están listas las API XML?

Question

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

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

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

No es este párrafo se refería a mi pregunta:

4.2 existentes API de procesamiento de XML

Como EXI es una codificación del conjunto de información XML, una aplicación EXI puede apoyar cualquiera de los XML de uso general API para el procesamiento 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 de la siguiente manera: "?! Usando EXI con las API existentes ninguna mejora del rendimiento (A menos que todos ellos volver a escribir)"

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 de ellas) Por lo que puedo juzgar, la mayoría (si no todos) están usando árboles DOM en memoria, o representación serializada ("textual") para transformar/procesar/validar/... datos XML.

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

Gracias a todos por sus opiniones.

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

Answer 1

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.

Answer 2

yo personalmente preferiría no utilizo EXI en absoluto. Parece que está tomando todas las cosas malas y torpes sobre XML, y atiborrándolos en un formato binario, que básicamente elimina la gracia de ahorro 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.

Cualquier cosa que dice ser "el último estándar binario" probablemente sea incorrecta.

Answer 3

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 DOM es eficiente y está bien diseñado para los idiomas modernos ;-)

Si está manejando grandes archivos XML (tengo algunos de ellos que son pocos cientos de MB), definitivamente sabe por qué necesita EXI: ahorrar toneladas de espacio, ahorrando gran cantidad de memoria y tiempo de procesamiento.

Esto no es nada diferente a la finalidad de codificación de contenido HTTP: no es necesario que lo use, simplemente que 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-encore 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, más rápido análisis = ¡la mejor experiencia de 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 ;-)

Answer 4

El problema con EXI es que debe abstraerse del código de la 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 cliente propio, middleware y aplicaciones web de proveedores. Me gustaría reemplazar esto con EXI, conservando XML legible para humanos en otras áreas. Con el fin de sustituir la comunicación SOAP con EXI yo tampoco necesito:

1. Esperar hasta EXI se ha incorporado en pilas de SOAP existentes (Eje ​​/ SAAJ), o
2. reemplazar mis implementaciones de cliente Axis/SAAJ SOAP/proveedor existentes con mi propio jabón-ish protocolo en la parte superior 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 que utilizan 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.

Answer 5

Estoy lidiando con EXI ahora mismo.

No existe 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ía 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?

Good golly no!

Bueno, ¡déjenme decirles chicos y chicas! Así es como está codificado en realidad

+---- 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 esto! ¡Fue una GRAN OFERTA DE DIVERSIÓN PARA MI !!!! @@ ##! @

Ahora esto es solo con un esquema, y ​​la especificación EXI dice específicamente que aún puede codificar XML que NO se ajusta a 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é, simplemente 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 diferentes generadores/analizadores XSD/XML generators. 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 estructura o clase 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 diatriba, Huff HUF

La única razón por la que estamos usando esto es un comité de estándares insistido 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 los datos numéricos, y es complicado implementarlo y no hay herramientas decentes para ello. 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, todos los procesadores que he encontrado que realmente funcionan bien con él, simplemente transfórmalo de EXI < -> XML - que 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 utilizan, 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.