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

StackOverflow https://stackoverflow.com/questions/51492

  •  09-06-2019
  •  | 
  •  

Вопрос

Для меня годный к употреблению Значит это:

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

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

Это было полезно?

Решение

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 полностью устраняет эту путаницу.

Другие советы

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

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

ТЛ;ДР

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

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

Программисты часто «забывают», из чего на самом деле состоит XML.Обычно относится к очень небольшому подмножеству того, что это такое.XML — очень сложный формат, состоящий как минимум из следующих частей: Язык схемы DTD, язык схемы XSD, Язык преобразования XSLT, язык схемы ГСЧ и XPath (плюс XQuery) — все они являются неотъемлемой частью стандарта XML.Плюс есть некоторые апокрифы типа E4X.У каждого из них есть свои версии, которые частично совпадают, несовместимы и т. д.Очень немногие синтаксические анализаторы XML реализуют все из них.Не говоря уже о многочисленных странностях и ошибках популярных анализаторов, некоторые из которых приводят к заметным проблемам безопасности, например https://en.wikipedia.org/wiki/XML_external_entity_attack .

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

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

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

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

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

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

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

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

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

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

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

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

Есть АКСОН которые охватывают лучшее из XML и JSON.Поясним это на нескольких примерах.

AXON можно рассматривать как более короткую форму данных XML.

XML

<person>
   <name>Frank Martin</name>
   <age>32</age>
 </person>

АКСОН

person{
  name{"Frank Martin"}
  age{32}}

или 

person
  name:
    "Frank Martin"
  age:
    32

XML

<person name="Frank Martin" age="32" />

АКСОН

person{name:"Frank Martin" age:32}

или 

person
  name: "Frank Martin"
  age: 32

AXON содержит некоторую форму JSON.

JSON

{"name":"Frank Martin" "age":32 "birth":"1965-12-24"}

АКСОН

{name:"Frank Martin" age:32 birth:1965-12-24}

AXON может представлять комбинацию данных типа XML и JSON.

АКСОН

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)
  }
}

или 

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 пиаксон сейчас.

Я думаю прозрачное серебро это очень хорошая альтернатива.У них даже есть страница сравнения. здесь и список проекты которые используют это

Для хранения кодоподобных данных ЛЕС (Синтаксис выражений Лойка) — многообещающая альтернатива.Я заметил, что многие люди используют 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: ЛЛЛПГ.Он поддерживает «атрибуты», но они похожи на атрибуты 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 };

Если у вас аллергия на угловые скобки, тогда JSON, ХДФ (Прозрачное серебро) и ОГДЛ единственные, кого я знаю навскидку.

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

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

https://github.com/mojombo/toml

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top