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

Question

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

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

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] 

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

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

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

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

Answer 1

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

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

{"x":"y\nz"} 

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

{"x":"y 
z"} 

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

Answer 2

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

Для Heredoc, вы будете использовать в JavaScript E4X встроенный XML:

{ 
    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 */ 
} 

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

Here's the E4X quickstart guide, too.

Answer 3

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

Answer 6

Посмотрите 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" 
}