КИТА unofficial

Один из создателей стнадарта XML, Тим Брей, написал заметку XML Is Too Hard For Programmers (http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog), а затем еще одну, менее пессиместичную Why XML Doesn't Suck (http://www.tbray.org/ongoing/When/200x/2003/03/24/XMLisOK). Обе заслуживают внимания.

Кроме того, существует еще один, весьма интересный документ (требуется регистрация): The Pros and Cons of XML (http://www.zapthink.com/report.html?id=ZT-XMLPROCON)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

Google предложил замену XML (http://lenta.ru/news/2008/07/08/google/)

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

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

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


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

* 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

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

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

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