Предполагая, что я начинаю проект с нуля, что не зависит от какого-либо другого проекта. Я хотел бы использовать формат для хранения фидов, например XML, поскольку XML не является единственным доступным форматом такого рода, я хотел бы знать: почему я должен выбирать один из них?
Я буду использовать perl.
'Feed' - описание продукта (имя, цена, тип, краткое описание, до 120 слов).
Мы не можем ответить на это, не зная намного большего. Просто потому, что в настоящее время вы не зависите от каких-либо других проектов, возможно, вы в какой-то момент в будущем будете взаимодействовать с ними? Если да, то какие технологии они предпочитают? На BBC у нас были некоторые проекты "только JSON", только чтобы узнать, что разработчики Java, которые хотели получить доступ к нашему API, попросили нас предоставить простой XML-API просто потому, что у них так много инструментов, построенных вокруг XML. Им даже не нравились пространства имен, атрибуты или что-то еще; им просто нужны угловые скобки.
Что касается "хранения фидов", я также не уверен, что вы имеете в виду. Вы объясняете данные в фиде, но что вы собираетесь делать с этими фидами? Разберите их? Кэшировать и резервировать их? Напиши их на клинописные таблетки?:)
Мне кажется, что вам действительно нужна база данных, и вы хотите сохранить данные там, а затем сделать ее сериализуемой как JSON/YAML/XML или независимо от вашего желаемого формата. То, что я рекомендую, - это возможность вытащить данные в структуру данных Perl, а затем "formatters", которые знают, как сериализовать эту структуру данных на желаемый результат. Таким образом, вы можете сериализовать, скажем, JSON, а позже, если это не достаточно хорошо, легко переключитесь на YAML или что-то еще. Фактически, если другим нужны ваши данные (односторонние данные имеют тенденцию не быть полезными), они могут запрашивать JSON, YAML, XML или что-то еще. У вас больше гибкости и не связаны с решением, которое вы сделали спереди.
Сказав это, я не знаю вашей системы, поэтому трудно сказать, что нужно делать. Кроме того, не то, что JSON и YAML не совсем взаимозаменяемы с XML. Тонкие различия могут и будут вас трогать.
Каждый из них выполнит задание.
JSON имеет преимущество супер-простого разбора в JavaScript, хотя вам, вероятно, придется найти и внедрить библиотеку на других языках.
XML имеет то преимущество, что больше языка связывает соответствующие библиотеки и полезно для упомянутого вами хранилища. Таким образом, это полезно для прохождения через разные системы, как "в движении", так и "в состоянии покоя".
YAML имеет библиотеки для всех языков, но несколько менее часто используется, поэтому вам, скорее всего, придется найти и ввести библиотеку.
Я думаю, что XML был полностью объяснен другими. Тем не менее, YAML и JSON - оба элегантных языка, и они не так похожи, как вы могли бы на первый взгляд подумать.
<сильные > Ссылки
- person: &id002 name: James age: 5.0 - person: *id001
Второй человек - ассоциативный массив, равный первому.
Типы данных литья
foobar: !!str 123
foobar - "123" (строка типа).
Необычные типы данных, не поддерживаемые каждой реализацией
Википедия:
Особенно интересные [...] - это наборы, упорядоченные карты, временные метки и шестнадцатеричные.
Поэтому я считаю JSON намного проще.
Не только для JavaScript
Хотя может показаться глупым использование "Обозначения объекта JavaScript" для вашего приложения, если вы не используете JavaScript, вы все равно должны его рассматривать, потому что типы данных, предлагаемые в JSON, вероятно, являются наиболее распространенными в вашем языке тоже.
Чтение, даже если пробел является необязательным
Я думаю, что JSON очень читабельна после того, как была пресечена, что очень легко сделать. YAML трудно сделать компактным, поскольку он опирается на пробелы. Конечно, вы должны полагаться на сжатие для экономии полосы пропускания. Ссылки в YAML могут сэкономить вам несколько байтов, но они добавляют много сложности. Если вы действительно имеете дело с количеством данных, что делает важным избежать дублирования, я бы предложил решить эту проблему на другом уровне. Даже XML не поддерживает такие макросы.
Выберите XML, если вам нужно взаимодействовать с системами, которые вы не контролируете (XML Schema здесь неоценим), если вы будете широко трансформировать данные в текст, HTML или XML (несмотря на то, что XSLT не имеет равных возможностей), if ваши данные включают в себя много текстовой разметки, если ваши данные должны быть редактируемыми для человека (несмотря на то, что ненавистники, редактируемый XML, который проверен на соответствие схеме, является довольно хорошим инструментом для множества заданий) и/или если вам необходимо взаимодействовать с любым из множества инструментов и технологий, которые работают с XML.
Выберите JSON, если вы действительно не можете беспокоиться об этом.
Выберите YAML, если вы работаете в среде, в которой много поддержки YAML.
Я согласен с Джо. Например, если это приложение javascript; json будет сильным кандидатом. Лично я бы пошел с json практически ко всему, но только потому, что это тот самый, с кем мне больше всего нравится.
JSON был бы моим выбором. JSON и YAML легки и легко начинаются с (формальная схема не требуется). JSON более широко используется и более совместим с различными другими технологиями, чем YAML. Например, PHP имеет встроенную функцию для декодирования или кодирования JSON, а не YAML. JavaScript, конечно, просто любит JSON, считая его строгим подмножеством действующего JavaScript.
В зависимости от ваших потребностей. Для небольших, легких приложений я лично считаю, что XML переполнен: http://www.codinghorror.com/blog/2008/05/xml-the-angle-bracket-tax.html
Я предпочитаю YAML в этом случае. для взаимодействия с javascript используйте json. Если вам действительно нужно определить свою собственную грамматику (read: schema), тогда xml это. Очень мощный, вы должны решить, что вы пытаетесь сделать - иначе ваш вопрос слишком широк, чтобы дать окончательный ответ.
Если данные не являются иерархическими или будут иметь данные, перемежающиеся, например, в описании
This product is great for <targetDemo/> who love it <featureSet/>), вы можете захотеть рассмотреть Разделяемые значения запятой (CSV) или какой-либо другой формат, например разделение вкладки.
Это старая школа, но она выполняет свою работу без взвешивания вашего файла с кучей описания текста. I.e., в XML, у вас будут следующие нецензурные данные для каждого фида.
<feed name="" price="" type="" description=""/>
... противопоставляется CSV:
"", , "", ""
Если вы хотите, вы можете добавить строку заголовка вверху для целей документации.
Там также много инструментов для CSV, из утилит командной строки, таких как awk для GUI, таких как Excel.
Другая альтернатива, если вам действительно не нужны данные для редактирования через текстовый редактор, но не хотите развертывать более надежную службу базы данных, будет SQLite, который позволяет выполнять операции CRUD в стиле RDBMS в плоском двоичном файле.
В отсутствие проблем с совместимостью я не думаю, что в этом много чего. Для всех есть хорошие библиотеки на всех языках; некоторые из них встроены, некоторые - нет. Интерфейс Yur для этих библиотек будет узким - только в коде доступа к данным - поэтому, если у вас есть болезненный API, даже это не имеет большого значения.
JSON для меня наиболее приятен для редактирования вручную, что является небольшим плюсом.
YAML может обрабатывать недревесные структуры данных, используя нотацию &/*. Ни XML, ни JSON не имеют встроенного способа сделать это. Однако ваше использование не нуждается в этом.
Я думаю, что xml предназначен для больших данных, а json - для небольших и не слишком сложных данных, для которых не требуется множество измерений массива. Я могу быть не прав. ^^ И я только вижу yaml в движке Google. Что мне кажется, оно вполне подходит для хранения предпочтений и данных приложения.