История изменений
Исправление KennyMinigun, (текущая версия) :
Для XML есть и XSD с нормальной валидацией, и SAX парсеров нормальных полно, и полиморфные элементы в нем удобнее хранить.
Я не имел ввиду JSON. Просто в той статье сравнение неплохое. Но раз за JSON - так за JSON.
Во-первых для последнего есть куча парсеров на любой вкус (свободных, лёгких, простых, быстрых). Тут хорошее обсуждение. А Тут приличный список JSON библиотек для разных ЯП (и платформ).
Во-вторых валидаторы схемы для JSON тоже есть (Тут и Тут тоже).
А JSON советуют просто потому что это модно и молодежно.
Поддержу Ваше мнение: а XML - это по старпёрски.
и полиморфные элементы в XML удобнее хранить.
Тут согласен. Если сериализовать обьекты определённого класса, то логично предположить такую семантику:
<namespace:SomeClass><!-- Описание внутренней структуры --></namespace:SomeClass>
Но ведь в JSON никто не запрещает добавить поле для идентификации типа:
{ type: "SomeClass", namespace: "namespace", /* Описание внутренней структуры */ }Для сложных структур данных XML вне конкуренции.
Почему?
Исправление KennyMinigun, :
Для XML есть и XSD с нормальной валидацией, и SAX парсеров нормальных полно, и полиморфные элементы в нем удобнее хранить.
Я не имел ввиду JSON. Просто в той статье сравнение неплохое. Но раз за JSON так за JSON.
Во-первых для последнего есть куча парсеров на любой вкус (свободных, лёгких, простых, быстрых). Тут хорошее обсуждение. А Тут приличный список JSON библиотек для разных ЯП (и платформ).
Во-вторых валидаторы схемы для JSON тоже есть (Тут и Тут тоже).
А JSON советуют просто потому что это модно и молодежно.
Поддержу Ваше мнение: а XML - это по старпёрски.
и полиморфные элементы в XML удобнее хранить.
Тут согласен. Если сериализовать обьекты определённого класса, то логично предположить такую семантику:
<namespace:SomeClass><!-- Описание внутренней структуры --></namespace:SomeClass>
Но ведь в JSON никто не запрещает добавить поле для идентификации типа:
{ type: "SomeClass", namespace: "namespace", /* Описание внутренней структуры */ }Для сложных структур данных XML вне конкуренции.
Почему?
Исправление KennyMinigun, :
Для XML есть и XSD с нормальной валидацией, и SAX парсеров нормальных полно, и полиморфные элементы в нем удобнее хранить.
Я не имел ввиду JSON. Просто в той статье сравнение неплохое. Но раз за JSON так за JSON.
Во-первых для последнего есть куча парсеров на любой вкус (свободных, лёгких, простых, быстрых). Тут хорошее обсуждение. А Тут приличный список JSON библиотек для разных ЯП (и платформ).
Во-вторых валидаторы схемы для JSON тоже есть (Тут и Тут тоже).
А JSON советуют просто потому что это модно и молодежно.
Поддержу Ваше мнение: а XML - это по старпёрски.
и полиморфные элементы в XML удобнее хранить.
Тут согласен. Если сериализовать обьекты определённого класса, то логично предположить такую семантику:
<namespace:SomeClass><!-- Описание внутренней структуры --></namespace:SomeClass>
Но ведь в JSON никто не запрещает добавить поле для идентификации типа:
{ type: "SomeClass", namespace: "namespace", /* Описание внутренней структуры*/ }Для сложных структур данных XML вне конкуренции.
Почему?
Исправление KennyMinigun, :
Для XML есть и XSD с нормальной валидацией, и SAX парсеров нормальных полно, и полиморфные элементы в нем удобнее хранить.
Я не имел ввиду JSON. Просто в той статье сравнение неплохое. Но раз за JSON так за JSON.
Во-первых для последнего есть куча парсеров на любой вкус (свободных, лёгких, простых, быстрых). Тут хорошее обсуждение. А Тут приличный список JSON библиотек для разных ЯП (и платформ).
Во-вторых валидаторы схемы для JSON тоже есть (Тут и Тут тоже).
А JSON советуют просто потому что это модно и молодежно.
Поддержу Ваше мнение: а XML - это по старпёрски.
и полиморфные элементы в XML удобнее хранить.
Тут согласен. Если сериализовать обьекты определённого класса, то логично предположить такую семантику:
<namespace:SomeClass><!-- Описание внутренней структуры --></namespace:SomeClass>
Но ведь в JSON никто не запрещает добавить поле для идентификации типа:
{ type: "SomeClass", namespace: "namespace" }Для сложных структур данных XML вне конкуренции.
Почему?
Исправление KennyMinigun, :
Для XML есть и XSD с нормальной валидацией, и SAX парсеров нормальных полно, и полиморфные элементы в нем удобнее хранить.
Я не имел ввиду JSON. Просто в той статье сравнение неплохое. Но раз за JSON так за JSON.
Во-первых для последнего есть куча парсеров на любой вкус (свободных, лёгких, простых, быстрых). Тут хорошее обсуждение. А Тут приличный список JSON библиотек для разных ЯП (и платформ).
Во-вторых валидаторы схемы для JSON тоже есть (Тут и Тут тоже).
А JSON советуют просто потому что это модно и молодежно.
Поддержу Ваше мнение: а XML - это по старпёрски.
и полиморфные элементы в XML удобнее хранить.
Тут согласен. Если сериализовать обьекты определённого класса, то логично предположить такую семантику:
<namespace:SomeClass><!-- Описание внутренней структуры --></namespace:SomeClass>
Но ведь в JSON никто не запрещает добавить поле для идентификации типа:
{ type: "SomeClass", namespace: "namespace" }Исходная версия KennyMinigun, :
Для XML есть и XSD с нормальной валидацией, и SAX парсеров нормальных полно, и полиморфные элементы в нем удобнее хранить.
Я не имел ввиду JSON. Просто в той статье сравнение неплохое. Но раз за JSON так за JSON.
Во-первых для последнего есть куча парсеров на любой вкус (свободных, лёгких, простых, быстрых). Тут хорошее обсуждение. А Тут приличный список JSON библиотек для разных ЯП (и платформ).
Во-вторых валидаторы схемы для JSON тоже есть (Тут и Тут тоже).
А JSON советуют просто потому что это модно и молодежно.
Поддержу Ваше мнение: а XML - это по старпёрски.
и полиморфные элементы в XML удобнее хранить.
Тут согласен. Если сериализовать обьекты определённого класса, то логично предположить такую семантику:
<namespace:SomeClass><!-- Описание внутренней --></namespace:SomeClass>