Чем JSON лучше XML?

Всем лучше. XML - труднораспаршиваемый хлам из прошлого века.

попробуй поработать с обоими из JS

Один из вариантов XML - property list - используют в Objective C, ибо там сериализация некоторых классов Foundation из коробки, а сам набор тегов в property list ограничен.

JSON - это такой же ограниченный несколькими типами язык (это плюс), и в javascript работа с ним из коробки, а для мобильников (java/objective c) библиотеки маленькие и хорошо отлаженные.

json для JavaScript это родной формат, а так абсолютно без разницы

Человекочитаемость явно ниже

[citation needed]

Человекочитаемость явно ниже

Не явно ниже. Это адский холивар. Рекомендую не начинать, на ЛОРе есть ярые слюнобрызгатели обеих сторон

JSON основан на списках и словарях, поэтому легко мапится на родные структуры данных любого современного языка безо всяких уродских DOM и SAX.

И второе: XML и SGML возникли как языки *разметки* для плоского текста. Их основной юзкейс - сплошное текстовое полотнище, в котором есть *немножко* тегов. А когда тегов становится больше, чем текста, это выглядит абсурдно. А JSON возник именно как язык для сериализации структурированных данных, поэтому для всяких веб-API это естественный выбор.

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

чем этот ваш JSON лучше XML

Для межпрограммного обмена - хуже.

Ну а если нужна человекочитаемость, то можно взять YAML, который в сущности тот же JSON, записанный в более человекочитаемом формате.

Человекочитаемость явно ниже

ЩИТО?

Ничем не лучше на самом деле. Обычная лапша.

Человекочитаемость явно ниже

Зато «человекописаемость» много выше :) Да и с читаемостью тоже вопрос тот ещё. Ну и парсится во вложенные массивы однозначно, в отличие от XML.

Человекочитаемость явно ниже

Не явно ниже. Это адский холивар. Рекомендую не начинать

Хорошо, постараюсь без холивара :)

Ну вот к примеру, в предоставленном по ссылке примере вся «простыня» вытянута в одну строку. Это требование синтаксиса JSON, или переводы строк таки можно вставлять?

Собственно, в xml тоже можно по-разному писать, но почти все XML, которые видел (и генерировал) я сделаны с разбиением по строкам и даже (что важно) с соблюдением отступов.

А когда тегов становится больше, чем текста, это выглядит абсурдно.

Да, это недостаток, соглашусь.

Это требование синтаксиса JSON, или переводы строк таки можно вставлять?

Нет, это сделано для минимизации объема передаваемых данных. http://jsonformat.com/

Есть pretty print, удобен для дебага. Но когда все налажено, то делают все в одну строчку что бы экономить траффик.

Пример pretty print

{
   "firstName": "Иван",
   "lastName": "Иванов",
   "address": {
       "streetAddress": "Московское ш., 101, кв.101",
       "city": "Ленинград",
       "postalCode": 101101
   },
   "phoneNumbers": [
       "812 123-1234",
       "916 123-4567"
   ]
}

Это в такой же мере читаемо/не читаемо как С, С++, Java

когда тегов становится больше, чем текста, это выглядит абсурдно

Обычное дело для JSON.

http://jsonformat.com/

Спасибо за ссылку. Скормил ей URL, про который шла речь.

Ну да, стало чуть понятнее. Но я не сказал бы, чтобы по антикритерию «тегов больше, чем текста», который тут упоминался, это сильно лучше XML. Те же теги, только скобочки другие. Впрочем, возможно, это я ещё не проникся сутью JSON...

это я ещё не проникся сутью JSON...

Суть - это простота. Вот, допустим, есть у меня питон. Чтоб забрать данные по ссылке мне достаточно сделать такое:

import urllib, json
data = json.loads(urllib.urlopen('http://www.linux.org.ru//forum/lor-source/8629357/comments').read())

Все, у меня есть уже нативная структура данных, с которой можно работать штатными средствами ЯП.

Так JSON и придуман для ситуаций, когда тегов больше, чем текста.

Посмотрел я тут в обсуждении будущего LOR API пример по ссылке из первого сообщения. Вот так и не понимаю я, чем этот ваш JSON лучше XML.

Экономия трафика, лучше и проще читабельность (как «человеческая» в режиме pretty, так и машинная).

Человекочитаемость явно ниже, а машине всё равно.

нет

Разве что компактность...

да.

Всем, просто у xml уже десятилетиями отлаженная развитая инфраструктура, вот и суют его куда ни попадя. Всё ровно так же, как и с тем же С++

Впрочем, возможно, это я ещё не проникся сутью JSON...

Лучше на конкретном примере показать:

<item name="item1">
 <prorerty name="param1">value1</property>
 <prorerty name="param2">value2</property>
  <items name="subitems">
    <item>
      <prorerty name="param1">value1</property>
      <prorerty name="param2">value2</property>
   </item>
    <item>
      <prorerty name="param1">value1</property>
      <prorerty name="param2">value2</property>
   </item>
 </items>
</item>

vs:

item1: {
  param1: value1;
  param2: value2;
  subitems: [
    {
      param1: value1;
      param2: value2;
    },
    {
      param1: value1;
      param2: value2;
    }
  ];
};

XML как бы скрывает данные за «разметкой», JSON же наоборот: демонстрирует данные, ненавязчиво предлагая «разметку». К тому же XML позволяет одну и ту же структуру данных описать различными способами. JSON однозначно указывает, что способов описать структуру есть ровно три: описать массив []. описать объект {} и описать пару «название:значение» . За счёт этой простоты улучшается(упрощается) парсинг, причём как машинный, так и «человеческий».

А почему все сказали про JS и никто не вспомнил про такое замечательное явление, как нереляционные БД (document store), как, например, MongoDB, где хранилище представляет из себя коллекции JSON документов? Даже в его «родном» промпте писать запросы в виде JSON - невероятно приятное занятие, скажу я вам. (:

А почему все сказали про JS

«Все» - это кто? Из отметившихся в топике только два участника упомянуло про JS :)

как нереляционные БД (document store), как, например, MongoDB, где хранилище представляет из себя коллекции JSON документов?

нуу... физически нет, не JSON. Физически данные хранятся в бинарном формате. Декорация потом происходит в JSON - это да.

А так вся разница сводится к наличию расшифровки закрывающих тегов :)

<item1>
 <param1>value1</param1>
 <param2>value2</param2>
 <subitems>
    <item>
      <param1>value1</param1>
      <param2>value2</param2>
    </item>
    <item>
      <param1>value1</param1>
      <param2>value2</param2>
    </item>
 </subitems>
</item1>

item1: {
  param1: value1;
  param2: value2;
  subitems: [
    {
      param1: value1;
      param2: value2;
    },
    {
      param1: value1;
      param2: value2;
    }
  ];
};

IMHO, всё равно xml смотрится избыточно.

И, как я уже писал, этот вариант ещё один из способов описать структуру данных (в дополнение к моему XML-примеру). Вроде структура данных та же, а «разметка» поменялась. Для такого удовольствия нужны тяжеловесные DOM-парсеры.

IMHO, всё равно xml смотрится избыточно.

Пока у тебя объекты небольшие — с десяток строчек, json читать проще.

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

IMHO, всё равно xml смотрится избыточно.

А это, имхо, от сложности структуры данных зависит. Чем сложнее структура, тем менее избыточным оказывается xml.

Это он пока сейчас такой легковесный этот json. Но кое кто уже пилит аналоги xpath, xslt, dtd ... для json и скоро будет все тоже самое. Смотрю на это только как на напрасную трату мировой энергии и денег. Завтра ibm скажет что скобочный формат еще лучше и начнут под него все переделывать ага.

Тут еще кричат что типов в json мало и они везде есть так выж все равно приводите эту утиную типизацию к строгой в java/c# а в json везде строковое поле type ага. Во всяких soap оно уже изкоробночно.

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

Восприятие человеком? В чём-то соглашусь, туча }}]}}]}}}]} в конце структуры может немного нарушить синаптические связи. С другой стороны, для человеков есть есть преттификаторы, которые облегчают просмотр JSON (и XML тоже).

Тем не менее, просмотр таких данных человеком (будь то JSON или XML) является скорее исключением из правил, чем правилом. Людям обычно показываются уже декорированные данные, а не голый поток структуры. Эти форматы больше для машинного разбора; люди на такие данные обычно только для отладки смотрят: на этапе разработки и/или на этапе тестирования.

А для машины восприятие роли не играет, ей наоборот «проще» парсить однозначный JSON вместо универсального, но неоднозначного XML.

И кстати действительно уже ищут более эффективную замену json в плане траффика/парсинга. Например http://msgpack.org/ http://bsonspec.org/

И все в конце концов сведется в старым добрым ctypes

эти форматы явно не human-readable. Они скорее не как замена, а как альтернатива там, где человекам не место.

И все в конце концов сведется в старым добрым ctypes

http://thrift.apache.org/

Вопрос из разряда «Чем ПМ лучше Калаша». Каждый для своих задач хорош. Возведение одного из них в абсолют возможно лишь от недостатка компетенции в предметной области.

С другой стороны, для человеков есть есть преттификаторы, которые облегчают просмотр JSON (и XML тоже).

Я имел ввиду чтение после преттификатора, то есть когда переносы строк и отступы правильно расставлены.

                                            }
                                        }
                                    ]
                                }
                            }
                        ]
                    }
                }
            }
        ]
    }

Чем JSON лучше:

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

2) Нормальные массивы.

3) JSON обычно рассматривается как конец цепи. Нет специальных стандартов, «основанных на JSON». В частности, обработка и верификация JSON-а делаются не самим JSON-ом, а кодом на том языке, на котором ведётся основная разработка.

Чем XML лучше:

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

2) Строковые литералы не нужно обрамлять кавычками (хотя иногда требуется эскейпить).

В таком случае, проще использовать интерактивные просмотрищики, позволяющие сворачивать узлы. Например, в файрбаг такой встроен.

Но Slavaz прав, читать голый json приходится очень редко.

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

Но если обратить внимание на время появления следующих форматов, то гипотеза о разумности будет сомнительна.

XML:

<item name="item1">
 <prorerty name="param1">value1</property>
 <prorerty name="param2">value2</property>
  <items name="subitems">
    <item>
      <prorerty name="param1">value1</property>
      <prorerty name="param2">value2</property>
   </item>
    <item>
      <prorerty name="param1">value1</property>
      <prorerty name="param2">value2</property>
   </item>
 </items>
</item>

JSON:

item1: {
  param1: value1;
  param2: value2;
  subitems: [
    {
      param1: value1;
      param2: value2;
    },
    {
      param1: value1;
      param2: value2;
    }
  ];
};

S-expression

(item1
   (param1 "value1")
   (param2 "value2")
   (subitems
      ((param1 "value1")
       (param2 "value2") )
      ((param1 "value1")
       (param2 "value2") ) ) )

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

Отказываюсь воспринимать тред без меток [грибы] и/или [упорин].

АПИ делается в первую очередь для клиентских скриптов. Сделай усилие и вспомни на чём пишут клиенские скрипты а потом расшифруй аббревиатуру JSON.

Человекочитаемость - субъективщина и миф, я бы это слово убрал чтоб не позориться. Аналогично компактность в общем-то.

То-то я чувствую чего-то не хватало. Теперь это обсуждение идеальное и каноничное.

S-expression

Too fat.

Человекочитаемость - субъективщина и миф

Авторы ДРАКОН-а смотрят на тебя с презрением.

[cite] S-expression

Too fat. [/cite]

Не флейма ради, а любопытства для, а что с ними не так?

Но если обратить внимание на время появления следующих форматов, то гипотеза о разумности будет сомнительна.

XML

~1998 (~1985 в качестве SGML)

JSON

~1999:

S-expression

~1960 (~1930 как рождение концепции записи исчислений)

порядок возникновения форматов притянут Вами за уши.
Гипотеза, выведенная из такого ошибочного порядка, не имеет смысла.

У меня давно иммунитет, спасибо ямлу. Что самое интересное, многие таки с пеной у рта пытаются доказать(sic!) что ямл такой весь всем понятный.

Это щас модно. Руби на рельсах в облаке через nosql и json реализует rest api, школота в экстазе пишет статью на хабр.