Скоро появится EXI (эффективный обмен XML) ... Готовы ли XML API? - PullRequest
12 голосов
/ 25 марта 2009

EXI W3 (эффективный обмен XML) будет стандартизирован. Он претендует на звание «последнего двоичного стандарта».

Это стандарт для хранения данных XML, оптимизированный для обработка и хранение, в комплекте с XML-схемой (создание данных сильно типизированный и сильно структурированный). Ну, есть много заявленные преимущества. Больше всего меня впечатлила обработка и измерения эффективности памяти.

Я спрашиваю себя, что произойдет со всеми установленными XML API?

Этот пункт связан с моим вопросом:

4.2 Существующие API обработки XML

Поскольку EXI является кодировкой XML Infoset, реализация EXI может поддерживать любой из обычно используемых API-интерфейсов XML для обработки XML, поэтому EXI не оказывает непосредственного влияния на существующие XML-API. Однако использование существующего XML API также требует, чтобы все имена и текст, появляющиеся в документе EXI, были преобразованы в строки. В будущем можно было бы добиться большей эффективности, если бы верхние уровни могли напрямую использовать эти данные в качестве типизированных значений, появляющихся в документе EXI. Например, если более высокий уровень нуждается в типизированных данных, просмотр его строковой формы может привести к снижению производительности, поэтому расширенный API, который напрямую поддерживает типизированные данные, может повысить производительность при использовании с EXI.

от: http://www.w3.org/TR/exi-impacts/

Я понимаю это следующим образом: "Использование EXI с существующими API? Нет прироста производительности! (Если вы не перепишите их все) "

Давайте возьмем экосистему Java в качестве примера:

В последней версии JDK 6 у нас есть множество API-интерфейсов XML. (С каждым новым выпуском JDK добавлялось все больше и больше.) Насколько я могу судить, большинство (если не все) из них используют либо деревья DOM в памяти или сериализованное («текстовое») представление преобразовать / обработать / проверить / ... данные XML.

Что вы, ребята, думаете, что произойдет с этими API с введением EXI?

Спасибо всем за ваше мнение.

Для тех, кто не знает EXI: http://www.w3.org/XML/EXI/

Ответы [ 5 ]

5 голосов
/ 15 декабря 2009

Вам не нужны никакие новые API, чтобы получить прирост производительности EXI. Все тесты EXI и измерения производительности, проводимые W3C, используют стандартные SAX API, встроенные в JDK. Последние тесты см. В http://www.w3.org/TR/exi-evaluation/#processing-results. В этих тестах синтаксический анализ EXI проходил в среднем в 14,5 раз быстрее, чем XML, без каких-либо специальных API.

Однажды, если люди сочтут это целесообразным, мы можем увидеть появление некоторых типизированных API XML. Если и когда это произойдет, вы получите еще лучшую производительность от EXI. Однако это не требуется для получения превосходной производительности, подобной той, о которой сообщает W3C.

4 голосов
/ 17 июля 2009

Давайте посмотрим на EXI как на «лучший GZIP для XML». К вашему сведению, это не влияет на API, так как вы все еще можете использовать их все (DOM, SAX, StAX, JAXB ...). Только для того, чтобы получить EXI, вы должны получить потоковую запись, которая пишет в нее, или потоковую программу, которая читает ее.

Наиболее эффективным способом выполнения EXI является StAX. Но это правда, что новый API может возникнуть из-за EXI. Но кто сказал, что DOM эффективен и хорошо разработан для современных языков; -)

Если вы работаете с большими XML-файлами (у меня есть несколько файлов размером в несколько сотен МБ), вы определенно знаете, зачем вам нужен EXI: экономия тонны пространства, большой объем памяти и время обработки.

Это не что иное, как цель кодирования содержимого HTTP: вам не нужно его использовать, просто если обе стороны понимают это, это очень эффективный способ выполнить обмен.

Кстати, EXI станет предпочтительным способом инкорпорирования контента любого XML через HTTP IMHO из-за раздувания SOAP ;-) Как только EXI установит настройки в браузерах, это также может принести пользу любому конечному пользователю: более быстрый перенос, более быстрый анализ = лучший опыт для той же машины!

EXI не осуждает строковое представление, только делает его немного другим. Да, и, кстати, когда вы выполняете UTF (например, по умолчанию UTF8), вы уже используете «кодирование сжатия» для 32-битной кодовой точки Unicode ... это означает, что данные в проводнике не совпадают с реальными данными уже; -)

2 голосов
/ 28 июня 2016

Я сейчас имею дело с EXI.

Нет хорошего универсального инструмента для обработки EXI. Как только вы разберетесь в EXI, вы поймете, что в двоичном потоке есть куча ненужных разделителей, которые абсолютно и совершенно не нужны для схемы. Отчасти это смешно.

Как вы думаете, будет ли закодировано следующее в EXI, если указаны оба значения?

<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>

Как вы думаете, это может быть максимум 4 бита? 1 бит, чтобы указать, определен ли bool1, и что значение bool1, а затем еще один бит, чтобы указать, определен ли bool2, тогда значение bool2?

Боже, нет!

Хорошо, позвольте мне рассказать вам, мальчики и девочки! Вот как это на самом деле кодируется

+---- 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)

Минимум 4 бита, МИНИМАЛЬНЫЙ, чтобы не определять ни того, ни другого. Теперь я немного несправедлив, потому что я включаю разделители - разделители, которые совершенно не нужны.

Теперь я понимаю, как это работает. Вот спецификация:

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

Приятного чтения! Это было БОЛЬШОЕ ДЕЛО ФУНДАМЕНТА ДЛЯ МЕНЯ !!!! @@ ##! @

Теперь это только со схемой, и спецификация EXI специально говорит, что вы все еще можете кодировать XML, который НЕ соответствует схеме. Что весело, потому что это должно быть для маленьких маленьких веб-устройств. Что вы делаете с неожиданными данными, которые у вас нет условий для обработки во встроенном устройстве?

Да ведь ты просто умрешь, конечно. Там нет восстановления для чего-то, что вы не ожидаете. У этих вещей нет экрана, мне повезло, если я могу войти в него через последовательный порт.

Я использовал 4 разных генератора XSD / парсеры / генераторы XML. 3 из них задыхаются от схемы, которую я должен использовать. Маршалинг данных для C и C ++ (помните, что для системы EMBEDDED с очень небольшим объемом памяти и процессорной мощностью) ужасен.

XSD описывает в основном структуру или архитектуру классов, и я не могу найти ни одного инструмента, который бы просто создавал классы. Пример XSD, который я привел выше, должен создать структуру с 4 bools, 2 bools - значения, а 2 bools указывают, определены ли они вообще.

Но ЭТО существует? Ну, черт возьми, нет.

Мне нравится XML для описания документов. На самом деле я делаю - но вот что я ненавижу в XML - для широко принятого стандарта, доступные инструменты для него абсолютно ужасны. Просто читать схему сложно, если она распространяется по нескольким пространствам имен и документам.

Rant rant, huff huf

Единственная причина, по которой мы используем это, - настаивал на этом какой-то комитет по стандартам. То, что это сделано, - это создание монополии для небольшой группы компаний, которая уже внедрила это, и это единственная цель.

EXI не является общепринятым стандартом, XML - плохой инкапсулятор для числовых данных, и его сложно реализовать, и для него нет достойных инструментов. EXIP имеет версию 5.0 - все, что работает с открытым исходным кодом, находится на Java - по крайней мере, у меня это есть.

Для моей сферы деятельности EXI - просто плохое дизайнерское решение. Я работал над множеством протоколов связи в различных встроенных системах. Я работал над DOCSIS, который используют все современные кабельные модемы - они используют простой и расширяемый протокол Type / Length / Value с положениями для работы с нераспознанными типами - именно поэтому длина всегда включена. Это просто, для реализации всего стека требуется буквально дни.

EXI очень сложен в написании кода, для него нет достойных процессоров, и, что хуже всего, все процессоры, которые я нашел, действительно работают с ним, просто преобразуйте его из EXI <-> XML - который полностью бесполезно.

Я прибег к написанию собственного синтаксического анализатора XSD, а это значит, что я должен понять, по крайней мере, всю спецификацию XML для тех частей этого проекта, которые его используют - и это обширно. То, что заняло бы у меня 2 недели, чтобы справиться с какой-либо разумной спецификацией, заняло у меня 10. Никто в моем мире не собирается использовать это, если оно не сдвинуло их горло и не должно, это квадратный колышек для круглого отверстия. *

2 голосов
/ 05 октября 2012

Проблема с EXI заключается в том, что он должен быть абстрагирован от кода вашего приложения. Я работаю над промежуточным программным продуктом, в котором понятная человеку природа XML является ключевой в определенных аспектах (ведение журнала, поиск неисправностей и т. Д.), Но может быть принесена в жертву в других областях (обмен данными между внутренними приложениями для ограничения нагрузки ввода-вывода).

В настоящее время мы используем SOAP для связи между веб-приложениями клиента, промежуточного программного обеспечения и поставщика или для них. Я хотел бы заменить это на EXI, сохранив читаемый человеком XML в других областях. Чтобы заменить связь SOAP с EXI, мне нужно:

  1. Подождите, пока EXI не будет включен в существующие стеки SOAP (Axis / SAAJ), или
  2. Заменить мои существующие реализации клиента / поставщика Axis / SAAJ SOAP на мой собственный SOAP-иш протокол поверх EXI

Сравнение между JSON и EXI справедливо, но варианты их использования различны. Не существует стандарта для метаданных для JSON, в то время как есть XML-схема для XML. В XML есть несколько органов стандартизации, которые определяют схемы для обмена данными для конкретных отраслей. Существует также ряд протоколов / стандартов, основанных на XML, таких как SOAP, XML-подпись, XML-шифрование, WS-Security, SAML и т. Д. Этого не существует для JSON.

Следовательно, XML является лучшим вариантом для обмена сообщениями B2B и в других случаях, когда вам необходимо интегрироваться с внешними системами с использованием отраслевых стандартов. EXI может принести некоторые из преимуществ JSON в этот мир, но его необходимо включить в существующие XML-API, прежде чем можно будет широко применять его.

2 голосов
/ 25 марта 2009

Лично я бы предпочел вообще не использовать EXI. Кажется, что он берет все неуклюжие, плохие вещи в XML и объединяет их в двоичный формат, который в основном удаляет изящество экономии XML (простой текстовый формат).

Похоже, что общая тенденция в отрасли - переход к более легким моделям передачи данных (например, HTTP REST) ​​и отход от таких более тяжелых моделей, как SOAP. Лично я не очень взволнован идеей двоичного XML.

Все, что претендует на звание "последнего двоичного стандарта", вероятно, неверно.

...