Альтернативы JSON (с целью указания конфигурации)?

Мне нравится json как формат файлов конфигурации для программного обеспечения, которое я пишу. Мне нравится, что он легкий, простой и широко поддерживается. Тем не менее, я обнаружил, что есть некоторые вещи, которые мне очень нравятся в json, которых у него нет.

Json не имеет многострочных строк или здесь документов (http://en.wikipedia.org/wiki/Here_document), и это часто очень неудобно, когда вы хотите, чтобы ваш json файл быть удобочитаемым и доступным для человека. Вы можете использовать массивы строк, но это kludgy обходной путь.

Json не дает комментариев.

Если вы посмотрите на форматы файлов конфигурации unix, вы увидите, что многие люди разрабатывают свои собственные неудобные форматы для вещей, которые действительно имеют смысл делать с использованием какой-то вещи общего назначения. Например, здесь некоторый код из конфигурационного файла Apache:

RewriteEngine on
RewriteBase /temp
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0
RewriteCond %{REQUEST_URI} \.html
RewriteCond %{THE_REQUEST} HTTP/1\.1
RewriteRule t\.html t.xhtml [T=application/xhtml+xml]

По существу, здесь происходит то, что они изобрели чрезвычайно болезненный способ написания булевой функции f (w, x, y, z) = w &! x & y & z. Вам нужен логический "или"? У них тоже есть отдельный (уродливый) механизм.

То, что это, похоже, указывает на какой-то язык описания данных, который прост и Turing-неполный, но еще более выразительный, гибкий и удобный, чем json. Кто-нибудь знает о таком языке?

По моему мнению, XML слишком сложный, а выражения lisp имеют неправильные функции (Turing-полнота) и не имеют правильных функций (здесь документы, выразительный синтаксис).

[EDIT] Название вводит в заблуждение. Меня не интересует буквально следующая итерация json. Меня не интересуют языки, которые являются подмножеством javascript. Меня интересуют альтернативные языки описания данных.

ОТВЕТЫ

Ответ 1

Формат EDN - это один из вариантов, основанный на литералах Clojure. Это почти надмножество JSON, за исключением того, что никакой специальный символ не разделяет ключи и значения на картах (как : делает в JSON); скорее, все элементы разделяются пробелами и/или запятой, а карта кодируется как список с четным числом элементов, заключенным в {..}.

EDN допускает комментарии (к новой строке с использованием ; или к концу следующего элемента, считанного с помощью #_), но не здесь-docs. Он доступен для новых типов с использованием нотации тегов:

#myapp/Person {:first "Fred" :last "Mertz"}

Аргумент тега myapp/Person (т.е. {:first "Fred" :last "Mertz"}) должен быть допустимым выражением EDN, что делает его нерастяжимым для поддержки here-doc.

Он имеет два встроенных тега: #inst для временных меток и #uuid. Он также поддерживает типы имен символов (например, идентификатор) и ключевого слова (например, ключей); он выделяет списки (..) и векторы [..]. Элемент любого типа может использоваться как ключ на карте.

В контексте вашей проблемы вы можете придумать тег #apache/rule-or, который принимает последовательность элементов, семантика которых я оставляю вам!

Ответ 2

Посмотрите http://igagis.github.io/stob/

Это еще проще, чем JSON.

Он имеет комментарии к стилю С++.

Можно форматировать многострочные строки и использовать экранированные строки \n и tab\t, если нужна настоящая новая строка или вкладка.

Вот пример фрагмента:

"String object"
AnotherStringObject
"String with children"{
    "child 1"
    Child2
    "child three"{
        SubChild1
        "Subchild two"

        Property1 {Value1}
        "Property two" {"Value 2"}
        //comment

        /* multi-line
           comment */

        "multi-line
         string"

        "Escape sequences \" \n \r \t \\"
    }

R"qwerty(
This is a
raw string, "Hello world!"
int main(argc, argv){
    int a = 10;
    printf("Hello %d", a);
}
)qwerty"
}

Ответ 3

Всегда есть то, что мне нравится называть "настоящим JSON". JSON обозначает JavaScript Object Notation, и JavaScript имеет комментарии и что-то достаточно близко к heredocs.

Для heredoc вы должны использовать встроенный XML JavaScript E4X:

{
    longString: <>
                Hello, world!
                This is a long string made possible with the magic of E4X.
                Implementing a parser isn't so difficult.
                </>.toString() // And a comment
    /* And another
       comment */
}

Вы можете использовать Firefox JavaScript engine (FF - единственный браузер для поддержки E4X в настоящее время), или вы можете реализовать свой собственный синтаксический анализатор, что действительно не так сложно.

Здесь также находится руководство по быстрому старту E4X.

Ответ 4

"J" в JSON - "Javascript". Если какая-то конкретная конструкция синтаксиса отсутствует в Javascript, то она не будет на JSON.

Heredocs выходят за рамки JSON. Это синтаксис языка для упрощенного определения многострочной строки, но JSON - это транспортная нотация. Это не имеет ничего общего со строительством. Тем не менее, он имеет многострочные строки, просто используя \n символы новой строки в строках. В JSON ничего не сказано, что вы не можете иметь строку в строке. До тех пор, пока содержащиеся символы цитат верны, это совершенно верно. например.

{"x":"y\nz"}

является 100% законным действительным JSON и является многострочной строкой, тогда как

{"x":"y
z"}

не выполняется и не будет выполняться при разборе.

Ответ 5

Одним из важных атрибутов JSON (возможно, самым важным) является то, что вы легко можете "перевернуть" между строковым представлением и представлением в виде объекта, а объекты, используемые для представления объектной формы, - относительно простые массивы и карты. Именно это делает JSON настолько полезным в сетевом контексте.

Функции, которые вы хотите, будут противоречить этой двойной природе JSON.

Ответ 6

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

Ответ 7

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

Короткий пример (JSON5)

{
  // comments
  unquoted: 'and you can quote me on that',
  singleQuotes: 'I can use "double quotes" here',
  lineBreaks: "Look, Mom! \
No \\n's!",
  hexadecimal: 0xdecaf,
  leadingDecimalPoint: .8675309, andTrailing: 8675309.,
  positiveSign: +1,
  trailingComma: 'in objects', andIn: ['arrays',],
  "backwardsCompatible": "with JSON",
}

Формат обмена данными JSON5 (JSON5) - это расширенный набор JSON, который призван ослабить некоторые ограничения JSON, расширив его синтаксис, включив в него некоторые произведения из ECMAScript 5.1.

Краткое описание возможностей

Следующие функции ECMAScript 5.1, которые не поддерживаются в JSON, были расширены до JSON5.

Объекты

  • Ключи объекта могут быть ECMAScript 5.1 IdentifierName.
  • Объекты могут иметь одну запятую.

Массивы

  • Массивы могут иметь одну запятую.

Струны

  • Строки могут быть в одинарных кавычках.
  • Строки могут занимать несколько строк, экранируя символы новой строки.
  • Строки могут включать экранирование символов.

чисел

  • Числа могут быть шестнадцатеричными.
  • Числа могут иметь начальную или конечную десятичную точку.
  • Числа могут быть IEEE 754 положительной бесконечности, отрицательной бесконечности и NaN.
  • Числа могут начинаться с явного знака плюс.

Комментарии

  • Разрешены однострочные и многострочные комментарии.

Пустое пространство

  • Допускаются дополнительные символы пробела.

GitHub: https://github.com/json5/json5

Ответ 8

Есть также thindf.

Хотя он не поддерживает комментарии, их можно эмулировать с помощью пустых ключей:

config_var1 = value1
=some comment
config_var2 = value2