EXI (эффективный обмен XML)... Готовы ли XML API?

Ответ 1

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

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

Ответ 2

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

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

Если вы обрабатываете большие XML файлы (некоторые из них имеют несколько сотен MB), вы окончательно знаете, зачем вам нужен EXI: экономя много места, экономя огромное количество памяти и время обработки.

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

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

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

Ответ 3

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

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

Все, что утверждает, что это "последний двоичный стандарт", вероятно, неверно.

Ответ 4

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

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

• Подождите, пока EXI не будет включен в существующие пакеты SOAP (Axis/SAAJ) или
• Замените существующие существующие решения Axis/SAAJ SOAP для клиентов/поставщиков с помощью собственного SOAP-ish протокол поверх EXI

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

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

Ответ 5

Сейчас я имею дело с 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?

Хороший golly no!

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

+---- 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 бит, MINIMUM, чтобы не определять. Теперь я немного несправедлив, потому что я включаю разделители - разделители, которые совершенно не нужны.

Я понимаю, как это работает. Здесь spec:

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

Получайте удовольствие от чтения! Это было БОЛЬШОЙ СЛУЧАЙ ДЛЯ МЕНЯ!!!! @@##! @

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

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

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

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

Но существует ли это? Ну, черт возьми.

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

Напыщенная речь, huff huf

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

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

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

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

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