Я, автор, нашел тут ваши выпады в мой адрес.  Я сертифицированный специалист по работе с 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 это уже текст не содержащий спец символов. 

В JSON есть javascript, который умеет явно не меньше) Плюс либы типа jquery, которые содержат и XPath в том числе

Это типа выполнить произвольный код пришедший неизвестно от кого? 

Добавлено через 2 минуты и 13 секунд
И кстати, что мне проку от этого JavaScript, если у меня система скажем на Java, C#, C++, Delphi? Как мне проверить валидность пришедших данных, выбрать определенные данные?

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

Какой функции?



Ну так хранятся же 

 Эм, я что-то не понимаю? JSON - всего лишь формат хранения типизированных данных с синтаксисом JS.

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

С базами данных, кончено это сравнивать нельзя, они это совсем другое. Другие скорости, другие алгоритмы и назначение. В целом же xml можно использовать как базы, но там уже не совсем xml получается, а скорее база, которая симулирует xml, и основная идея мне думается при этом теряется.

Хорошая статья? 
Ты не выспался?

А чем тебе статья не нравится, вполне описывает конструктивные недостатки. Взять хотя бы Д1, автор спрашивает в чём отличие. Отличие в том, что атрибут всегда будет лексемой, напротив то, что находится в тегах может быть древовидной структурой данных.

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

Но тут согласен, не согласен, а почитать полезно.

Пункт "Д3. Нет автоматических средств упаковки данных". xml.gz. Оба стандартизированы, второй является потокком и может быть распакован на лету без изменения кода(при должном уровне абстракции системы).
На практике пакуют в ZIP(на примере FB2 XML-формата).

Ну в пункте "Д5.Трудносопоставимые открывающие и закрывающие тэги" автора статьи уже конкретно начало глючить(до его изменений код был читаемым из-за отступов, которые он убрал). + не стоит забывать фолдинг и переформатирование в любом вменяемом редакторе.
При этом автор противоречит своему же пункту 4, с которым я согласен.

И далее его понесло: "Д6. Отсутствие средств произвольного доступа" Формат не предназначается для такого. И нет вменяемых методов это сделать без ухудшения остальных параметров.
При этом есть элементарные обходные пути, которые и используют, например в моей любимой читалке ShortBook(чтение XML-формата(FB2) книг): внешние индексы. Они не являются частью XML, а лежат отдельно.

В "Д7. доп. Отсутствие типизации" Он говорит, что она есть, но многие люди ее не юзают, потому что она не нужна.
Теперь вопрос: "Логика, ау?"

"Д8. доп. Отсутствие code convention" Выглядит совсем странным: оно есть де-факто: отступы и именование тегов у всех одинаковы(насколько я видел). Иногда отступы убирают(для уменьшения размера), но они легко восстанавливаются редакторами.

Посмотрим на JSON: оставшиеся проблемы 1,2,4(с ними согласен) решены.

Представьте, что, по аналогии с xml, в таблицах реляционных баз данных есть не только поля, но и атрибуту.  Т.е. каждая строчка хранит не только значения полей, но и значения атрибутов.
Junior: Что-то я не пойму, чем отличаются поля от атрибутов?
Senior: Ну это разные виды данных.
Junior: Почему разные? Ведь и в полях и атрибутах можно хранить одни и те же типы данных.
Senior: Да я говорю, что разные. На экране они немного по-разному отображаются.
Junior: Блин, так ведь по сути это ничего не меняет. Получается, что поля от атрибутов отличаются только визуальным представлением на экране. В SQL таблицах такого не должно быть. Ведь это модель для хранения данных.


Ну, сравнил. Если бы они претендовали на форматы хранения данных, то это для них это тоже стало бы неполноценностью. Из википедии " XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных) "



Могу только сказать, что PL/SQL тоже имеет весьма неудобный синтаксис. Хорошо, что этого языка нигде за пределами Oracle нет. 



Парень, ты не передергивай. Такой тезис выдвинул я. Ты что тоже хочешь доказать  бессмысленность закрывающих тегов в XML? Если есть нормальный редактор, то эти "достижения" xml не имеют значения.


Ну, так я и говорю, что xml не ориентирован на произвольный доступ. А формату, без такого доступа претендовать на задачу хранения и обработки больших объемов данных – глупо.  W3C для больших объемов его и позиционировало. (цитата " designed to meet the challenges of large-scale electronic publishing ")
…
Так "как-то" и дальше жить будем. 
Да, property файлы писать на много удобнее чем xml.


Для официальных форматов вроде Office Open XML схемы конечно создаются. Но реальное положение дел состоит в том, что разработчики схемы не делают. Я участвовал в проектах, где хватало любителей xml. XMLы они пишут в огромных количествах. А схемы, тем более с типами, – нет.  Если можно не писать, то писать не будут. Попробуйте вы в какой-нибудь реляционной базе не указать тип данных или в языке программирования. Скриптовые язык рассматривать не надо, так как они тоже являются плодородной почвой для багов. 


Да, одной из  целей создания xml было то, что его можно читать в простом текстовом редакторе вроде Notepad. У людей была уверенность, что это повысить кроссплатформенность.


Ну, браузером я могу и gif и flash открыть. В HTML5 даже видео. Конечно, они там отлично выглядят.  Но если формат предназначался для редактирования Notepad, то выглядеть он должен прилично, например так, как исходник на языке C или Java.


Ну вот из-за этого желания и весь гемор пошел. Лично мне не нужен формат хранения больших объемов данных, который должен читаться. Я пользуюсь Oracle, Postgre, MySQL, Firebird, DB2, MS SQL. У всех у них разные форматы и все не читаются человеком. Но для хранения данных мне другое важно. Если же писать конфигурационные фалы, так лучше уж я использую property формат. XML для конфигурационных файлов тоже не подходит так как синтаксис бюрократичный.


Ну конечно, можно оптимизировать убогости xml. Но уже давно есть СУБД, которые проектировались без недостатков xml. Я не знаю, какие у вас были задачи в проекте. Может вам СУБД не подходили. Но явно, что для любой из задач можно подобрать что-то более подходяще чем xml. XML – "не два и не полтора", каша из топора (все сделай сам и еще придумай как убогости обойти) .

JSON – формат гораздо более реальный. Отвечает реальным требованиям.

nerezus, ты описываешь как можно обойти недостатки xml. В самом xml этого нет.

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


Логика привет! На практике это язык приводит к нетипизированным данным, чего никогда не случается с добрыми старыми СУБД. А это можно назвать деградацией данных.


Странным? Какова максимальная длинна строки в xml? Если этот формат предназначен для чтения, то должна быть максимальная длинна строки, ну например как в ранзных code convention для С или Java. Я конечно понимаю, что на этот мой вопрос можно заявить, что xml – это не язык для представления данных, но как раз его читаемость (представимость) и заявлена создателями как плюс. Получается и не нормальное хранение данных и не хорошая читаемость. Все убого. 

 При наличии отступов он читаемый.
Отступы не ставят в случаях, когда файл предназначен на 99.9% для компьютера, а не человека. При этом любая современная десктопная юзер-ориентированная ОС стандартными средствами позволяет их прочесть.

 Т.е. когда я пишу, что в одном пункте автор полностью себе противоречит - то я описываю, как обойти недостатки XML?)
Советую перечитать то, что я написал.

 wrap lines не котируется? У нас непрерывные данные, и задание средств для их переноса:
1) Усложнило бы формат
2) Сделало бы плохочитаемым его на устройствах с шириной, не равной заданной ширине. Как владелец широкоформатника говорю ;)

  БД умеет наглядно отображать древовидные структуры? Внутренний формат БД читается легко человеком? XML удобен в первую очередь на стыке человек-машина. И нашим и вашим. Кроме того это стандарт, это значит что любой подготовленный человек откроет и поймет что к чему безо всяких инструкций. Так что смысл в этом есть. XML это просто. Не признаю XML без отступов, а лучше когда есть комментарии. Какой смысл обмениваться данными, которые не будет видеть человек в человекоудобной форме. Это как делать CPU под команды бейсика вместо машинных. Неэффективно и никому не нужно. Для этого правильнее делать сериализацию в бинарный формат. И быстрее и проще. 

Практически в любой системе есть вещи которые можно реализовать более чем одним способом. И в целом это не создает проблем (пока количество способов не превышает разумных пределов). К тому же атрибуты и вложенные теги все таки различаются, атрибуты не могут содержать CDATA, на атрибуты в XML Schema нельзя наложить некоторые ограничения.






Ну прям все, педивикия истина в последней инстанции  Вот например в английской версии никакого упоминания о том что XML должен заменить СУБД - нет. К тому же нет никаких препятствий для того чтобы скомбинировать два стандарта, тот же XML и ZIP.
Что же касается сравнения, 

ты сам сравниваешь XML - формат хранения структурированных данных, с форматами для библиотек/исполняемых файлов (jar), с форматами для хранения картинок, с форматами для РСУБД, со всем что тебе в данные момент удобно. А от меня требуешь, чтобы я ограничивался только форматами для структурированных данных.






Во первых без закрывающих тегов в любом случае не обойтись. Что это будет запятая как в JSON, закрывающая скобка, закрывающий тег как в XML, или просто конец строки, это отдельный вопрос.
Во вторых я и не отказываюсь от своих слов, XML нормально читается и без подсветки синтаксиса. Но подсветка синтаксиса и code folding делают чтение еще удобнее.





Из фразы того что XML используется в large-scale electronic publishing вовсе не следует, что объем самих XML документов должен быть большим.




До тех пор пока данные которые надо описать простые и не древовидные, property файлы конечно удобны. А вот когда надо реализовать что-то посложнее, начинаются извраты, достаточно поглядеть на property файлы от Log4j 






1. Как из количества криворуких программисто пишущих на каком то языке/использующих какой то формат/программирующих под какую то платформу/.... вытекает недостатки этого языка/формата/платформы/...?
2. Язык программирования это не формат хранения данных. Что же касается СУБД, то там куча своих проблем: денормализация, ссылочная целостность и т.д.
3. Ты пока не привел пример ни одно формата, который бы решал задачи обмена данными лучше чем XML. property файлы вообще не имеет средств для формального описания структуры, для JSON-а же schema есть, но по возможностям до XML Schema они не дотягивают, не стандартизованы, количество парсеров с их поддержкой стремится к 1 слева 
4. У меня противоположный опыт, всегда когда используется XML для него составляется схема, хотя бы для того чтобы можно было использовать биндинг 
5. Если фомат не указан то формат строка, вот и все