<div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">Статья</div></div><div class="sp-body"><div class="sp-content">Доказательство неполноценности XML
Никаких эмоций, только факты.
Доказать неполноценность XML так же просто, как доказать несоответствие структуры базы данных нормальным формам. Нужно лишь использовать строгие, хорошо описанные критерии. Нижеприведенные доказательства означают, что этот язык не должен использоваться для промышленного программирования. Он совершенно не соответствует стандартам современного научного знания и практики. Единственным оправданием его применения является необходимость сохранения совместимости.
После того, как вы осознаете всю неполноценность XML, вы, с большой вероятностью, испытаете бурю эмоций и, возможно, мир ваш программирования перевернется. Не забудьте пристегнуть ремень. Я начинаю.
Доказательство 0. Вводное. XML - язык данных
На основе этого доказательства базируются все остальные, и оно очевидно.
Если ошибочно понять название XML (Extensible Markup Language - Расширяемый Язык Разметки), то может показаться, что этот язык как-то связан с графикой или с графическим отображение данных. Но, как говорит Wikipedia: "XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами". В английской Wikipedia: "It is a textual data format". В XML нет никаких управляющих инструкций, которые могли бы определять, как будут отображаться данные. Соответственно, XML – это язык или, даже, формат данных (и по определению и по возможностям). Хочу отметить, что говорит родитель XML, организация W3C: "Originally designed to meet the challenges of large-scale electronic publishing." Значит XML это еще и формат позволяющий решить проблемы больших объемов обработки информации.
Д1. Избыточность форм представления
В XML есть возможность одни и те же данные хранить как в атрибутах элемента, так и во вложенных элементах.
<a href="webplace.com">
..
<a>
<href>webplace.com</href>
</a>
С точки зрения хранения и обработки эти формы абсолютно одинаковы. Зачем вводить разные структуры данных (вложенный элемент и атрибут) если они значат одно и то же? Для красоты? Чтобы один программист мог посчитать один вариант красивым, а другой – другой? Это же замедляет процесс принятия решений при разработке и увеличивает сложность парсеров. Представьте, что в языке Java два примитивных типа данных: int и num означающих одно и то же.
В XML, использование атрибутов является лишь способом оформления данных. XML не может претендовать на звание завершенного язык хранения данных, если в нем остались такие атавизмы. Это – явная избыточность.
Д2. Наличие неименованных полей
В XML вполне возможно написать такой код:
<root>
<a>aaa</a>
text1
<c>ccc</c>
text2
</root>
Элемент root является контейнером для 4х элементов. К первым из них можно обратиться по имени: a и c . Два других, содержащие text1 и text2 не имеют имен. Представьте теперь объект на С++ или поле в базе данных, которое не имеет имени. Адресация только по последовательному номеру. Это же нонсенс. Подобный подход в языках программирования остался далеко позади. Он порождал огромное количество ошибок адресации. К тому же, если удаляется элемент <c>, то text1 и text2 сливаются вообще в один элемент. Как их тогда по отдельности прочитать? Делать дополнительный парсер? Зачем вообще в контейнерах сделана возможность иметь свои данные?
Если сделать аналогичный механизм в реляционной базе данных, то, например, таблица TOOLS могла бы иметь не только строки соответствующие разным инструментам, но и какой-то текст, хранящийся по идентификатору TOOLS. Даже если хранить в этом тексте описание таблицы, то на практике принято делать отдельное именованное поле, например, TOOLS.description (хранят его обычно в отдельной таблице). Неименованные поля – это ужасный механизм для хранения данных. В паттернах программирования нужно поместить его под рубрикой "никогда не делайте так". Большинство программистов на практике и не используют эту возможность. В тэге-контейнере обычно хранятся только другие тэги, т.е. это выглядит так:
<root>
<a>aaa</a>
<text>text1</text>
<c>ccc</c>
<text>text2</text>
</root>
Д3. Нет автоматических средств упаковки данных
W3C провозгласила XML, как средство способное справиться растущим потоком электронных данных. Но расточительность этого формата колоссальна.
В Java откомпилированный код пакуется в jar файлы. Jar файл – это, фактически, zip архив. Простая и эффективная идея. Но она позволяет значительно сэкономить дисковое пространство и трафик, т.е. много денег. Java – это, всего лишь, исполняемый код. Его, обычно, гораздо меньше чем данных. Почему в XML нет хотя бы такого же простого механизма? Как при этом XML может "заменить существующие файлы баз данных"? Я не думаю, что у XML есть хоть какие-то шансы на замещение реальных баз данных. Они бы занимали на порядок (десятичный) больше места, что в загруженных бизнес системах не реально.
Д4.Избыточность закрывающих тэгов
Избыточность XML проявляется в том, что в конце области действия каждой конструкции пишется ее полное имя. Представьте в другом языке, например, языке программирования нечто подобное:
private void open(String uri) {
//function body
..
} private void open(String uri)
Или представьте подобные выражения в математике:
<sin> angle/180*PI <sin>
или
sin(angle/180*PI)sin
Существует проблема сопоставления открывающих и закрывающих скобок (конструкций), но о ней в следующем пункте. А пока, констатируем, что избыточные закрывающие тэги созданы только для удобства чтения человеком, а не для хранения данных. В случае с XML получается, что данные не отделены от их представления (один из страшных грехов программирования).
Д5.Трудносопоставимые открывающие и закрывающие тэги
Вообще-то, этой темы в формате хранения данных вообще быть не должно. Для машины такой проблемы не существует. Ей все равно из скольких символов состоит закрывающий тэг. Но если в XML брались решать эту задачу, то могли бы найти решение получше. Вот мой вариант решения проблемы с помощью автоматических индексов:
1 <root>
1.1 <record>
1.1.1 <field>
value
1.1.1 </field>
1.1 </record>
1.2 <record>
1.2.1 <field>
value
1.2.1 </field>
1.2 </record>
1 </root>
Возле каждого открывающего и закрывающего тэга стоит уникальный индекс. Так что найти закрывающий тэг можно по индексу и через несколько экранов. Подобная проблема есть и в других языках. Иногда программисты решают ее вот так:
for (int i = 0; i < args.length; i++) {
..
} //END of for
Предлагаемое мною решение чем-то похоже на такие комментарии. Можно дополнительно сократить закрывающие тэги. Сейчас я уберу смещение вложенных символов, чтобы посмотреть, насколько падает читаемость в самом худшем варианте:
1 <root>
1.1 <record>
1.1.1 <field>
value
1.1.1 </field>
1.1 </record>
1.2 <record>
1.2.1 <field>
value
1.2.1 </field>
1.2 </record>
1 </root>
По-моему, разобраться очень легко. Индексы должны автоматически добавляться редактором при просмотре документа. Хранить их в файле нет смысла. Я думаю, что, если бы создатели XML всерьез задумались над проблемой, они могли бы придумать еще несколько вариантов улучшающих чтение документов. Но, повторю, эта тема уже выходит за рамки вопроса хранения данных и входит в область графического представления, понятного человеку.
Хочу добавить, что в современных базах данных проблемы сопоставления границ разных полей не существует в принципе. Все дело в выборе правильных инструментов.
Д6. Отсутствие средств произвольного доступа
Обработка XML файла похожа на работу с магнитной лентой. Вы последовательно читаете ее с начала и если нужная вам информация находиться в конце, то читать приходиться до самого конца. Нет средств индексной адресации и произвольный доступ к данным не возможен. Подобная бедность формата данных, который позиционируется, как инструмент работы с большими объемами данных, удивляет. В любой системе хранения данных механизм использования индексов подразумевается априори. На магнитные ленты с последовательным доступом делают только бэкапы. Но делать бэкапы из XML, который не имеет встроенных средств архивирования (тем более шифрования и восстановления поврежденных данных) никому не придет в голову. Поэтому, заменить собой "существующие файлы баз данных" XML никак не может.
Основные доказательства неполноценности XML закончились. Есть еще пара дополнительных.
Д7. доп. Отсутствие типизации
В самом XML и DTD нет типизации значений. Типизация появилась только в XML Schemas. Боюсь, что мало кто ее, поэтому, использует. Информационные системы заполнены "мега тоннами" нетипизированных xml файлов. Напротив же, данные хранящиеся в базах данных, сильно типизированы. Соответственно, внедрение XML чаще порождает не упорядочивание, а беспорядок.
Д8. доп. Отсутствие code convention
Для разных языков программирования создаются code convention или нотации. Эти документы определяют типовое форматирования исходного кода и заметно повышают его читаемость. Если XML – это язык, на котором вручную должны писать программисты, то необходимо code convention. Если это формат данных не предназначенный редактирования вручную, то может нужен эталонный редактор или просмотрщик (этакий reference design)?
Вывод:
XML не является однозначным не избыточным языком для хранения данных. Обработка и хранение данных в XML не оправданны и уступают по большинству параметров всем распространенным реляционным БД. XML может быть использован лишь как средство обучения программированию. Хорошо оформленные (имеется ввиду визуальное форматирование) xml файлы способны наглядно представлять простые структуры данных.
В силу того, что XML получил большое распространение, выглядит целесообразным создание утилит для импорта и экспорта данных из/в XML. Но для ежедневного хранения и обработки данных XML не подходит. Заменить его можно любой из известных баз данных. Хорошо зарекомендовавшая себя связка HTML+CSS+PHP(Java)+SQL с легкостью заменяет такие расширения XML как XSL, Namespaces, XLink, XPath, XML Schemas, XML Data Types. При этом скорость ее работы и эффективность использования дискового пространства на порядок выше. Скорее всего, трудозатраты на ее разработку тоже окажутся значительно ниже.
Стоимость создания замены XML
Формат, подобный XML, любой лаборант кафедры вычислительной техники может придумать за день (вместе с написанием парсера). Учитывая все возможные и не возможные автоматические тесты – за неделю. Для создания удобного редактора может потребоваться еще до месяц работы квалифицированного программиста. При этом, есть возможность учесть требования, специфичные для вашего применения, например, эффективность использования дискового пространства или трафика, скорость обработки, удобство редактирования человеком, автоматический контроль ошибок. Так как XML уже стал общепринятым форматом, ваш "доморощенный" формат получает легкую возможность за счет XML тоже стать совместимым. Для этого необходимо написать утилиту импорта-экспорта в XML (1-2 дня работы). Приведенные прогнозы по затратам рабочего времени верны только для форматов, таких же примитивных как XML. Если вы захотите, например, ввести контроль типа данных, то может потребоваться дополнительное время. Но в любом случае, "роскошь" создания собственного формата файлов данных может позволить себе любой программист, работающий хотя бы 5 лет, не говоря уже о целых фирмах.
P.S. XML – это не высокая технология и не сложное изобретение – это лишь стандарт. Некая примитивная и неудобная вещь стала стандартом. Можно ли сделать стандартом что-то более совершенное?
Грид. 02.01.10
При цитировании ссылка на extrapro.ru обязательна.
Имхо, бред, человека страдающего графоманством..
