Здравствуйте, 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. Необходимость просматривать текст посимвольно, чтобы найти начало следующего узла
