Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, 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
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
