Как описать данные JSON в спецификации?

Question

Каков наилучший способ описания данных JSON в спецификации?

В прошлом я использовал примеры с «многословными» описаниями, но это кажется неточным.

Кажется, есть зарождающаяся схема JSON стандарт, но он не выглядит как чрезвычайно активный проект. Есть ли другие способы?

---

( Обновление ) Подумав об этом в течение нескольких дней, мне нравится предложение bmargulies об использовании соглашения о конвертации. Поскольку в этом случае JSON документирует выход из веб-сервисов .NET, я собираюсь просто задокументировать схему с синтаксисом класса C #. Это может быть не совсем сложно, но все участники поймут это и вместе с примерами расскажут сообщение как можно быстрее.

Answer 1

Я бы порекомендовал мою js-схему библиотеку JavaScript. Основная мотивация была та же, что вы описали в вопросе. Это простая и понятная нотация для описания схем JSON (или спецификации, если хотите).

Пример схемы, описанной в схеме JSON:

{
  "type":"object",
  "properties":{
    "id":{
      "type":"number",
      "required":true
    },
    "name":{
      "type":"string",
      "required":true
    },
    "price":{
      "type": "number",
      "minimum":0,
      "required":true
    },
    "tags":{
      "type":"array",
      "items":{
        "type":"string"
      }
    }
  }
}

и то же описание схемы с js-схемой:

{
  "id"    : Number,
  "name"  : String,
  "price" : Number.min(0),
  "?tags" : Array.of(String)
}

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

Answer 2

Я знаю, что это старый вопрос, но он может быть полезен кому-то еще: При поиске методов описания JSON-данных я наткнулся на Orderly . Вот абстрактное право на первой странице:

Упорядоченный текстовый формат для описания JSON. Упорядоченный может быть скомпилирован в JSONSchema. Это разработано, чтобы быть легким читать и писать.

Я могу согласиться с этим, но я пока пробовал это только с относительно простыми структурами.

Answer 3

Как насчет использования какого-нибудь расширенного BNF?

PERSON <- { "firstname": FIRSTNAMES, "lastname": LASTNAME, "age": AGE, "version": VERSION, "parents" <- PARENTS }

FIRSTNAMES <- [ FIRSTNAME+ ]

FIRSTNAME <- STRING

LASTNAME <- STRING

PARENTS <- [ PERSON{0,2} ]

AGE <- INTEGER

VERSION <- 1 | 2

Вам нужно будет определить значение атомарных описаний типов, таких как INTEGER и STRING где-нибудь.Если бы вы хотели добавить не жестко закодированные ключи для словарей, вы бы определили это следующим образом:

BREADLOOKUP <- { (TYPE : HOWMANY)+ }

TYPE <- "white" | "dark" | "french" | "croissant"

HOWMANY <- POSITIVE-INTEGER

Это позволило бы такие вещи, как

{ "white": 5, 
  "french": 2
}

, поскольку и регулярные выражения, и BNF довольноХорошо известно, что это может быть простой путь.?, +, *, {n}, {min,max} были бы простыми способами указать количество элементов (взятых из регулярных выражений), а остальное - в значительной степени чистый BNF.

ЕслиВы сделали это достаточно строго, это может даже быть разборчивым для валидатора.

Answer 4

Вы можете объединить XML-схему W3C или менее уродливую схему, например RelaxNG, с соглашениями о преобразовании.