В последнее время меня все чаще стала посещать мысль о принципиальной несовместимости XML и эффективных программ
В связи с этим, меня заинтересовала возможность создания документов, полностью дублирующих все возможности XML, но без его проблем с эффективностью разбора. Поискал в гугле — и у меня просто глаза разбежались от обилия реализаций и дискуссий на эту тему
К сожалению, большинство этих обсуждений — это holy war в чистом виде, и полезной информации там не очень много.
Поэтому хотелось бы спросить — а кто уже использовал какие-то реализации сабжа в своих проектах? Какие именно реализации? Какие остались впечатления?
Дарней -> "Binary XML"
Д> В последнее время меня все чаще стала посещать мысль о принципиальной Д> несовместимости XML и эффективных программ Д> В связи с этим, меня заинтересовала возможность создания документов, Д> полностью дублирующих все возможности XML, но без его проблем с Д> эффективностью разбора. Поискал в гугле — и у меня просто глаза Д> разбежались от обилия реализаций и дискуссий на эту тему Д> К сожалению, большинство этих обсуждений — это holy war в чистом Д> виде, и полезной информации там не очень много. Д> Поэтому хотелось бы спросить — а кто уже использовал какие-то Д> реализации сабжа в своих проектах? Какие именно реализации? Какие Д> остались впечатления?
А что для тебя является критерием эффективности? Что не устраивает?
Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон
Как бинарный способ енкодинга данных, функционально аналогичный XML-ю могу порекомендовать ASN.1
Давным давно устоявшийся и по сю пору плавно эволюционирующий промышленный стандарт ( родился аж в 80х годах прошлого века)
С инструментарием правда ситуацию осветить пожалуй не смогу — в своих проектах используем собственную библиотеку по работе с ASN.1. Библиотечка была создана года два назад по результатам обзора рынка на тот момент — все бесплатное было "ниже плинтуса" да еще с неудобными лицензиями, а платное либо не по карману, либо не устраивало по другим критериям.. Возможно сейчас ситуация изменилась в лучшую сторону ...
J.J.OK -> "Re: Binary XML"
JO> Здравствуйте, Дарней, Вы писали: JO> [...]
JO> Как бинарный способ енкодинга данных, функционально аналогичный JO> XML-ю могу порекомендовать ASN.1 JO> Давным давно устоявшийся и по сю пору плавно эволюционирующий JO> промышленный стандарт ( родился аж в 80х годах прошлого века) JO> С инструментарием правда ситуацию осветить пожалуй не смогу — в JO> своих проектах используем собственную библиотеку по работе с ASN.1. JO> Библиотечка была создана года два назад по результатам обзора рынка JO> на тот момент — все бесплатное было "ниже плинтуса" да еще с JO> неудобными лицензиями, а платное либо не по карману, либо не JO> устраивало по другим критериям.. Возможно сейчас ситуация изменилась JO> в лучшую сторону ...
Хм... у меня вопрос — а какие задачи вы решали? Для чего нужен был именно
бинарный формат?
Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон
Здравствуйте, hrg, Вы писали:
hrg>J.J.OK -> "Re: Binary XML"
JO>> Здравствуйте, Дарней, Вы писали: JO>> [...]
hrg>Хм... у меня вопрос — а какие задачи вы решали? Для чего нужен был именно hrg>бинарный формат?
Удостоверяющий Центр сделали — тот который X.509-сертификаты выдает и кое что еще. В общем наша поляна — все что вокруг PKI и защищенного документооборота и цифровых подписей. В этой области все (почти ) стандартизировано и все ( почти ) на ASN.1
Здравствуйте, hrg, Вы писали:
hrg>А что для тебя является критерием эффективности? Что не устраивает?
Я вижу в XML как минимум одну принципиальную проблему:
Для того, чтобы найти некоторый элемент в документе, необходимо просмотреть весь текст от начала документа до начала нужного элемента. Это — в том случае, если использовать SAX. В случае с DOM все еще хуже
Иными словами — если программе нужно извлечь из файла конфигурации .NET некоторый параметр, и этот параметр последний в списке — то парсер будет добросовестно просматривать весь список параметров, пока не найдет параметр с нужным именем
Возможность читать XML в notepad'e — это полезная фича... но не такой же ценой.
Здравствуйте, J.J.OK, Вы писали:
JJO>Как бинарный способ енкодинга данных, функционально аналогичный XML-ю могу порекомендовать ASN.1
хотелось бы такой формат, который совместим по всем фичам — иными словами, чтобы можно было заменить парсер XML на парсер этого формата без необходимости менять логику. Например, довольно часто упоминается некий BiM — он используется как часть стандарта MPEG-7.
[...]
Д>Я вижу в XML как минимум одну принципиальную проблему:
Д>Для того, чтобы найти некоторый элемент в документе, необходимо просмотреть весь текст от начала документа до начала нужного элемента. Это — в том случае, если использовать SAX. В случае с DOM все еще хуже Д>Иными словами — если программе нужно извлечь из файла конфигурации .NET некоторый параметр, и этот параметр последний в списке — то парсер будет добросовестно просматривать весь список параметров, пока не найдет параметр с нужным именем
Д>Возможность читать XML в notepad'e — это полезная фича... но не такой же ценой.
ну тогда прямая дорога хранить конфиги в базе хотя если тебя больше заботит ресурсоемкость "просмотра" и компактность енкодинга, а не сам факт того что нужно "просматривать" — то варианты остаются
J.J.OK -> "Re[3]: Binary XML"
hrg>>Хм... у меня вопрос — а какие задачи вы решали? Для чего нужен был hrg>>именно hrg>>бинарный формат?
JO> Удостоверяющий Центр сделали — тот который X.509-сертификаты выдает JO> и кое что еще. В общем наша поляна — все что вокруг PKI и JO> защищенного документооборота и цифровых подписей. В этой области все JO> (почти ) стандартизировано и все ( почти ) на ASN.1
Понятно. Глупый вопрос — а просто сжатый zip-ом xml не прокатил был?
Дарней -> "Re[2]: Binary XML"
hrg>>А что для тебя является критерием эффективности? Что не устраивает?
Д> Я вижу в XML как минимум одну принципиальную проблему:
Д> Для того, чтобы найти некоторый элемент в документе, необходимо Д> просмотреть весь текст от начала документа до начала нужного Д> элемента. Это — в том случае, если использовать SAX. В случае с DOM Д> все еще хуже
Хм... а насколько часто происходят эти поиски? Наколько велик документ?
Yury Kopyl aka hrg | Любой служащий должен строго выполнять свои
обязанности. А практически каждый занимается на работе чем хочет. (с)
Паркинсон
Здравствуйте, hrg, Вы писали:
hrg>Хм... а насколько часто происходят эти поиски? Наколько велик документ?
я говорю не о каком-то конкретном случае, а "в общем"
В случае XML нет например эффективного способа реализовать DOM через fly-weight. Поэтому остаются только два варианта — кэшировать все данные из документа в памяти (пожирает ресурсы), или каждый раз искать данные в документе (очень медленно).
Здравствуйте, Дарней, Вы писали:
AVK>>Здесь МС пытается что то на эту тему сообразить, но что из этого получится
Д>А почему там написано, что это obsolete?
А потому что у них семь пятниц на неделе. Новые классы и методы, объявленные obsolete последнее время стали попадаться прямо таки массово. С одной стороны непонятно что в итоге будет, с другой стороны вроде как видно что работат по проектированию ведется серьезная, а не как получится. ИМХО с большой долей вероятности бинарная реализация XmlWriter будет, но вот какая
когда дело доходить до бинарщины — значит важен размер и скорость
значит тебе ни один формат не подойдет, потому что он будет иметь некие излишества для поддержки общности
JJO>Как бинарный способ енкодинга данных, функционально аналогичный XML-ю могу порекомендовать ASN.1 JJO>Давным давно устоявшийся и по сю пору плавно эволюционирующий промышленный стандарт ( родился аж в 80х годах прошлого века) JJO>С инструментарием правда ситуацию осветить пожалуй не смогу — в своих проектах используем собственную библиотеку по работе с ASN.1. Библиотечка была создана года два назад по результатам обзора рынка на тот момент — все бесплатное было "ниже плинтуса" да еще с неудобными лицензиями, а платное либо не по карману, либо не устраивало по другим критериям.. Возможно сейчас ситуация изменилась в лучшую сторону ...
Библиотека работы с ASN.1 (по-моему, достаточно богатая) есть в Erlang.
По поводу альтернативы XML кое-что любопытное есть здесь. (Кстати, там есть интересные идеи и помимо альтернативного формата)
Здравствуйте, Banch, Вы писали:
B>когда дело доходить до бинарщины — значит важен размер и скорость B>значит тебе ни один формат не подойдет, потому что он будет иметь некие излишества для поддержки общности
Скорость не важна если позиционировать XML как формат конфиг-файлов 2-3 килобайтных, редактируемых в notepad.
Но преобразовывать объектную модель в текстовый формат, для передачи по сети, и после передачи обратно в объектную модель — это уже очень сомнитльное удовольствие.
Здравствуйте, Дарней, Вы писали:
Д>Я вижу в XML как минимум одну принципиальную проблему:
Д>Для того, чтобы найти некоторый элемент в документе, необходимо просмотреть весь текст от начала документа до начала нужного элемента. Это — в том случае, если использовать SAX. В случае с DOM все еще хуже Д>Иными словами — если программе нужно извлечь из файла конфигурации .NET некоторый параметр, и этот параметр последний в списке — то парсер будет добросовестно просматривать весь список параметров, пока не найдет параметр с нужным именем
А чем поможет бинарный формат? Его ведь так же необходимо прочитать.
В данном случае помогут только индексы, их есть и у XML.
Д>Возможность читать XML в notepad'e — это полезная фича... но не такой же ценой.
Здравствуйте, Silver_s, Вы писали:
S_> Но преобразовывать объектную модель в текстовый формат, для передачи по сети, и после передачи обратно в объектную модель — это уже очень сомнитльное удовольствие.
Зато стандартно, гарантированно прочитается везде (ASCII понимают все), имеет кучу всяких плюшек (типа XPath, xslt).
Здравствуйте, Banch, Вы писали: B>когда дело доходить до бинарщины — значит важен размер и скорость B>значит тебе ни один формат не подойдет, потому что он будет иметь некие излишества для поддержки общности
Если требуется выжать максимум производительности и компактность, то да. Но идеальное решение требуется редко. Для средних задач подойдёт средняя производительность.
Здравствуйте, Дарней, Вы писали:
Д>В последнее время меня все чаще стала посещать мысль о принципиальной несовместимости XML и эффективных программ Д>В связи с этим, меня заинтересовала возможность создания документов, полностью дублирующих все возможности XML, но без его проблем с эффективностью разбора. Поискал в гугле — и у меня просто глаза разбежались от обилия реализаций и дискуссий на эту тему Д>К сожалению, большинство этих обсуждений — это holy war в чистом виде, и полезной информации там не очень много. Д>Поэтому хотелось бы спросить — а кто уже использовал какие-то реализации сабжа в своих проектах? Какие именно реализации? Какие остались впечатления?
BiM. Бинарный XML, компактный и быстрый. Применяется и разработан для MPEG7 (http://www.citforum.ru/nets/semenov/2/25/mpeg_7.shtml), но при этом совершенно универсален.
Парсится напрямую, без преобразования в текст, раз в 50 быстрее XML. При этом, это именно XML-технология, а не альтернативная ботва. Может рассматриваться как Schema-based XML Compression. Тесты технологии обнадеживают. Google. Я бы попробовал применить эту фигню, если встала необходимость.
Здравствуйте, master_of_shadows, Вы писали: Д>>Иными словами — если программе нужно извлечь из файла конфигурации .NET некоторый параметр, и этот параметр последний в списке — то парсер будет добросовестно просматривать весь список параметров, пока не найдет параметр с нужным именем __>А чем поможет бинарный формат? Его ведь так же необходимо прочитать.
В бинарном формате рядом с каждым тегом можно указывать его общую длину (вместе с вложенными тегами). Тогда можно например, начать парсить 2-й тег, не разбирая 1-й. Так, конечно, можно поступить и в текстовом формате. Но как тогда быть с незначащими пробелами? Добавив такой пробел, мы изменим физическую длину тега и парсинг поломаем. Так по идее быть не должно.
Здравствуйте, beroal, Вы писали:
B>В бинарном формате рядом с каждым тегом можно указывать его общую длину (вместе с вложенными тегами). Тогда можно например, начать парсить 2-й тег, не разбирая 1-й. Так, конечно, можно поступить и в текстовом формате. Но как тогда быть с незначащими пробелами? Добавив такой пробел, мы изменим физическую длину тега и парсинг поломаем. Так по идее быть не должно.
в бинарном формате можно перед каждым куском текста указывать его длину, что избавляет от необходимости использовать "символические сущности" и esacpe-последовательности — таким образом отпадают накладные расходы на преобразование текста. При поиске элемента нет необоходимости просматривать весь текст — достаточно пробежаться по заголовкам элементов.
Или, другой вариант — построить глобальную таблицу индексов всех элементов. Адрес нужного элемента можно извлечь из нее, и избавиться от необходимости искать по тексту вообще.
Разница по скорости парсинга по сравнению с текстовым XML должна быть на порядки.
Здравствуйте, Дарней, Вы писали: Д>Или, другой вариант — построить глобальную таблицу индексов всех элементов. Адрес нужного элемента можно извлечь из нее, и избавиться от необходимости искать по тексту вообще.
Тогда это будет уже сетевая база данных.
Здравствуйте, beroal, Вы писали:
B>В бинарном формате рядом с каждым тегом можно указывать его общую длину (вместе с вложенными тегами). Тогда можно например, начать парсить 2-й тег, не разбирая 1-й.
тогда получается, что такие данные нельзя записывать в поток! что особенно критично для бинарщины
т.е. мы получаем просто линейную последовательность блоков: тип, размер, данные, тип размер данные, ...
Здравствуйте, Banch, Вы писали:
B>>В бинарном формате рядом с каждым тегом можно указывать его общую длину (вместе с вложенными тегами). Тогда можно например, начать парсить 2-й тег, не разбирая 1-й. B>тогда получается, что такие данные нельзя записывать в поток! что особенно критично для бинарщины
В обычный поток — да. Можно сделать специальный поток, в котором будут команды "открыть тег", "закрыть тег".
B>т.е. мы получаем просто линейную последовательность блоков: тип, размер, данные, тип размер данные, ...
Почему же только линейная? Может быть и дерево. Собственно, его я и имел в виду. Длина тега включая вложенные теги. Действительно, формировать "лениво" такой файл нельзя, только целиком (так как нужно вычислить длину тега самого верхнего уровня, которая равна длине всего файла).
Я имел в виду, что в предложенном мною формате время поиска некоторого тега пропорционально длине пути к нему, тогда как для текстового формата пропорционально количеству всех тегов (грубая оценка).
Но это уже будет не формат данных, а специализированная БД. Т.е. при передаче данных предполагается, что данные будут читаться полностью, а БД именно для поиска данных. Короче, надо просто указывать количество вложенных тегов, и не морочить голову с оптимизацией поиска. Оптимизация пусть выполняется на клиенте.
Кстати, XML имеет избыточность, которую совсем не обязательно перетаскивать в бинарный формат: атрибуты есть частный случай вложенных тегов.
Здравствуйте, beroal, Вы писали:
B>>тогда получается, что такие данные нельзя записывать в поток! что особенно критично для бинарщины B>В обычный поток — да. Можно сделать специальный поток, в котором будут команды "открыть тег", "закрыть тег".
А теперь попробуй передать такой поток по сети. Заодно подумай что произойдет если байт с размером при передаче побьется.
B>>т.е. мы получаем просто линейную последовательность блоков: тип, размер, данные, тип размер данные, ... B>Почему же только линейная? Может быть и дерево. Собственно, его я и имел в виду. Длина тега включая вложенные теги.
Т.е., если мы передаем по сети, то передать тег мы можем только когда у нас есть все вложенные. Учитывая то что в XML всегда присутствует корневой тег получаем забавную фичу — пока весь документ не сформирован передавать его по сети мы не сможем.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Gaperton, Вы писали:
G>>BiM. Бинарный XML, компактный и быстрый. Применяется и разработан для MPEG7 (http://www.citforum.ru/nets/semenov/2/25/mpeg_7.shtml), но при этом совершенно универсален.
Д>я уже встречал ссылки на него... А ты не видел где-нибудь описание самого стандарта?
Нет. Спецификация существует, есть и реализации. Искать надо — у меня просто не было серьезной в том необходимости.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, beroal, Вы писали:
B>>>тогда получается, что такие данные нельзя записывать в поток! что особенно критично для бинарщины B>>В обычный поток — да. Можно сделать специальный поток, в котором будут команды "открыть тег", "закрыть тег".
AVK>А теперь попробуй передать такой поток по сети. Заодно подумай что произойдет если байт с размером при передаче побьется.
Проверка на вшивость пакета, это несколько другая песня из более низкого протокола. Однако, в данном случае, мы будем знать, что пакету доверять нельзя. После окончания длины должен быть тэг следующего объекта, или окончание пакета (ASN1).
B>>>т.е. мы получаем просто линейную последовательность блоков: тип, размер, данные, тип размер данные, ... B>>Почему же только линейная? Может быть и дерево. Собственно, его я и имел в виду. Длина тега включая вложенные теги.
AVK>Т.е., если мы передаем по сети, то передать тег мы можем только когда у нас есть все вложенные. Учитывая то что в XML всегда присутствует корневой тег получаем забавную фичу — пока весь документ не сформирован передавать его по сети мы не сможем.
В принципе, если представить, что заключающий тег корневого элемента является флагом конца пересылки сообщения, а заключающий тег вложенного объекта — флаг конца пересылки объекта, то все встает на свои места. В XML это весьма даже удобно.
То что описано, с некоторыми поправками является велосипедом, и называется ASN1. Формат старый и сейчас применяется только для X509.
С уважением, Gleb.
Здравствуйте, AndrewVK, Вы писали:
AVK>Т.е., если мы передаем по сети, то передать тег мы можем только когда у нас есть все вложенные. Учитывая то что в XML всегда присутствует корневой тег получаем забавную фичу — пока весь документ не сформирован передавать его по сети мы не сможем.
На самом деле, для такого случая больше подходит другой вариант — передавать длину только перед кусками плоского текста (внутри элемента или в его имени, например)
Просто вариантов кодирования много, и каждый хорошо подходит для одной определенной цели. Одинаково для всех целей подходит только текстовый XML... одинаково плохо
Здравствуйте, Дарней, Вы писали: Д>Просто вариантов кодирования много, и каждый хорошо подходит для одной определенной цели. Одинаково для всех целей подходит только текстовый XML... одинаково плохо
Я предлагаю вам сформулировать требования к формату данных (e.g. компактность, простота, гибкость etc). Вас что-то не устраивает, но непонятно, что.
Здравствуйте, beroal, Вы писали:
B>Я предлагаю вам сформулировать требования к формату данных (e.g. компактность, простота, гибкость etc). Вас что-то не устраивает, но непонятно, что.
про это я уже писал.
1. Необходимость преобразовывать текст при его сохранении/извлечении в XML (ну а с бинарными данными все еще хуже... но это второстепенное)
2. Необходимость просматривать текст посимвольно, чтобы найти начало следующего узла
Здравствуйте, GlebZ, Вы писали:
AVK>>А теперь попробуй передать такой поток по сети. Заодно подумай что произойдет если байт с размером при передаче побьется. GZ>Проверка на вшивость пакета, это несколько другая песня из более низкого протокола.
Почему ж другая. Та же. Вот текстовый xml себя при передаче по сети ведет себя неплохо.
AVK>>Т.е., если мы передаем по сети, то передать тег мы можем только когда у нас есть все вложенные. Учитывая то что в XML всегда присутствует корневой тег получаем забавную фичу — пока весь документ не сформирован передавать его по сети мы не сможем. GZ>В принципе, если представить, что заключающий тег корневого элемента является флагом конца пересылки сообщения, а заключающий тег вложенного объекта — флаг конца пересылки объекта, то все встает на свои места. В XML это весьма даже удобно.
Здравствуйте, Дарней, Вы писали:
Д>про это я уже писал. Д>1. Необходимость преобразовывать текст при его сохранении/извлечении в XML (ну а с бинарными данными все еще хуже... но это второстепенное) Д>2. Необходимость просматривать текст посимвольно, чтобы найти начало следующего узла
Просто для справки: для ASN.1, в виду разнородности требований приложений, определены различные правила енкодинга. В том числе есть BER (Basic Encoding Rules), позволяющие упаковывать в ASN.1 поток данных неопределенной длинны и отправлять упакованное частями — по мере поступления данных для енкодинга. Понятно, что накладные расходы и требования по памяти при енкодинге/декодинге будут зависеть от выбранных правил ИМХО, ASN.1 в любом случае дешевле чем XML... ну да не о том.
Еще для справки — куча сетевых протоколов (тот-же LDAP) построена с использованием ASN.1 для транспорта сообщений — и ничего никто не жалуется что битики пропадают
Кстати, если при передаче XML-я побьется байтик в одном из тэгов — ситуация будет ничем не лучше.
А в общем задача обеспечения целостности решается либо засчет протокола транспортного уровня, либо внедрением в прикладной (читай в формат сообщения) доп информации (контрольные суммы, хэши, подписи и т.п.)
VladD2,
> ПК> По-моему можно совместить приятное с полезным, кэшируя бинарное представление XML.
> С какй целью?
В цитате было. Чтобы и глазами смотреть/руками редактировать можно было (удобство), и чтобы при зачитывании каждый раз не грузился целиком и не парсился текстовый XML (скорость). Это, конечно, не все use cases покрывает, но описанный в процитированном сообщении — легко.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Дарней, Вы писали:
VD>Мне кажется бинарный ХМЛ в чистом виде — это бессмысленная затея. А вот ХМЛ БД очень даже разумная вещь.
Я бы сказал больше, бинарные XML не является XMLом
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
AVK>>>А теперь попробуй передать такой поток по сети. Заодно подумай что произойдет если байт с размером при передаче побьется. GZ>>Проверка на вшивость пакета, это несколько другая песня из более низкого протокола.
AVK>Почему ж другая. Та же. Вот текстовый xml себя при передаче по сети ведет себя неплохо.
Например чем?
AVK>>>Т.е., если мы передаем по сети, то передать тег мы можем только когда у нас есть все вложенные. Учитывая то что в XML всегда присутствует корневой тег получаем забавную фичу — пока весь документ не сформирован передавать его по сети мы не сможем. GZ>>В принципе, если представить, что заключающий тег корневого элемента является флагом конца пересылки сообщения, а заключающий тег вложенного объекта — флаг конца пересылки объекта, то все встает на свои места. В XML это весьма даже удобно.
AVK>А как же с размерами?
То же самое. Так сказать, два пути к одному и тому-же. Оба способа являются эквивалентными.
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется бинарный ХМЛ в чистом виде — это бессмысленная затея. А вот ХМЛ БД очень даже разумная вещь.
ну почему же... это будет давать все возможности существующего XML, без необходимости менять использующий код — при этом получив немаленькое увлеичение скорости. Собственно, большинство из описанных в документе либ идут именно по этому пути, насколько можно судить по описанию.
А XML BD — это было бы очень полезной надстройкой над Binary-XML
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В цитате было. Чтобы и глазами смотреть/руками редактировать можно было (удобство), и чтобы при зачитывании каждый раз не грузился целиком и не парсился текстовый XML (скорость). Это, конечно, не все use cases покрывает, но описанный в процитированном сообщении — легко.
в результате мы получим еще больший объем данных, и кучу проблем по синхронизации собственно XML и бинарного индекса
хотя ускорение парсинга — да, это мы все-таки получим
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, GlebZ, Вы писали:
GZ>>Я бы сказал больше, бинарные XML не является XMLом
Д>почему?
Потому что у XML есть спецификация, даже две. У него есть предок в виде SGML. Потому что текстуальность ее обусловлена не только тем что удобно просматривать, но и тем что она проходит через все виды сетей. Поэтому, отказываясь от текстуальности (какой-то дурной термин), вы не только перечеркиваете его историю, но и его свойство кроссплатформенности. Бинарный формат более эффективен не в виде XML.
Существуют форматы кодирования XML в бинарный вид, но не работа с XML в бинарном виде.
Здравствуйте, GlebZ, Вы писали:
AVK>>Почему ж другая. Та же. Вот текстовый xml себя при передаче по сети ведет себя неплохо. GZ>Например чем?
По крайней мере он лишен тех проблем, которые я описал.
GZ>>>В принципе, если представить, что заключающий тег корневого элемента является флагом конца пересылки сообщения, а заключающий тег вложенного объекта — флаг конца пересылки объекта, то все встает на свои места. В XML это весьма даже удобно.
AVK>>А как же с размерами? GZ>То же самое.
Что то же самое? Я тебе на пальцах показал что требование указывать размер тега приводит к заднице при передаче по сети.
GZ> Так сказать, два пути к одному и тому-же. Оба способа являются эквивалентными.
Здравствуйте, GlebZ, Вы писали:
GZ>Потому что у XML есть спецификация, даже две. У него есть предок в виде SGML. Потому что текстуальность ее обусловлена не только тем что удобно просматривать, но и тем что она проходит через все виды сетей. Поэтому, отказываясь от текстуальности (какой-то дурной термин), вы не только перечеркиваете его историю, но и его свойство кроссплатформенности. Бинарный формат более эффективен не в виде XML.
Давайте все-таки отделим мух от котлет. Одно дело — кроссплатформенность, другое дело — передача через сеть.
1. Кроссплатформенность и текстовое представление совершенно ортогональны. Никто не мешает сделать кросс-платформенный бинарный формат в виде потока байт, а на каждой конкретной платформе приводить каждый тип данных в принятому на данной платформе типу. (так и слышу, что кто-нибудь начинает кричать "а какая же разница по сравнению с текстом, если все равно нужно преобразовывать данные?". Ответ прост — разница в эффективности)
2. Любые сети прекрасно передают бинарные данные — собственно, на этом они и построены :-D Другой вопрос, что некоторые клиенты имеют доступ только через HTTP прокси. Специально для таких случаев документ можно перекодировать с помощью base64, к примеру — и никаких проблем не будет.
GZ>Существуют форматы кодирования XML в бинарный вид, но не работа с XML в бинарном виде.
не думаю... нет никаких принципиальных проблем, чтобы создать парсер для бинарного XML, который будет полностью имитировать обычный текстовый XML на уровне интерфейса парсера
Здравствуйте, AndrewVK, Вы писали:
AVK>Что то же самое? Я тебе на пальцах показал что требование указывать размер тега приводит к заднице при передаче по сети.
Абсолютно также, если потерялся в заключительном теге символ '/', эффект абсолютно тот же.
GZ>> Так сказать, два пути к одному и тому-же. Оба способа являются эквивалентными.
AVK>Эквивалентно некудышными?
Для замены задачи подсчета контрольной суммы, да.
Здравствуйте, Дарней, Вы писали:
Д>в результате мы получим еще больший объем данных, и кучу проблем по синхронизации собственно XML и бинарного индекса Д>хотя ускорение парсинга — да, это мы все-таки получим
Один пример — в Юконе внутрях XML хранится в бинарном виде, и в бинарном же он его отдает по сети.
Здравствуйте, AndrewVK, Вы писали:
AVK>По крайней мере он лишен тех проблем, которые я описал.
если побьется хотя бы один символ "<" к примеру, то задница будет ничуть не меньшая — парсер не сможет разобрать документ. Или ты предполагаешь восстанавливать документ вручную?
не вижу никакой разницы
Здравствуйте, GlebZ, Вы писали:
AVK>>Что то же самое? Я тебе на пальцах показал что требование указывать размер тега приводит к заднице при передаче по сети. GZ>Абсолютно также, если потерялся в заключительном теге символ '/', эффект абсолютно тот же.
Неа. В XML это будет ошибка синтаксиса, а вот в твоем случае ты просто какое то время будет парсить неверным образом. Если ты попытаешься ввести какие то синтаксические правила контроля структуры бианрника (теги, метки, сигнатуры), то получишь в итоге тот же XML, только в нечитаемом, но быстро отпарсиваемом виде.
Здравствуйте, Дарней, Вы писали:
AVK>>По крайней мере он лишен тех проблем, которые я описал.
Д>если побьется хотя бы один символ "<" к примеру, то задница будет ничуть не меньшая — парсер не сможет разобрать документ.
Проблема не в том что парсер не сможет разобрать документ, проблема в том что столь примитивный бинарный формат, что тут был описан (без синтаксической структуры) при сбое скорее всего закончится весьма печально.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, GlebZ, Вы писали:
GZ>>Потому что у XML есть спецификация, даже две. У него есть предок в виде SGML. Потому что текстуальность ее обусловлена не только тем что удобно просматривать, но и тем что она проходит через все виды сетей. Поэтому, отказываясь от текстуальности (какой-то дурной термин), вы не только перечеркиваете его историю, но и его свойство кроссплатформенности. Бинарный формат более эффективен не в виде XML.
Д>Давайте все-таки отделим мух от котлет. Одно дело — кроссплатформенность, другое дело — передача через сеть. Д>1. Кроссплатформенность и текстовое представление совершенно ортогональны. Никто не мешает сделать кросс-платформенный бинарный формат в виде потока байт, а на каждой конкретной платформе приводить каждый тип данных в принятому на данной платформе типу. (так и слышу, что кто-нибудь начинает кричать "а какая же разница по сравнению с текстом, если все равно нужно преобразовывать данные?". Ответ прост — разница в эффективности)
Ну и откажись от xml в пользу других более быстрых стандартов благо такие есть. Кстати, что в данном случае подразумевается под эффективностью, быстрая работа или удобство использования? Д>2. Любые сети прекрасно передают бинарные данные — собственно, на этом они и построены :-D Другой вопрос, что некоторые клиенты имеют доступ только через HTTP прокси. Специально для таких случаев документ можно перекодировать с помощью base64, к примеру — и никаких проблем не будет.
Абсолютно верно, только тогда смысл и эффективность бинарного формата теряется. BIM, насколько я понял, так делает, но только по требованию.
A Base64 предназначен для того, чтобы через xml можно было провести бинарные данные в виде текста, но не наоборот.
Простой XML нетипизирован и тогда то что вы называете бинарного формата теряется.
GZ>>Существуют форматы кодирования XML в бинарный вид, но не работа с XML в бинарном виде.
Д>не думаю... нет никаких принципиальных проблем, чтобы создать парсер для бинарного XML, который будет полностью имитировать обычный текстовый XML на уровне интерфейса парсера
Только будет ли этом стандартом XML?
Стандарт xml все таки имеет спецификацию: XML 1.0 XML 1.1
The design goals for XML are:
XML shall be straightforwardly usable over the Internet.
XML shall support a wide variety of applications.
XML shall be compatible with SGML.
It shall be easy to write programs which process XML documents.
The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
XML documents should be human-legible and reasonably clear.
The XML design should be prepared quickly.
The design of XML shall be formal and concise.
XML documents shall be easy to create.
Terseness in XML markup is of minimal importance.
Здравствуйте, GlebZ, Вы писали:
GZ>Абсолютно верно, только тогда смысл и эффективность бинарного формата теряется. BIM, насколько я понял, так делает, но только по требованию.
ну не совсем так. эффективность парсинга все равно останется, так что даже в этом случае он будет намного быстрее текстового представления XML
GZ>A Base64 предназначен для того, чтобы через xml можно было провести бинарные данные в виде текста, но не наоборот. GZ>Простой XML нетипизирован и тогда то что вы называете бинарного формата теряется.
GZ>Только будет ли этом стандартом XML?
Здравствуйте, GlebZ, Вы писали:
GZ>Ну и откажись от xml в пользу других более быстрых стандартов благо такие есть. Кстати, что в данном случае подразумевается под эффективностью, быстрая работа или удобство использования?
Быстрая работа... хотя и по удобству использования разница не должна быть очень велика
Похоже, что из этих "велосипедов" ASN.1 лучше всего проработан. Надо будет подумать в этом направлении
Здравствуйте, AndrewVK, Вы писали:
AVK>Проблема не в том что парсер не сможет разобрать документ, проблема в том что столь примитивный бинарный формат, что тут был описан (без синтаксической структуры) при сбое скорее всего закончится весьма печально.
это верно. но если добавить к нему сигнатуры для разделов, то эта проблема решится без особых затрат
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
AVK>>>Что то же самое? Я тебе на пальцах показал что требование указывать размер тега приводит к заднице при передаче по сети. GZ>>Абсолютно также, если потерялся в заключительном теге символ '/', эффект абсолютно тот же.
AVK>Неа. В XML это будет ошибка синтаксиса, а вот в твоем случае ты просто какое то время будет парсить неверным образом. Если ты попытаешься ввести какие то синтаксические правила контроля структуры бианрника (теги, метки, сигнатуры), то получишь в итоге тот же XML, только в нечитаемом, но быстро отпарсиваемом виде.
Ты видел протоколы без синтаксической правил?
Первое, бинарник без типизации, является тем же текстом — следовательно, каким-то параметром тега является тип — следовательно, при получении неправильного типа должна выводится ошибка. Второе, если мы делаем аналог xml — то каждое значение имеет имя, которое обязано выделяться из общего потока по каким-то правилам. То есть последовательность: "Имя"-"Тип"-"Размер"-"Данные" (для справки, я не описываю ASN). Следовательно, есть некоторые правила определяющие правильность контроля полученных данных.
И еще, допустим к нам приходит XML в 3 пакетах:
Пакет1:
<root>
<obj>adfasdfsadfsadf</obj>
<obj>adfa
Пакет 2 потерялся. С точки зрения синтаксиса xml, все нормально. Пришедшие данные неполны и неверны. Для вышеописанного метода — это выдаст синтаксическую ошибку.
Опять же повторюсь и кто-то уже писал: Контроль правильности доставки сообщения по сети лежит на более низком уровне. Мы обсуждаем то чего не должно быть в принципе.
Здравствуйте, Дарней, Вы писали: Д>А XML BD — это было бы очень полезной надстройкой над Binary-XML
XML BD будет по сути реляционной БД. Операции: получить родительский тег (родительскую запись), дочерние теги (дочерние записи), атрибуты (поля записи).
Здравствуйте, Дарней, Вы писали:
GZ>>Только будет ли этом стандартом XML?
Д>с точки зрения программиста — будет
Да в том-то и дело, что не будет.
Цели XML которые затрагиваются в этом случае, напрямую:
XML documents should be human-legible and reasonably clear.
XML documents shall be easy to create.
XML shall be compatible with SGML. — хотя это в принципе можно опустить.
Самая интересная строка по данное тематике:
Terseness in XML markup is of minimal importance.
Мне показалось, что вы обсуждаете инструменты для работы с xml. Но у них есть свои спецификации которые просто связанны с данной. Как вы представляете себе XDR описыватывающий некоторый бинарный xml уже имеющий типы данных.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, GlebZ, Вы писали:
GZ>>Ну и откажись от xml в пользу других более быстрых стандартов благо такие есть. Кстати, что в данном случае подразумевается под эффективностью, быстрая работа или удобство использования?
Д>Быстрая работа... хотя и по удобству использования разница не должна быть очень велика Д>Похоже, что из этих "велосипедов" ASN.1 лучше всего проработан. Надо будет подумать в этом направлении
Скорее всего да. Однако не следует от него ждать возможностей XPath. Я по крайней мере, таких инструментов не видел. Не знаю, возможно в X.684 что то есть, но времени нет подробно посмотреть.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, GlebZ, Вы писали:
GZ>>ITU/X.694 xml основаный на ASN. Почитать, что это такое не удалось, но видимо действительно что-то интересное.
Д>http://www.itu.int/ITU-T/studygroups/com17/languages/
У меня там ссылка живая, просто времени не было посмотреть. Но все равно, спасибо.
Здравствуйте, Павел Кузнецов, Вы писали:
>> С какй целью?
ПК>В цитате было. Чтобы и глазами смотреть
Куда же смотреть в бинарном стандарте?
ПК>/руками редактировать можно было (удобство),
Бинарный стандарт руками? Забавно...
ПК> и чтобы при зачитывании каждый раз не грузился целиком и не парсился текстовый XML (скорость).
Боюсь тебя огрочить, но если это универсальный стандарт, то парсить его все же прийдется. И скорость с текстовым будет не вилика. Так что из приемуществ будет только компактность и отсутствие необходимости кодировать бинарные данные в текст.
ПК> Это, конечно, не все use cases покрывает, но описанный в процитированном сообщении — легко.
Стадется мне, что выигрыш от бинарности будет компенсироваться универсальностью стандарта. Это приведет к тому что общий выигрыш будет не велик. В виндвс давно есть стандарт компонентного бинарного хранилища. Компактность он не достиг. Погляди на файлы ворда и ёкселя. Аналогичный ХТМЛ занимает куда меньше места.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>ну почему же... это будет давать все возможности существующего XML,
Основное достоинство ХМЛ — это то-что это плэйн-текст доступный для чтения и изменения непосредственно человеком. Именно это достоинство пропадет в бинаром формате.
Универсальнос бинарного формата приведет к его неэффективности в сравнение с специализированными форматами. В итоге получится еще один IStorage с теми же проблемами.
Д> без необходимости менять использующий код — при этом получив немаленькое увлеичение скорости.
Маленькое. А при сравнение со специализированным форматом, так и проигрыш.
Д> Собственно, большинство из описанных в документе либ идут именно по этому пути, насколько можно судить по описанию. Д>А XML BD — это было бы очень полезной надстройкой над Binary-XML
Нафиг не нужен никакой Binary-XML для создания XML DB. Более того сами концепции БД напроч отвергают подобные форматы. В БД хранение поихводится не стримами, а структурированно. Именно это и позволяет достичь нужной производительности выборок и гранулярности обновления.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>В цитате было. Чтобы и глазами смотреть > > Куда же смотреть в бинарном стандарте?
Не в бинарном, а в текстовом. В бинарном только кешируются результаты разбора текстового XML.
> ПК>/руками редактировать можно было (удобство), > > Бинарный стандарт руками? Забавно...
Текстовый.
> ПК> и чтобы при зачитывании каждый раз не грузился целиком и не парсился текстовый XML (скорость). > > Боюсь тебя огрочить, но если это универсальный стандарт, то парсить его все же прийдется. И скорость с текстовым будет не вилика.
Смотря как сделать.
> Стадется мне, что выигрыш от бинарности будет компенсироваться универсальностью стандарта.
Никто не говорил, что бинарный формат должен быть универсальным или соответствовать какому-либо стандарту.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Основное достоинство ХМЛ — это то-что это плэйн-текст доступный для чтения и изменения непосредственно человеком. Именно это достоинство пропадет в бинаром формате.
Возможно, для кого-то это действительно важно и нужно. Для меня, например — нет.
VD>Универсальнос бинарного формата приведет к его неэффективности в сравнение с специализированными форматами. В итоге получится еще один IStorage с теми же проблемами.
IStorage — это совсем отдельная песня. Одна из особенностей этого формата — при изменениях происходит не полная перезапись документа (как в XML, например) — а только измененной его части. Фактически, внутри него находится нечто вроде мини-файловой системы с кластерами, таблицей размещения элементов и т.п. Вот только реализовано это препохабно, отсюда и все "достоинства" этого формата — как то большой размер, маленькая скорость работы, фрагментация и разбухание файла при частых изменениях, и т.п.
VD>Маленькое. А при сравнение со специализированным форматом, так и проигрыш.
если верить тестам того же BinXML, то разница минимум на порядок. По мне — этого уже вполне достаточно
VD>Нафиг не нужен никакой Binary-XML для создания XML DB. Более того сами концепции БД напроч отвергают подобные форматы. В БД хранение поихводится не стримами, а структурированно. Именно это и позволяет достичь нужной производительности выборок и гранулярности обновления.
Насколько я слышал, в существующих реализациях XML BD используется некоторое бинарное представление (точнее, бинарный индекс) для выборок по документам. Без этого время работы выборок было бы совсем уж печальным К сожалению, ссылку на источник сейчас дать не могу — не помню точно, где я про это читал.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Не в бинарном, а в текстовом. В бинарном только кешируются результаты разбора текстового XML.
Тут предлагается в том числе и чисто бинарный стандарт. Так что ответ не принимается.
ПК>Текстовый.
Тогда о чем речь в этой теме?
>> Боюсь тебя огрочить, но если это универсальный стандарт, то парсить его все же прийдется. И скорость с текстовым будет не вилика.
ПК>Смотря как сделать.
Как не делай. Парсинга не избежать.
>> Стадется мне, что выигрыш от бинарности будет компенсироваться универсальностью стандарта.
ПК>Никто не говорил, что бинарный формат должен быть универсальным или соответствовать какому-либо стандарту.
По-моему, тут только об этом и говорят. А иначе разговор лешается смысла и переходит к стадии серокоников.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Дарней, Вы писали:
Д>если верить тестам того же BinXML, то разница минимум на порядок. По мне — этого уже вполне достаточно
Это если верить. Я лично не врею. Я сам писал бинарные сериализаторы и сканеры к ним, и сравнивал с аналогичными текстовыми. Так вот огромной разницы в скорости небыло. Максимум разы. Так что порядки — это уже точно нечесный тест.
Д>Насколько я слышал, в существующих реализациях XML BD используется некоторое бинарное представление (точнее, бинарный индекс) для выборок по документам. Без этого время работы выборок было бы совсем уж печальным К сожалению, ссылку на источник сейчас дать не могу — не помню точно, где я про это читал.
XML DB имеют специализированную систему хранения данных. К бинартому формату это отношения не имеет. Это подобные форматы попросту приватны. Как и в обычных БД там куча системной информации и разных вивертов. Так что это совсем разные вещи.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК>Не в бинарном, а в текстовом. В бинарном только кешируются результаты разбора текстового XML.
> Тут предлагается в том числе и чисто бинарный стандарт. Так что ответ не принимается.
решения проблемы быстродействия — а именно кеширование некоторого бинарного представления. Если оно кому-нибудь надо — пусть используют. Нет — ну и ладненько.
Posted via RSDN NNTP Server 1.9 delta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
VD>Это если верить. Я лично не врею. Я сам писал бинарные сериализаторы и сканеры к ним, и сравнивал с аналогичными текстовыми. Так вот огромной разницы в скорости небыло. Максимум разы. Так что порядки — это уже точно нечесный тест.
надо будет попроверять самому. когда руки до этого дойдут.
Здравствуйте, VladD2, Вы писали: VD>Боюсь тебя огрочить, но если это универсальный стандарт, то парсить его все же прийдется. VD>... VD>Стадется мне, что выигрыш от бинарности будет компенсироваться универсальностью стандарта.
Интересно, чем отличается универсальный стнадарт от специализированного. Можно ли дать какое-то чёткое определение? Он действительно совсем универсальный? А Вселенную в нём закодировать можно ?
Если серьёзно, действительно ли нужны универсальные форматы данных, к которым XML и принадлежит?
Здравствуйте, J.J.OK, Вы писали:
JJO>все бесплатное было "ниже плинтуса" да еще с неудобными лицензиями JJO>Возможно сейчас ситуация изменилась в лучшую сторону ...
This ASN.1 compiler turns the formal ASN.1 specifications into the C code. The compiler is shipped together with conformant BER/DER/CER/XER codecs, with more codecs to follow. X.509 decoding example is shipped as well.
) стандартизировано и все ( почти 
