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

Файловые системы и базы данных имеют свой формат хранения данных. Как правило это научно обоснованные (по скорости поиска, размеру) алгоритмы и форматы. Они так же далеки от XML как американская экономика от индийской.


Опять же. Возмем пример с базами данных. Если там происходит какая-то ошибка, то это не является проблемой сообщить о ней пользователю.

Не думал, что доведется подискутировать 




А кто у нас проводит сертификацию на работу с XML? Неужто IBM?  
И как сертифицированный специалист может не знать:

Что по стандарту

Или проблема в том, что кодировка не одна?  




1. Причем тут вообще СУБД или ФС? Речь шла о формате обмена данными между системами. Ты предлагаешь гонять между системами бинарные файлы БД или вообще образы диска? 
2. Как правило система делает еще какие нибудь действия помимо парсинга XML. И как правило эти действия и занимают большую часть времени, а затраты на парсинг XML малы. Я понимаю, что иногда скорость парсинга и размеры данных критичны, но так я и нигде не утверждал, что XML универсальный формат на все случаи жизни.





Опять же я и не говорил, про пользователя, я говорил про лог системы, туда пользователь как правило не заглядывает. Ты можешь без специальных инструментов прочесть redo log Oracle?




Я не утверждал, что XML универсальный формат и подходит на все случаи жизни. Но он хороший выбор в качестве формата обмена данными между системами (если нет особых требований по скорости и/или объему передаваемых данных). Причин тому несколько:
- есть куча готовых утилит по работе с ним (парсеры, валидаторы, XSLT процессоры и т.д.)
- легко читается и самодостаточен (в смысле взглянув на XML документ можно понять, что вообще в нем содержится, в отличии от бинарного формата)
- есть мощное средство валидации данных - XML Schema
- есть мощное средство трансформации данных - XSLT
- есть мощное средство запросов - XPath
Причем это все уже есть out of the box. Какой еще формат может похвастаться этим?

Главная фишка, в том, что они нифига не легко читается. Скролировать метровые простыни в Notepad и "парсить" глазами что к чему относиться - это утомительное занятие.

Формат MSWord или Excel файлов бинарный, но читаются они легко потому, что есть удобный редактор. И пользуется этими бинарными форматами миллиард юзеров. 

Для XML, конечно, тоже есть редакторы. Все удобство XML определяется редактором. (каша из топора: xml- топор, редактор - каша) Но задумывали то этот формат как нечто, что можно просматривать как текстовый файл (в обычном Notepad). Об этом весь сыр-бор и был. Если же брать для XML редактор, то для конечного пользователя (программера) вообще становиться все равно какой он внутри, этот формат. Так же, как для пользователся MS Word или Photoshop все равно, как представленны данные внутри doc или jpeg файла. Главное есть просмоторщики и редакторы. Если вы думаете, что это верно только для простых пользователей, то спросите как много прграммеров знает в каком формате MySQL хранит свои данные. Формат хранения знать нет надобности потому, что есть SQL. Движок базы обеспечивает быстрое чтение фала данных базы и нахождение в нем необходимых таблиц и строк.

Форматы создаются с целью оптимизировать обработку и хранение данных. GIF, например, это компрессированный формат с возможностью чересстрочной загрузки (т.е. расчет на использование в сети). Является ли gif межплатформенным? Конечно. Есть ли у программистов трудности с обработкой gif-оф? Нет, потому, что написанны библиотеки.

XML создан из HTML. А HTML - это всего лишь язык разметки для ламеров.
"HTML создавался как язык для обмена научной и технической документацией, пригодный для использования людьми, не являющимися специалистами в области вёрстки." Эти люди не умели работать в сложных программах (аля pagemaker или msword, которых к тому же тогда не было), но им были доступны редакторы вроде Notepad.
У кого могла родиться идея создать язык хранения данных из такого примитивного языка разметки? XML ведь хранит только данные, он не определяет правил как они должны быть обработанны или показанны. Полная абстракция данных. При этом, эта абстракция данных не предназначенна для обработки или компактного хранения. Как это может быть? Получается, что это лишь некое "красивое" форматированние данных для Notepad. Пропарсить такой фал и однозначно интерпретировать средствами программирования, конечно, можно. Но только разобранный и преобразованный, например, в Java в структуру объектов (из List, HashMap, String) XML действительно становиться данными, которые связанны, по которым можно осуществлять произвольный доступ, быстрый поиск и изменения.

На некоторых серверах парсинг и записть XML уже несколько лет назад стала самой прожорливой задачей. Поэтому и стали думать о создании формата binary xml.

Я понятно излагаю? 

1. Скролировать метровые простыни Word-а ничуть не легче. Если ты знаешь, что ты ищешь, то Ctrl+F тебе поможет и там и там, иначе и то и другое одинаково утомительно.
2. Как я уже неоднократно повторял, XML не предназначен для хранения больших массивов данных. В нормальной системе XML больше сотни килобайт, это редкость. К тому же как правило если данных и много, то структура у них повторяющаяся.
3. Ты не поверишь, но MS Word и Excel уже два года как имеют XML-ный формат документов  





2. Для удобной работы с XML от редактора требуется минимум: подсветка синтаксиса, Code folding, форматирование, XPath. И самое главное этого будет достаточно для любого XML. А вот такого же простого и универсального редактора для бинарных форматов не существует. Мне ничего не стоит записать в лог, послать по e-mail сообщение в формате XML, но вот для того же Hessian я это сделать не могу.
3. В XML есть XPath, который не уступает SQL.
4. Пользователю не важен формат хранения данных в MySQL пока все идет хорошо. Но стоит запороться хоть одной таблице, как сразу наступает череда утилит по восстановлению за много $$$$.





Как же так получилось, что сертифицированный специалист по работе с XML не знает что:

а не HTML?  





1. XML нет определяет правил обработки, а вот XSLT определяет. Плюс куча других спецификаций по обработке XML (DOM, SAX и т.д.). Так что с обработкой у XML все в порядке.
2. А с чего ты вообще взял, что компактность это самая главная цель разработки какого либо формата? Те же ini файлы, они далеко не компактны (особенно за счет комментариев), но они удобочитаемы и их легко править. Тот же Word далеко не компактный формат и содержит много лишней информации, но ничего все его пользуют и никого это не напрягает.
3. Ты в Java и GIF-ом не сможешь оперировать, без преобразования в java.awt.Image. А вот XML прочитать определенный тег можно и без полного парсинга XML.

Ладно, LSD, работай с xml.  

Твои аргументы не интересные.

Это сообщение отредактировал(а) Grid - 26.11.2009, 17:57

Новая статья по поводу XML.

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

Никаких эмоций, только факты.

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

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

Аффтар продолжает жечь напалмом. Ну что же, пройдемся без эмоций по этим "фактам" 


Д 1
Эти формы различны и с точки зрения хранения и с точки зрения обработки. Есть рекомендации когда использовать вложенные теги а когда атрибуты, но это только рекомендации никто никого не заставляет. Есть пара вещей которые можно реализовать только вложенными тегами, но их но они не особо существенны. В любом нормальном языке есть вещи которые можно реализовать разными способами, но это вовсе не делает их неполноценными.

Д 2
напишу попозже.


Д 3
А вот в JavaScript, Perl, PHP, C#, Python, Ruby тоже нет автоматических средств упаковки данных они тоже неполноценные? Или это правило распространяется только на XML?  


Д 4
В том же PL/SQL применяются такие же конструкции:

Помимо удобства для человека, подобные закрывающие теги еще значительно повышают устойчивость языка к случайным ошибкам.
Зато порадовал вывод о том, что данные не отделены от представления, который буквально материализовался из ниоткуда  


Д 5
Для того чтобы найти закрывающий элемент (скобку или тег) в современных редакторах придумана куча средств. И в целом сейчас уже мало кто парится по этому поводу.


Д 6
Во первых автор не понимает, что произвольность доступа предоставляется не форматом данных, а приложением/библиотекой (сервер СУБДб DOM). Просто есть форматы данных которые ориентированны на произвольный доступ (те же СУБД), а есть которые не ориентированы.
Во вторых есть тонны форматов хранения данных которые не ориентированы на произвольный доступ. Практически все документ-ориентированные форматы именно такие: всевозможные виды ini-файлов, офисные документы, графические форматы, форматы исполняемых файлов и т.д. И ничего как-то живем 


Д 7
Сейчас трудно найти формат основанный на XML для которого бы не было XML Schema - Office Open XML, OpenDocument Format, XMPP для всех них существуют XML Schema. Прежде чем делать подобные заявления неплохо бы поинтересоваться истинным положением дел.


Д 9
У XML есть code convention по части форматирования кода. Достаточно скачать 10 редакторов и заставить их отформатировать код, если что-то и будет отличаться так это величина отступа 



P.S. Основная проблема XML, это то что по каким-то неведомым причинам Grid решил, что это формат для организации СУБД  

Grid, в каких конкретно целях тебя не устраивает xml ?

Не сорьтесь, горячие финские парни   , уже придумали JSON  

Добавлено через 2 минуты и 20 секунд

зачем XML скроллировать  , он разве для чтения глазами?

есть еще yaml, но он не является альтернативой xml, он может заменить xml там, где нужна человеко-читаемость и человеко-редактируемость  

Добавлено через 57 секунд
ну там для конфигов всяких, к примеру
язык очень удобен для описания данных и в тоже время легко читается

 Ровно как и код.
А откройте XML браузером - сразу ситуация изменится.

 Именно! Как и абсолютно любой формат.
Возьмите "Войну и мир", откройте ее блокнотом и книжной читалкой - разница невообразимая.

 Перебор.
Формат все же должен читаться человеком. XML плохоЧИТАЕМЫй. Т.е. все же читаемый.

 Зато в них есть аргументация.

 +1, использую именно его.

  В этом то и фишка.

  Соглашусь с LSD для небольших файлов до 100-200 кб скорость еще допустима. Парсинг 200 кб на 200МГц проце занимает сотые доли секунды. 

  На счет того что для доступа элемента с конца требуется полный парсинг. Неверно. Можно производить первоначальный парсинг только до определенной глубины, а остальное делать на лету. В свое время мне нужно было написать парсер XML, для слабого железа. Так я за раз разбирал только теги, атрибуты разбирались по первому требованию. Поскольку каждый тег содержит мало атрибутов, то извлекаются они мгновенно, в тоже время затраты на извлечение всех атрибутов всех тегов увеличивают время в разы.
  Зато в любой момент человек не являющийся программистом может отредактировать данные. Проверить целостность структуры можно открыв любым браузером. 
  
   Один из серьезных недостатков, это невозможность хранения в себе бинарных данных. Например изображений. Дополнительное перекодирование в base64 во первых раздувает XML, во вторых делает невозможным его чтение человеком. Так что на бинарные данные приходиться ссылаться и хранить отдельно, что снижает удобство работы.

Если рассматривать JSON как язык для хранения/передачи данных, то кардинальных преимуществ перед XML, что-то не видно. Я предполагаю, что в основном данные генерируются/парсятся руками, но иногда бывает необходимость читать/писать их руками.
1. Не знаю ошибка это или нет, но этот код:

не сбалансирован по скобкам. Что само по себе сакс.

2. Если сравнить один тег JSON

и один тег XML:

То вся избыточность только в том, что закрывающий тег должен содержать то же имя что и открывающий. Зато имеем большую устойчивость к случайным изменениям (опечатки, ошибки при передаче и т.п.).

3. В JSON есть аналоги CDATA, XML Schema (или хотя бы DTD), XPath, XSLT?





Только не невозможность, а не оптимальность хранения бинарных данных.

LSD, такой функции попросту нет. Бинарные данные хранятся как текстовые. Т.е. для XML это уже текст не содержащий спец символов.