Для меня полезный означает, что:
Также я хочу, чтобы он был как можно ближе к XML, т.е. должна существовать поддержка атрибутов, а также свойств. Итак, YAML, пожалуйста. В настоящее время мне приходит в голову только один подходящий язык - JSON. Знаете ли вы другие альтернативы?
YAML - это 100% -ый суперсет JSON, поэтому нет смысла отклонять YAML, а затем рассматривать JSON. YAML делает все, что делает JSON, но YAML дает гораздо больше (например, ссылки).
Я не могу думать о том, что XML может сделать, что YAML не может, за исключением проверки документа с DTD, который по моему опыту никогда не стоил накладных расходов. Но YAML намного быстрее и проще печатать и читать, чем XML.
Что касается атрибутов или свойств, если вы думаете об этом, они действительно не "добавляют" что-либо... это просто нотативный ярлык, чтобы написать что-то как атрибут node вместо того, чтобы помещать его в свой собственный ребенок node. Но если вам нравится это удобство, вы можете часто эмулировать его с помощью встроенных списков/хэшей YAML. Например:
<!-- XML -->
<Director name="Spielberg">
<Movies>
<Movie title="Jaws" year="1975"/>
<Movie title="E.T." year="1982"/>
</Movies>
</Director>
# YAML
Director:
name: Spielberg
Movies:
- Movie: {title: E.T., year: 1975}
- Movie: {title: Jaws, year: 1982}
Для меня роскошь не нужно писать каждый тэг node дважды, в сочетании со свободой от всех подкладок с угловыми скобками делает YAML предпочтительным выбором. Мне также на самом деле нравится отсутствие формальных атрибутов тегов, поскольку это всегда казалось мне серым областью XML, который бесполезно вводил два набора синтаксиса (как при записи, так и при переходе) по существу одной и той же концепции. YAML полностью устраняет эту путаницу.
JSON - очень хорошая альтернатива, и есть инструменты для него на нескольких языках. И это действительно легко использовать в веб-клиентах, поскольку это родной javascript.
Джефф написал об этом здесь и здесь. Это должно помочь вам начать работу.
Я бы порекомендовал JSON... но так как вы уже упомянули об этом, возможно, вам стоит взглянуть на буферы протокола Google.
Редактирование: буферы протокола предназначены для использования программно (существуют привязки для С++, java, python...), поэтому они могут не подходить для вашей цели.
Вы требования немного невозможны.. Вы хотите что-то близкое к XML, но отклоните, вероятно, ближайший эквивалент, который не имеет угловой скобки (YAML).
Насколько мне это не нравится, почему бы просто не использовать XML? Вы никогда не должны на самом деле читать XML (за исключением отладки, я полагаю), есть абсурдное количество инструментов для него.
Практически все, что не является XML, не будет столь широко использоваться, поэтому поддержка инструментов будет меньше.
JSON, вероятно, примерно эквивалентен, но он в значительной степени нечитабелен. Но опять-таки вам не следует когда-либо читать его (загружать на любой язык, который вы используете, и его нужно преобразовать в собственные массивы/dicts/переменные/все).
О, я нахожу JSON намного лучше, чем синтаксический анализ XML: я использовал его в Javascript, а модуль simplejson Python - об одной команде, и он красиво преобразуется в собственный Python dict или объект Javascript (таким образом, имя!)
Я нашел S-Expressions, чтобы стать отличным способом представления структурированных данных. Это очень простой формат, который легко создавать и анализировать. Он не поддерживает атрибуты, но, как YAML и JSON, он не нужен. Атрибуты - это просто способ для XML ограничить многословие. Более простые, чистые форматы просто не нужны.
Пролог здесь не упоминался, но это лучший формат, который я знаю для представления данных. Программы Prolog, по сути, описывают базы данных со сложными отношениями между сущностями. Пролог мертв - просто разобрать, чей, вероятно, только соперник - это S-выражения в этом домене.
Поэтому поиск альтернативы XML - не очень хорошая идея. Вы, вероятно, не хотите иметь дело с подобными XML вообще.
YAML, вероятно, второй худший вариант. Он не такой большой, как XML, но он также был разработан в попытке охватить все базы... более десяти раз каждый... по-разному и уникальным образом, о которых никто никогда не мог себе представить. Я еще не слышал о правильно работающем парсере YAML. Ruby, язык, который много использует YAML, из-за этого лихо извратил. Все партизаны YAML, которые я видел на сегодняшний день, являются копиями libyaml, который сам по себе является рукописным (не сгенерированным из формального описания ) вид анализатора с кодом, который очень сложно проверить на правильность (функции, которые охватывают сотни строк с запутанным потоком управления). Как уже упоминалось, он полностью содержит JSON в нем... помимо нескольких методов кодирования Unicode... внутри того же документа и, вероятно, множество других вещей, о которых вы не хотите слышать.
JSON, с другой стороны, совершенно не похож на два других. Вероятно, вы можете написать парсер JSON, ожидая загрузки артефакта парсера JSON с вашего Maven Nexus. Он может сделать очень мало, но по крайней мере вы знаете, на что он способен. Без сюрпризов. (За исключением некоторых расхождений, связанных с символом, ускоряющимся в строках и удвоением кодирования). Никаких скрытых подвигов. Вы не можете писать в нем комментарии. Многострочные строки выглядят плохо. Независимо от того, что вы подразумеваете под различием свойств и атрибутов, вы можете реализовать более вложенные словари.
Предположим, хотя вы хотели бы исправить то, что помешало XML... ну, тогда популярные вещи, такие как YAML или JSON, не будут делать этого. Каким-то образом мода и рациональное мышление расстались в программировании в середине семидесятых. Итак, вам придется вернуться туда, где все началось с Маккарти, Хоара, Кодда и Ковальского, выяснить, что вы пытаетесь представить, а затем посмотреть, какая техника наилучшего представления существует для всего, что вы есть пытаясь представить:)
Существует AXON, которые охватывают лучшие из XML и JSON. Объясним это в нескольких примерах.
AXON можно рассматривать как более короткую форму XML-данных.
XML
<person>
<name>Frank Martin</name>
<age>32</age>
</person>
AXON
person{
name{"Frank Martin"}
age{32}}
или
person
name:
"Frank Martin"
age:
32
XML
<person name="Frank Martin" age="32" />
AXON
person{name:"Frank Martin" age:32}
или
person
name: "Frank Martin"
age: 32
AXON содержит некоторую форму JSON.
JSON
{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}
AXON
{name:"Frank Martin" age:32 birth:1965-12-24}
AXON может представлять собой комбинацию XML-подобных и JSON-подобных данных.
AXON
table {
fields {
("id" "int") ("val1" "double") ("val2" "int") ("val3" "double")
}
rows {
(1 3.2 123 -3.4)
(2 3.5 303 2.4)
(3 2.3 235 -1.2)
}
}
Теперь доступна библиотека python pyaxon.
Я думаю, Clearsilver - очень хорошая альтернатива. У них даже есть страница сравнения здесь и список projects, которые используют его
YAML - чрезвычайно полнофункциональный и общедоступный формат, но исцеление Achilles - это сложность, о чем свидетельствуют уязвимости Rails, которые мы видели в эту зиму. Из-за своей повсеместности в Ruby в качестве языка конфигурации Том Престон-Вернер из Github славы активизировал создание разумной альтернативы, получившей название TOML. Он получил массивную тягу сразу и имеет отличную поддержку инструмента. Я настоятельно рекомендую всем, кто смотрит на YAML, проверить это:
Для хранения кодовых данных LES (синтаксис выражения Loyc) является альтернативой для начинающих. Я заметил, что многие люди используют XML для кодовых конструкций, таких как системы сборки, которые поддерживают условные обозначения, вызовы команд, иногда даже циклы. Подобные вещи выглядят естественно в LES:
// LES code has no built-in meaning. This just shows what it looks like.
[DelayedWrite]
Output(
if version > 4.0 {
$ProjectDir/Src/Foo;
} else {
$ProjectDir/Foo;
}
);
У него пока нет отличной поддержки инструмента; в настоящее время единственная библиотека LES предназначена для С#. Известно, что только одно приложение использует LES: LLLPG. Он поддерживает "атрибуты", но они похожи на атрибуты С# или аннотации Java, а не на атрибуты XML.
В теории вы можете использовать LES для данных или разметки, но нет стандартов для того, как это сделать:
body {
'''Click here to use the World '''
a href="http://google.com" {
strong "most popular"; " search engine!"
};
};
point = (2, -3);
tasteMap = { "lemon" -> sour; "sugar" -> sweet; "grape" -> yummy };
Если у вас аллергия на угловые скобки, то JSON, HDF (ClearSilver) и OGDL - это единственные, кого я знаю из рук в руки.
После небольшого количества поисковых запросов я также нашел список альтернатив:
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html
AFAIK, JSON и YAML в точности эквивалентны в терминах структуры данных. У YAML просто меньше скобок и цитат и прочее. Поэтому я не вижу, как вы отвергаете одного и сохраняете другого.
Кроме того, я не вижу, как угловые скобки XML менее "читаемы человеком", чем квадратные скобки JSON, фигурные скобки и кавычки.
Есть действительно много альтернатив XML, но основная проблема со многими из них, по-видимому, заключается в том, что библиотеки могут быть недоступны для каждого выбранного языка, а библиотеки относительно трудоемки для реализации.
Анализ структуры дерева может быть не таким приятным, если сравнивать с парами ключ-значение, например. хэш-таблицы. Если экземпляр хэш-таблицы соответствует требованию, что все его ключи являются строками, а все его значения являются строками, то это относительно не требует трудоемкости для реализации hashtable2string() и string2hashtable().
Я использую сериализацию таблиц хеш файлов в AJAX между PHP и JavaScript и формат, который я разработал, называется ProgFTE (программатор дружественного текстового обмена) и описывается по адресу:
http://martin.softf1.com/g/n//a2/doc/progfte/index.html
Можно найти версию Ruby версии Ruby как часть библиотеки Ruby Kibuvits: http://rubyforge.org/projects/kibuvits/