Центр информации по операционным системам: Новости / Комментарии / Как направить XML в скоростной ряд?

Технология Extensible Markup Language стала практически универсальным средством обмена информацией в онлайне. Но все чаще можно услышать признание, что за преимущества XML подчас приходится платить снижением производительности.

Roman I Khimov в Понедельник, 17 Январь 2005, 14:14 |

Комментарии: 6 |

Комментарии

Freeman |17.01.2005 20:29

Комментарии: 240

Зарегистрирован: 01.07.2004 14:57

Ну, вот, наконец-то. Сообщество разработчиков начинает приходить к тому, что лежало на поверхности с самого начала. XML слишком жирен - это факт.

Не далее, как сама Oracle придумала некоторый вариант двоичного представления XML, который используется в их СУБД, начиная с версии 9i Release 2.

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

vilmor |18.01.2005 10:02

Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

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

Действительно плохо то, что XML используют и для хранения данных. Сейчас порой можно встретить БД, в которой данные хранятся в XML, что естественно, приводит к крайне неэффективной работе программ.

Другая беда - небрежное проектирование прикладных сетевых протоколов, основанных на XML. Бывает, что они чрезмерно многословны избыточны (из моего личного опыта разработки).

Третий факт - это традиционный отказ от сжатия (gzip, deflate), которое можно использовать при передаче данных по HTTP.

Четвёртый - неэффективные XML-парсеры. Мне нравится libxml, но его способ работы с текстовыми строками меня поражает своей неэффективностью. Об MSXML ничего не могу сказать, поскольку не видел его сырцов.

Для меня представляется сомнительной выгода от использования бинарного XML в мобилных устройствах - это смена "жирности" XML на накладные расходы, потребующиеся для распаковки/сжатия данных и поддержки нескольких вариантов кодирования.

Freeman |18.01.2005 13:20

Комментарии: 240

Зарегистрирован: 01.07.2004 14:57

Не знаю, как MSXML и прочие, мне приходилось работать только с SAX. У него все основано на интерфейсах, и по большому счету все равно, как на нижнем уровне хранятся данные. Если будет реализация для двоичного варианта XML, программы придется в худшем случае перекомпилировать.

А насчет накладных расходов на распаковку и прочее - это уже как реализовать. Возможно, ты и прав - XML изначально не был рассчитан на объемы данных, которые пихаются в него сегодня. Но факт есть факт. Жаба тоже разрабатывалась для управления встроенными устройствами...

Кстати, насчет раздутости конкретных форматов данных, основанных на XML. Благодаря текстовому представлению мы воочию увидели, сколько лишней информации может храниться в двоичном формате... Взять тот же Windows-манифест.

Если же формат двоичного XML будет стандартизирован, ничего страшного не произойдет. Всегда будет возможность преобразовать его в текстовый. Не знаком с DFM-файлами в Дельфи/Билдере? Во время разработки чаще всего используется текстовое представление, чтобы иметь возможность править формы на нижнем уровне, если потребуется, а в выполнимом файле они уже в двоичном виде - эффективно и меньше места занимает.

Другой пример использования компилированного текстового представления HTML/CHM. Удобно. Правда, стандарт CHM не открытый, отсюда и ограничения. Но значение самой технологии это нисколько не умаляет.

vilmor |18.01.2005 14:16

Комментарии: 27

Зарегистрирован: 29.10.2004 17:09

>Возможно, ты и прав - XML изначально не был рассчитан на объемы данных, которые пихаются в него сегодня

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

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

По поводу chm. У него есть существенные недостатки - использование HTML и только однобайтовых кодировок.
Очень обидно, что для него нет альтернативы в Open Source. В принципе, нет ничего сложного в создании такого альтернативного формата - можно просто "поженить" DocBookXML, tar и bzip2 - вот вам и простой, компактный, открытый, платформонезависимый формат для технической документации

Freeman \|18.01.2005 16:33
Комментарии: 240 Зарегистрирован: 01.07.2004 14:57	Скажу я, почему нет альтернативы CHM в Open Source, но вам не понравится: юниксоиды зациклены на текстовом представлении информации

vilmor \|18.01.2005 17:37
Комментарии: 27 Зарегистрирован: 29.10.2004 17:09	тем не менее, в Linux Documentation Project (LDP) используют DocBook как внутренний формат, а результаты выкладывают как в HTML, так и в PDF...

Комментарии доступны только авторизованным пользователям, авторизуйтесь или зарегистрируйтесь на сайте здесь