XML против YAML против JSON

Question

Предполагается, что я начинаю проект с нуля, который не зависит ни от какого другого проекта. Я хотел бы использовать формат для хранения каналов, что-то вроде XML, поскольку XML - не единственный доступный формат в своем роде, я хотел бы знать: почему я должен выбрать один из остальных?

Я буду использовать Perl.

«Канал» - это описание товара (название, цена, тип, краткое описание, до 120 слов).

Answer 1

Мы не можем ответить на этот вопрос, не зная намного больше.Просто потому, что вы в настоящее время не зависите от каких-либо других проектов, вы, вероятно, будете взаимодействовать с ними в будущем?Если да, то какие технологии они предпочитают?На Би-би-си у нас было несколько проектов, предназначенных только для JSON, только для того, чтобы узнать, что разработчики Java, которые хотели получить доступ к нашему API, умоляли предоставить нам простой XML API просто потому, что у них так многоИнструмент построен на XML.Они даже не заботились о пространствах имен, атрибутах или чем-то еще;они просто хотели эти угловые скобки.

Что касается "хранения каналов", я также не уверен, что вы имеете в виду.Вы объясняете данные в ленте, но что вы собираетесь делать с этими фидами?Разобрать их?Кешировать и резервировать их?Выписать их на клинописные таблички?:)

Мне кажется, что вам действительно нужна база данных, и вы хотите сохранить данные там, а затем сделать их сериализуемыми в формате JSON / YAML / XML или в любом другом формате.Я бы порекомендовал уметь извлекать данные в структуру данных Perl, а затем иметь «средства форматирования», которые знают, как сериализовать эту структуру данных до желаемого результата.Таким образом, вы можете сериализовать, скажем, в JSON, а затем, если этого недостаточно, легко переключиться на YAML или что-то еще.Фактически, если другим нужны ваши данные (односторонние данные обычно бесполезны), они могут запросить JSON, YAML, XML или что-то еще.У вас больше гибкости, и вы не привязаны к принятому вами ранее решению.

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

Answer 2

Каждый выполнит свою работу.

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

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

Answer 3

Я думаю, что XML был подробно объяснен другими.Тем не менее, YAML и JSON являются элегантными языками, и они не так похожи, как вы могли бы подумать на первый взгляд.

Некоторые из особенностей YAML

• Ссылки

  - person: &id002
      name:   James
      age:    5.0
  
  - person: *id001
  

  Второй человек - это ассоциативный массив, равный первому.

• Типы данных Casting

  foobar: !!str 123
  

  foobar равен "123" (строка типа).

• Uncommonтипы данных, не поддерживаемые каждой реализацией

  Википедия:

  Особенно интересными [...] являются множества, упорядоченные карты, временные метки и шестнадцатеричные числа.

Поэтому я считаю JSON намного проще.

Аргумент для JSON

Не только для JavaScript

Хотя может показаться глупым использовать «объектную нотацию JavaScript» для вашего приложения, если вы не используете JavaScript, вы все равно должны это учитывать, потому чтоТипы данных, предлагаемые в JSON, являются, вероятно, самыми распространенными в вашем языке.

Читаемые, даже если пробел необязательный

Я думаю, что JSON очень хорошо читается после предварительной проверки, что очень легко сделать.YAML сложно сделать компактным, поскольку он опирается на пробелы.Конечно, вы должны полагаться на сжатие для экономии пропускной способности.Ссылки в YAML могут сэкономить вам несколько байтов, но они добавляют много сложности.Если вы действительно имеете дело с объемами данных, которые делают важным избежать дублирования, я бы предложил решить эту проблему на другом уровне.Даже XML не поддерживает такие макросы.

Answer 4

Выберите XML, если вам нужно взаимодействовать с системами, которые вы не контролируете (схема XML здесь неоценима), если вы будете активно преобразовывать данные в текст, HTML или XML (несмотря на ненавистники, XSLT бесподобен), есливаши данные содержат много текстовой разметки, если ваши данные должны быть доступны для редактирования человеком (несмотря на ненавистников, редактируемый XML, который проверяется на соответствие схеме, является довольно хорошим инструментом для многих заданий), и / или если вам нужно взаимодействовать с любымиз множества инструментов и технологий, которые работают с XML.

Выберите JSON, если вы действительно не можете быть обеспокоены любым из вышеперечисленного.

Выберите YAML, если вы работаете в средекоторый получил большую поддержку YAML.

Answer 5

JSON будет моим выбором. JSON и YAML легки и с ними легко начать (формальная схема не требуется). JSON более широко используется и более совместим с другими технологиями, чем YAML. Например, в PHP есть встроенная функция для декодирования или кодирования JSON, а не YAML. JavaScript, конечно, просто любит JSON, учитывая, что это строгое подмножество действительного JavaScript.

Answer 6

Я согласен с Джо. Например, если это приложение javascript; JSON будет сильным кандидатом. Лично я бы пошел с json почти на все, но только потому, что это то, с чем мне удобнее всего.

Answer 7

Зависит от ваших потребностей.Для небольших легких приложений я лично считаю, что XML - это слишком много: http://www.codinghorror.com/blog/2008/05/xml-the-angle-bracket-tax.html

Я предпочитаю YAML в этом случаедля взаимодействия с javascript используйте json.Если вам действительно нужно определить свою собственную грамматику (читай: схема), тогда это xml.Очень мощный, вы должны решить, что вы пытаетесь сделать, иначе ваш вопрос слишком широк, чтобы дать однозначный ответ.

Answer 8

Если данные не являются иерархическими или будут иметь данные, например, в описании This product is great for <targetDemo/> who love it's <featureSet/>), вы можете рассмотреть значения, разделенные запятыми ( CSV ) или некоторые другиеформат как разделенный табуляцией.

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

<feed name="" price="" type="" description=""/>

... в отличие от CSV:

"", , "", ""

Если вы хотите, вы можетедобавьте строку заголовка вверху для целей документирования.

Существует также множество инструментов для CSV, от утилит командной строки, таких как awk, до графических интерфейсов, таких как Excel.

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

Answer 9

В отсутствие проблем с совместимостью, я не думаю, что это много. Есть хорошие библиотеки для всех на всех языках; некоторые из них встроенные, некоторые нет. Интерфейс Yur для этих библиотек будет узким - только в коде доступа к данным - поэтому, если у вас есть болезненный API, даже это не имеет большого значения.

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

YAML может обрабатывать не древовидные структуры данных, используя нотацию & / *. Ни XML, ни JSON не имеют встроенного способа сделать это. Ваше использование не нуждается в этом, однако.

Answer 10

Я думаю, что xml предназначен для больших данных, а json - для небольших и не слишком сложных данных, которые не требуют многомерного массива.Я могу быть не прав.^^ И я вижу только yaml в Google App Engine.Как мне кажется, он вполне подходит для хранения настроек и данных приложения.