Какие полезные альтернативы синтаксису XML вы знаете?

Question

Для меня использовать означает, что:

• он используется в реальной пустоши
• он имеет поддержку инструментов. (По крайней мере, некоторые простой редактор)
• имеет читаемый синтаксис человека (угол не скобки, пожалуйста)

Кроме того, я хочу, чтобы это было как можно ближе к XML, как это возможно, то есть должна быть поддержка атрибутов, а также для свойств. Итак, нет YAML пожалуйста. В настоящее время мне приходит в голову только один подходящий язык - JSON. Знаете ли вы другие альтернативы?

Answer 1

YAML - это 100% -ый суперсет JSON, поэтому не имеет смысла отклонять YAML, а затем рассматривать JSON вместо этого. YAML делает все, что делает JSON, но YAML дает гораздо больше (например, ссылки).

Я не могу придумать ничего, что может сделать XML, что YAML не может, за исключением проверки документа с DTD, который по моему опыту никогда не стоил накладных расходов. Но YAML намного быстрее и проще печатать и читать, чем XML.

Что касается атрибутов или свойств, если вы думаете об этом, они действительно не «добавляют» что-либо ... это всего лишь нотативный ярлык, чтобы написать что-то как атрибут узла вместо того, чтобы помещать его в свой собственный дочерний узел. Но если вам нравится это удобство, вы можете часто имитировать его с помощью встроенных списков/хэшей 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} 

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

Answer 2

JSON - очень хорошая альтернатива, и есть инструменты для него на нескольких языках. И он очень прост в использовании в веб-клиентах, поскольку он является родным javascript.

Answer 3

Я бы порекомендовал JSON ... но так как вы уже упомянули, возможно, вам стоит взглянуть на Google protocol buffers.

Редактирование: Буферы протокола предназначены для использования программно (есть привязки для C++, java, python ...), поэтому они могут не подходить для вашей цели.

Answer 4

Я думаю, Clearsilver - очень хорошая альтернатива. У них даже есть сравнения страницы here и список projects, которые используют его

Answer 5

Джефф написал об этом here и here. Это должно помочь вам начать работу.

Answer 6

Вы требования немного невозможны .. Вы хотите что-то близкое к XML, но, вероятно, отклоните, вероятно, ближайший эквивалент, который не имеет угловой скобки (YAML).

Насколько мне это не нравится, почему бы просто не использовать XML? Вы не должны когда-либо читать XML (за исключением отладки, я полагаю), в нем есть абсурдное количество инструментов.

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

JSON, вероятно, примерно эквивалентен, но он в значительной степени нечитабелен. Но опять-таки вам никогда не придется читать его (загружать его на любой язык, который вы используете, и его следует преобразовать в собственные массивы/dicts/переменные/все).

О, я нахожу JSON гораздо приятнее разобрать, чем XML: Я использовал его в JavaScript, и модуль simplejson Python - около одной команды, и это хорошо преобразуется в родной Dict Python или объект Javascript (таким образом, имя!)

Answer 7

Если у вас аллергия на угловые кронштейны, то JSON, HDF (ClearSilver) и OGDL являются единственными, кого я знаю из рук вон.

После немного прибегая к помощи, я нашел список альтернатив здесь:
http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html

Answer 8

AFAIK, JSON и YAML точно эквивалентны с точки зрения структуры данных. У YAML просто меньше скобок и цитат и прочее. Поэтому я не вижу, как вы отвергаете одного и сохраняете другого.

Кроме того, я не вижу, как угловые скобки XML менее «понятны для человека», чем квадратные скобки JSON, фигурные скобки и кавычки.

Answer 9

Я нашел S-Expressions, чтобы быть отличным способом представления структурированных данных. Это очень простой формат, который легко создавать и анализировать. Он не поддерживает атрибуты, но, как YAML & JSON, он не нужен. Атрибуты - это просто способ для XML ограничить многословие. Более простые, чистые форматы просто им не нужны.

Answer 10

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

Анализ структуры дерева может быть не таким приятным, если сравнивать с парами ключ-значение, например. хэш-таблицы. Если экземпляр хэш-таблицы удовлетворяет требованию, чтобы все его ключи были строками, а все его значения были строками, то относительно небезопасно реализовать hashtable2string() и string2hashtable().

Я использую хэш-таблицы сериализации в AJAX между PHP и JavaScript, и формат, который я разработал, называется ProgFTE (программатор Дружественный текст Exchange) и описан в:

http://martin.softf1.com/g/n//a2/doc/progfte/index.html

можно найти версию рубина реализации ProgFTE в рамках рубиновой библиотеки Kibuvits: http://rubyforge.org/projects/kibuvits/

Answer 11

YAML чрезвычайно полнофункциональный и вообще люди-читаемый формат, но это ахиллесова залечить является сложностью, как показано на Rails против мы видели эту зиму. Из-за своей повсеместности в Ruby в качестве языка конфигурации Том Престон-Вернер из Github славы активизировал создание разумной альтернативы, получившей название TOML. Он получил массивную тягу сразу и имеет отличную поддержку инструмента. Я настоятельно рекомендую никому смотреть на YAML проверить это:

https://github.com/mojombo/toml

Answer 12

Для хранения кода типа данных, 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 предназначена для C#. В настоящее время известно, что только одно приложение использует LES: LLLPG. Он поддерживает «атрибуты», но они похожи на атрибуты C# или аннотации Java, а не на атрибуты XML.

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

body { 
    '''Click here to use the World's ''' 
    a href="http://google.com" { 
     strong "most popular"; " search engine!" 
    }; 
}; 

point = (2, -3); 
tasteMap = { "lemon" -> sour; "sugar" -> sweet; "grape" -> yummy }; 

Answer 13

Существует 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) 
    } 
} 

Существует доступна питон библиотека pyaxon Теперь.

Answer 14

TL; DR

Пролог не был упомянут здесь, но это лучший формат я знаю для представления данных. Программы Prolog, по сути, описывают базы данных со сложными отношениями между сущностями. Пролог мертв - просто разобрать, чей, вероятно, только соперник - это S-выражения в этом домене.

Полная версия

Программисты часто "забывают", что XML на самом деле состоит из. Обычно речь идет о очень маленьком подмножестве того, что есть.XML - очень сложный формат, по крайней мере, эти части: DTD schema language, XSD schema language, XSLT transformation language, RNG schema language и XPath (плюс XQuery) языки - все они являются неотъемлемой частью стандарта XML. Кроме того, есть некоторые апокрифы, такие как E4X. У каждого из них есть свои версии, довольно много совпадений, несовместимости и т. Д. Очень мало парсеров XML в дикой природе реализуют все из них. Не говоря уже о многочисленных причудах и ошибках популярных анализов, некоторые из которых приводят к заметным проблемам безопасности, таким как https://en.wikipedia.org/wiki/XML_external_entity_attack.

Поэтому, ища XML альтернатива - не очень хорошая идея. Вероятно, вы вообще не хотите иметь дело с подобными XML.

YAML, возможно, второй худший вариант. Он не такой большой, как XML, но он также был разработан для того, чтобы охватить все базы ... более десяти раз каждый ... по-разному и уникальным, о которых никто никогда не мог себе представить. Я еще не слышал о правильно работающем парсере YAML. Ruby, язык, который использует YAML много, был классно screwed up из-за этого. Все партизаны YAML, которые я видел на сегодняшний день, являются копиями libyaml, которые сами по себе представляют собой написанный вручную (не сгенерированный из формального описания) парсер с кодом, который очень сложно проверить на правильность (функции, которые охватывают сотни линий со свернутым управляющим потоком). Как уже упоминалось, он полностью содержит JSON в нем ... помимо нескольких методов кодирования Unicode ... внутри того же документа и, вероятно, множество других вещей, о которых вы не хотите слышать.

JSON, с другой стороны, совершенно не похож на другие два. Вероятно, вы можете написать парсер JSON, ожидая загрузки артефакта парсера JSON с вашего Maven Nexus. Это может сделать очень мало, но, по крайней мере, вы знаете, на что он способен. Без сюрпризов. (За исключением некоторых расхождений, связанных с символом, ускоряющимся в строках и удвоением кодирования). Никаких скрытых подвигов. Вы не можете писать в нем комментарии. Многострочные строки выглядят плохо. Независимо от того, что вы подразумеваете под различием свойств и атрибутов, вы можете реализовать более вложенные словари.

Предположим, хотя вы хотели, чтобы правильно испортить XML ... ну, тогда популярный материал, такой как YAML или JSON, не сделает этого. Каким-то образом мода и рациональное мышление расстались в программировании в середине семидесятых. Итак, вам нужно будет вернуться туда, где все началось с Маккарти, Хоара, Кодда и Ковальского, выяснить, что вы пытаетесь представить, а затем посмотреть, какая техника наилучшего представления есть для всего, что вы есть пытаясь представить :)