XML: pro и contra

[LazarusLong]

Один из создателей стнадарта XML, Тим Брей, написал заметку XML Is Too Hard For Programmers, а затем еще одну, менее пессиместичную Why XML Doesn't Suck. Обе заслуживают внимания.

Кроме того, существует еще один, весьма интересный документ (требуется регистрация): The Pros and Cons of XML

Вроде все доводы за вполне разумны. Все красиво на бумаге - данные и метаданные хранятся вместе, interoperability, readability как для людей так и для машин, обобщенный стандарт для представления Unicode, хранить можно древовидные и плоские данные и прочая, прочая. А то что чересчур большие файлы - ничего страшного, можно юзать сжатие, например на транспортном уровне. Сложно парсить и выбирать данные? Ничего, есть библиотеки для любого языка программирования. Нет нормальных XML-редакторов? Не беда, появятся.

И все же, всякий раз работая с XML-файлами возникает какое-то интуитивное неприятие. "Блин, опять этот хренов XML!" - проносится мысль, когда появляется задача с исходными данными в этом формате. Кажется что-то очень, в корне не правильно. Ни у кого аналогичных мыслей не возникает?

[grimgav]

Ни у кого аналогичных мыслей не возникает?

Возникают и ой как часто. Особенно когда приходиться объяснять все плюсы XML программерам раньше с ним дела не имевшим. И опять же в процессе реализации той или иной функциональности, использующей XML, постоянно вылетают какие-то бока =/ В основном из-за не согласованности действий разработчиков сервверной и клиентской частей =)

[artri]

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

постоянно вылетают какие-то бока =/ В основном из-за не согласованности действий разработчиков сервверной и клиентской частей =)

Используйте dtd для валидации xml документов, будет Вам и согласованность действий

[EvilMax]

grimgav, надо схему сразу делать, всю, целиком на все случаи жизни и сценарии использования. Тога боков не будет. Все всё нормально сделают при минимальном взаимодействии. А не "давайте еще прорисуем протокол"... де-нить посередине разработки. Ну ты помнишь, где такое было )))

Сложно парсить и выбирать данные?

XPath форева. В особенности XPath 2.0

Нет нормальных XML-редакторов? Не беда, появятся.

Давно хватает - тот же XMLSpy. А несложные есть практически во всех нормальных IDE.

Используйте dtd

Это как минимум. Но DTD некторых вещей не учитывает. Так что в идеале, схема.

[LazarusLong]

XPath, XMLSpy

Да все это ясно. Просто примеры еще не так давно очень часто встречавшихся аргументов против.

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

А ведь XML ни в коем разе не является форматом хранения данных, хотя в последнее время частенько наблюдается тенденция к его использованию именно для этого. Изначально назначение XML - передача данных и interoperability. XML - является форматом write-once, то есть он не предназначен для того, чтобы записать на хард, а потом иногда вносить изменения. Его назначение в том, однажды вывести свои данные в формате XML, чтоб кто-то это прочел преобразовал в свой формат и всё! На этом жизнь XML-файла должна заканчиваться.

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

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

[EvilMax]

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

Мнэээ... Куда-то не туда сворачиваем. Мне кажется, что это не вопрос преимуществ/недостатков XML, а вопрос целевого применения технологий. А по поводу СУБД - посмотрим, во что выльется проект Xindice.

[LazarusLong]

Мнэээ... Куда-то не туда сворачиваем. Мне кажется, что это не вопрос преимуществ/недостатков XML, а вопрос целевого применения технологий. А по поводу СУБД - посмотрим, во что выльется проект Xindice.

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

[grimgav]

А не "давайте еще прорисуем протокол"... де-нить посередине разработки. Ну ты помнишь, где такое было )))

Да, да. Я именно о таких случаях =)

[EvilMax]

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

Ну, злоупотребляют всем. Наверное, нужно переименовать тему.

[grimgav]

А сейчас есть тенденция подменять БД статическими XML-файлами

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

И ещё интересно было бы узнать о "не профильном" применении XML, так сказать для расширения кругозора.

[LazarusLong]

Ну вот я не так давно наблюдал в одном проекте 10 гиг xml-файлов вместо БД.

И еще мне не очень нравится, когда конфиги из plain-text(особенно когда это простой, плоский файл без всяких там уровней вложенности) переделывают в xml.

Какой формат проще для чтения и редактирования (для человека)?

Код:

127.0.0.1     localhost locahost.mydomain.com
11.12.13.14   myhost    myhost.mydomain.com

Код: (xml)

<?xml version="1.0" encoding="ISO-8859-1"?>
<hosts>
  <host type="IPv4">
    <address>127.0.0.1</address>
    <aliases>
      <alias>localhost</alias>
      <alias>localhost.mydomain.com</alias>
    </aliases>
  </host>
  <host type="IPv4">
    <address>11.12.13.14</address>
    <aliases>
      <alias>myhost</alias>
      <alias>myhost.mydomain.com</alias>
    </aliases>
  </host>
</hosts>

Хотя дело привычки наверное.

Или вот, к примеру Sun заменила inetd систему сервисов на какое-то *** с кучей XML файлов и кучей допутилит. Это вместо 1-го файла и никаких утилит.

[zer_owlet]

вставлю и свои 5 коп... соглашусь с Лазарусом -- часто пихают xml куда только можно ибо это модно... ну на кой пихать его туда, где вполне подойдет строка параметров, разделенная каким-то символом...

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

да, когда список параметров плавающий, легче таки юзать xml... тут согласен...

ЗЫ: в принципе, "не профильное" использование вообще свойственно для всего нового...

[LazarusLong]

Google предложил замену XML

[naxellar]

Бред. Написано, что тот протокол не предназначен для чтения пользователем и еще выставляется это за плюс. XML специально такой, а не вынуждено.

[LazarusLong]

Бред не бред, но думаю гугл не зря его использует в своих проектах вместо ХМЛ,

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


Вот какие плюсы выделяет Гугл:

* are simpler
* are 3 to 10 times smaller
* are 20 to 100 times faster
* are less ambiguous
* generate data access classes that are easier to use programmatically

ни слова про читабельность.

С этим форматом я еще не знакомился - так пробежал пару статей по диагонали, но вообще выглядит так, что операции чтения записи будут менее дорогостоящими чем в случая с ХМЛ. Хотя это только первое впечатление.

[Sochin]

ггг. а к чему еще один протокол коли есть уже стандартный? ничего не напоминает? =)