1. Набираем команду codeby webinar. Набираем команду для организации и проведения вебинаров. Подробнее ...

    Скрыть объявление
  2. Требуются разработчики и тестеры для проекта codebyOS. Требования для участия в проекте: Знание принципов работы ОС на базе Linux; Знание Bash; Крайне желательное знание CPP, Python, Lua; Навыки системного администрирования. Подробнее ...

    Скрыть объявление
  3. Получи 30.000 рублей. Для получения денег необходимо принять участие в конкурсе авторов codeby. С условиями и призами можно ознакомиться на этой странице ...

    Внимание! Регистрация авторов на конкурс закрыта.

    Скрыть объявление

Доказательство неполноценности Xml

Тема в разделе "Остальные языки программирования", создана пользователем Grid, 3 янв 2010.

  1. Grid

    Grid Гость

    Репутация:
    0
    Новая статья на сайта codeby.net
    <div style="width:100%;padding:8px;background:#fcc3c3;border:1px solid #ff0000;color:#ff0000;">reklama

    Явная реклама убрана! Еще одна такая штука - забаню. Если хотите отзыв - цитируйте статью здесь(!), и указывайте источник.</div>
    Интересно было бы услышать комментарии.
     
  2. vital

    vital Больной Компом Детектед

    Репутация:
    0
    Регистрация:
    29 янв 2006
    Сообщения:
    2.432
    Симпатии:
    40
    Смотрим исправления в посте..
     
  3. vital

    vital Больной Компом Детектед

    Репутация:
    0
    Регистрация:
    29 янв 2006
    Сообщения:
    2.432
    Симпатии:
    40
    <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 обязательна.
    Имхо, бред, человека страдающего графоманством..
     
  4. vital

    vital Больной Компом Детектед

    Репутация:
    0
    Регистрация:
    29 янв 2006
    Сообщения:
    2.432
    Симпатии:
    40
    Ну я тоже не знаю=) Просто очевидно, что в статье бред.. То же мне недостаток - наличие закрывающих тегов.. омг..
     
  5. Grid

    Grid Гость

    Репутация:
    0
    Я так понимаю, что никаких значимых аргументов в защиту XML у вас нет ;)

    Свои оскорбления можете оставить при себе.
    Достаточно много человек уже поддержали мои выводы. Хотя, конечно, здравомыслящих всегда меньше чем "идущих строем".

    Если кто-то сомневается, то скажу, с xml я очень хорошо был знаком. Еще в 1998 разрабатывал для IBM библиотеки. Может уже-то что-то и забыл. Сейчас стараюсь по-реже использовать этот денатурат. Оказывается, что есть проекты, где xml с успехом не используют. :)
     
  6. Grid

    Grid Гость

    Репутация:
    0
    Вот вам еще одно доказательство неудобности XML.

    Нашел интересный формат JSON, который разработан для PHP и уже достаточно широко используется. Статья "PHP. Что такое JSON и как с ним бороться" JSON является прямым конкурентом xml. Он лишен многих недостатков XML и, главное, гораздо более подходит для эффективного программирования.


    Добавлено:
    Все наоборот. Пока нет никаких значимых аргументов за xml. И никогда не было. Кроме того, что этот стандарт был навязан как стандарт всем, других преимуществ не видно.
    Какие преимущества у xml и перед чем?

    Богатая исторыя ХэМэЭля началась с перепеси на селения в СШАтах у 1960 годзе. Бюрократам надо было как-то скомпоновать текст на карточках. Вот с тех пор всякие странные идеи и бороздят просторы голубой планеты обогощая ее чернозем. Это то и понятное дело, чернозем как-то надо размечать на десятины и вы-сотки. Для этого и созданы языки разметки с богатейшей, позвольте сказать, простите, написать, историей.
     
  7. Grid

    Grid Гость

    Репутация:
    0
    Во всех языках им можно пользоваться. Статья, про то, как использовать его в PHP. Изначально сделан для JavaScript. Сейчас ядро PHP поддерживает функции json_encode() и json_decode().

    Дело не в происхождении JSON а в его преимуществах.
    Вот статейка "JSON: Альтернатива XML без лишнего жира" Название статьи даже символичное.
    JSON: The Fat-Free Alternative to XML

    Никто на этом форумен не смог мне привести аргументы в защиту XML. Ну раз у меня такие уж дистрофичные оппоненты, найду сам. Например из статьи "JSON: The Fat-Free Alternative to XML"

    В переводе на русский это значит
    XML предлагает два гигантских преимущества, как язык представления данных:
    1. Он основан на тексте
    2. Он не зависит от позиции


    Да уж, преимущества гиганские однозначно.
    1. Теперь данные можно редактировать в Notepad. Наверное это очень важно чтобы офисные служащие могли создавать данные не через специальные программы или стандартные редакторы баз данных, а в Notepad или FAR. "Гигантский шаг" вперед к примитивному универсализму. Да и универсализм этот, кстати, неполноценный.
    2. До XML было множество языков, в которых смысл не зависит от позиции. Возмем любой язык программирования. Задан
    набор делимитеров с помощью которых определяются все границы. Но в XML делимитеры ужасны до безобразия.
     

Поделиться этой страницей