Почему XML?

xml старше json лет на двадцать.

Ещё у дефолтной имплементации JSON в лицензии указано не использовать для зла.

JSON лишь пример для подражания^Wсравнения
То что XML стар как свет, не ответ на вопрос, почему выбрали именно его. А то что проектов овер дохрена с ним - это уже последствия.

Для XML есть xpath и схема, для JSON подобных стандартных средств, ЕМНИП, нет.

Бытует мнение, что XML читабельный.

Булшит.

они дали в лицензии определение злу? Нет? Какие вопросы?

JSON такая же лапша, даже хуже. Also, твой JSON пешком под стол ходил, когда энтерпрайз решил, что ему что-то нужно.

Именно это и плохо.

Вот и пригодились «Похожие темы»: Чем JSON лучше XML?

Булшит.

А мне норм.

Везёт тебе.

XML более читабельный, чем JSON, если не использовать спец редакторы. Сравни:

...
            </user>
          </team>
        </organization>
        <configuration>
          <city id="12002">
...         

и

            }
          }
        }
        "configuration": {
          "city": {
            id: "12002",
...

есть xpath

JSON - это обычный словарь или массив, xpath там теряет смысл вообще.

схема

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

Погугли все стандарты, которые начинаются на X

В JSON даже комментов нет.

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

Есть смысл, плохо знаете XPath

Я наверно чего-то не понимаю, но конфиги опенбокса

сериализация

определись, тебе сериализацию или конфиги.

JSON - это обычный словарь или массив, xpath там теряет смысл вообще.

Допустим, у тебя JSON представляет дерево, тебе нужно получить значение достаточно глубоких узлов, удовлетворяющих некоторым условиям. Твои действия: писать по функции/методу на каждый такой случай? Или воспользоваться существующими JSON-аналогами xpath?

xpath же — просто строка, её можно без проблем передать хоть по сети. Кстати, при получении данных в из Google Custom Search используется что-то похожее на xpath для ограничения получаемых полей.

а учитывая то, что в JSON нет элементарных комментариев, переноса строк и валидации по схеме...

мне лично пофигу что читать - JSON или XML.

что в JSON нет элементарных комментариев

Если нужен json с комментариями, то имеет смысл взять yaml.

далекому от энтерпрайза

В enterpriZe строгость. Схемы xsd, как Вам уже тут ответили.

просто починил:

имеет смысл взять yaml.

</thread>

У меня такая же фигня. Star E пишу.

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

man xpath, man xsd, man namespace, man валидирующий парсер. JSON отличная штука для простых, однородных данных. А если нужна расширяемость, неймспейсы тэгов и т.п. - увы, альтернативы XML'ю я не вижу.

html[5] фактически частный случай XML, хотя и произрастает из sgml. XML позволяет задействовать атрибуты (хотя это и не приветствуется, но довольно удобно) и «проще расширять вложенность» по сравнению с JSON, но более избыточный.

Есть вариант YAML среднее между JSON и XML.

JSON как расшифровывается? JavaScript Object Notation. А Javascript имеет настолько отвратительную репутацию, что в серьёзном бизнесе не хотят использовать ничего даже косвенно связанного с ним. Ну и угловые скобочки рисовать легче, чем фигурные, это тоже имеет значение.

Помню, в году так 2001-2002 мощная движуха в сторону XML началась с пиара Web-сервисов. О JSON тогда ничего не слышал.

чёто мне ща книжка Фостер.Обработка списков.

пофорсю её(72 стр)

стр 38. пара абзацев озаглавленных

СПИСКИ ВО ВСПОМОГАТЕЛЬНОЙ ПАМЯТИ Если ёмкость машиной памяти недостаточна для решения нужной задачи или если требуется запомнить результаты на некоторое время между просчётами, то может понадобится помещать списки во внешнюю память. Представление списка во внешней памяти может совсем отличаться как от представления в основной машинной памяти, так и от записи, применяемой программистом. Обычное машинное представление удобно только до тех пор, пока элементы списка занимают постоянные места в памяти, отражённые в указателях. Но оно порождает значительные трудности при считывании списков в основную память, когда нельзя использовать старые адресса. То представление, с которым имеет дело пользователь, тоже не подходит, так как оно часто оказывается недостаточно детальным для того, чтобы дать возможность в точности восстановить список. Если список, включающий общий подсписок, помещается во внешнюю память, а потом считывается оттуда, то обычно возникает необходимость восстановить точную структуру общих подсписков вместо того, чтобы просто копировать их много раз. Поэтому во внешней памяти должна быть представлена детальная структура списков. Впрочем представление во внешней памяти имеет то преимущество, что оно предназначено для машинного чтения, а не для человеческого восприятия; поэтому не требуется, чтобы оно было понятно для людей. В частности, можно пользоваться той формой записи, которая описана выше для циклических списков, уплотнив её так, чтобы она стала удобней для машинного применения. Для атомов также необходимо найти некоторую форму представления.

это из монографии сданной впечать не позже 1968.

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

у json - при некотором дополнительном соглашении (а именно как же даги и прочии графы с циклами) тоже это возможно.

однако эталоный json не регламентирует как же серелизовать графы с циклами. - т.е каждый решает сам .

Вот и мне непонятно. JSON таки значительно лучше XMLя.

Мне то для сериализации, но применение XML ей не ограничивается.

А кто тебя просит сериализованный объект скармливать JS и ждать что_будет? Правильно, никто. Я в глаза JS не видел, но знаю что JSON которым я пользуюсь достаточно давно представляет собой синтаксис JS.

А Javascript имеет настолько отвратительную репутацию, что в серьёзном бизнесе не хотят использовать ничего даже косвенно связанного с ним.

В серьезном бизнесе предпочитают php?

Ну и угловые скобочки рисовать легче, чем фигурные, это тоже имеет значение.

((((А еще)легче)классические)((Lisp)стайл)так сказать)

Для XML есть xpath и схема, для JSON подобных стандартных средств, ЕМНИП, нет.

Есть json-schema.

Но форматы для разного, да. Сравнивать оба нечитабельных по читабельности - феерично.

Хочу стандартом yaml :(

но и предпосылки мне не понятны.

Исторически так сложилось. Была движуха, как у Лема, сделать «теорию всеобщего всего».

Сейчас кому надо использует и json и protobuf и yaml и много чего другого. Если вы видели только XML - значит фигово смотрели.

В рубях давно ямл под конфиги. Это в ноде фанбои гордятся, что умеют читать json и изобретают отрыжки вроде json5.

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

Для сериализации есть protobuf, thrift, json, messagepack. Это то что сразу вспомнил.

Потому что это было время «всё перепишем на джава» и иксемель был как раз её одним из столпов. Понятное дело, с XML сейчас связывается только больной.

Бытует мнение, что XML читабельный

Для машины - очень даже да.

Для XML есть xpath и схема, для JSON подобных стандартных средств, ЕМНИП, нет.

схема таки есть. ЧТо такое xpath незнаю.

/*! \brief add XML encoded media control with update
  \note XML: The only way to turn 0 bits of information into a few hundred. (markster) */
static int add_vidupdate(struct sip_request *req)
{
  const char *xml_is_a_huge_waste_of_space =
    "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\r\n"
    " <media_control>\r\n"
    "  <vc_primitive>\r\n"
    "   <to_encoder>\r\n"
    "    <picture_fast_update>\r\n"
    "    </picture_fast_update>\r\n"
    "   </to_encoder>\r\n"
    "  </vc_primitive>\r\n"
    " </media_control>\r\n";
  add_header(req, "Content-Type", "application/media_control+xml");
  add_content(req, xml_is_a_huge_waste_of_space);
  return 0;
}

Asterisk. chan_sip.c.

Всему виной хомячки: ну никак в их бошки не вбивается то, что кое-кто конфигурационные файлы руками правит, а не мышкой тыкает.

JSON лучше для данных, XML для документов. Разница в том, насколько сильно структурирована информация.

Для XML есть xpath и схема, для JSON подобных стандартных средств, ЕМНИП, нет.

Есть.