В 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. Если фомат не указан то формат строка, вот и все