В описании использованы следующие термины и сокращения,

JavaScript— мультипарадигменный язык программирования.

JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. В данном документе используется версия JSON по стандарту RFC 7159.

JSON Schema— один из языков описания структуры JSON-документа. В данном документе используется версия JSON Schema Draft 6.

Kwalify— это синтаксический анализатор, валидатор схемы и инструмент привязки данных для YAML и JSON. В данном документе используется версия Kwalify 0.7.2.

XML (англ. extensible Markup Language)— расширяемый язык разметки. В данном документе используется версия XML 1.0.

XSD (XML Schema)— язык описания структуры XML-документа. В данном документе используется версия XSD 1.0.

YAML (рекурсивный акроним англ. «Yet Another Markup Language»— «Ещё один язык разметки», позже— англ. «YAML Ain't Markup Language»— «YAML— не язык разметки») — «дружественный» формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования. В данном документе используется версия YAML 1.1.

Сложный (структурированный, составной) тип — тип данных, объекты (переменные или постоянные) которого имеют внутреннюю структуру, доступную программисту.

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

Известны несколько языков для описания составных типов данных. Самые популярные из них: XSD, JSON-Schema, Kwalify.

Наиболее близким аналогом заявляемого изобретения является техническое решение из патентной заявки US 20140067866. В способе определяют, соответствует ли объект, указанный в JavaScript (JSON) объектной нотации, схеме JSON, при этом схема содержит объект, содержащий свойства, содержащие массив из одной или нескольких пар значений имени.

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

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

Между тем, последние несколько лет в мире наблюдаются тенденции к использованию достаточно простых структур данных в информационных системах. Чем проще структуры, тем проще вникать разработчикам в программы, тем проще искать ошибки. Этим, кстати, обусловлена возросшая популярность языка JSON по сравнению с языком XML. Язык JSON менее гибкий, чем XML, зато гораздо более наглядный.

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

Техническим результатом заявляемого изобретения является упрощение и сокращение времени на разработку описания составного типа данных при повышении удобства пользования за счёт повышения эффективности восприятия разработчиками. Указанный технический результат достигается за счёт того, что в способе описания составного типа данных для минимального описания составного типа данных используют пример данных этого типа, отдельно определяют правила интерпретации присутствия или отсутствия элемента примера данных этого типа 5 в описании составного типа данных, определяют правила внедрения расширений описания типа данных в описание составного типа данных, осуществляют расширение минимального описания составного типа данных за счёт внедрения в минимальное описание составного типа данных дополнительных элементов по определённым ранее правилам внедрения расширений описания типа данных в ю описание составного типа данных и определяют правила интерпретации расширений описания составного типа данных.

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

В способе могут отображать сообщения об ошибках в проверяемых данных 15 и/или советы по устранению ошибок в проверяемых данных.

В способе могут создавать электронную документацию на составной тип данных.

В способе могут визуально выделять синтаксические конструкции описания составного типа данных.

20 В способе могут генерировать пример типа данных на основе описания составного типа данных.

Ядром для описания составного типа данных является пример данных этого типа, т.е. в предельном случае пример типа данных сам по себе является минимальным описанием этого типа данных. Дополнительные уточняющие 25 описания типа данных вводят в этот же самый пример с помощью служебных полей.

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

35 интуитивно усваивает структуру этого типа данных, при дальнейшем анализе описательных служебных полей он быстро усваивает особенности типа данных. Описание типа данных легко преобразовать в валидный пример типа данных, который может быть использован в разработке. Для этого достаточно удалить из описания типа данных служебные поля. Визуальное выделение синтаксических конструкций в текстовом редакторе позволяет значительно ускорить процесс усвоения типа данных разработчиком, например, поля примера данных можно подсветить, а служебные поля затушевать.

Изобретение особенно полезно при разработке следующих типов вычислительных систем: распределенных сетевых приложений и систем хранения данных.

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

Способ осуществляют следующим образом.

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

Основанием для этого является тот факт, что пример данных какого-то типа очевидным образом так или иначе описывает этот тип данных. Например, следующие данные (на языке JSON):

{

"name": "Петров Иван",

"salary": 200.0

}

очевидным образом говорят о том, что соответствующий тип данных содержит поле "name" типа string и поле "salary" типа number.

Затем отдельно определяют правила интерпретации присутствия или отсутствия элемента примера данных этого типа в описании составного типа данных. Например, правило интерпретации присутствия может звучать так: «Если в примере данных присутствует некоторое поле некоторого типа, то это следует интерпретировать так, что в описываемом типе данных это поле не является обязательным, но если это поле присутствует, то тип этого поля должен строго соответствовать типу этого поля в примере данных». Правило интерпретации отсутствия может звучать так: «Если в примере данных отсутствует некоторое поле некоторого типа, то такое поле не может присутствовать в данных описываемого типа данных». Применяя описанные правила к вышеприведенному примеру, можно сказать про этот тип данных следующее: «Данные описанного типа данных «могут» содержать поле «пате» типа string, также они «могут» содержать поле «salary» типа number. Других полей данные этого типа данных содержать не могут». Эти правила могут быть сформулированы несколько иначе, в зависимости от реализации конкретного языка описания типа данных.

Определяют правила внедрения расширений описания типа данных в описание составного типа данных путем введения служебных полей, снабжённых условными обозначениями.

Осуществляют расширение минимального описания составного типа данных за счёт внедрения в минимальное описание составного типа данных дополнительных элементов по уже определённым правилам внедрения расширений описания типа данных в описание составного типа данных.

Ввиду того, что пример данных описывает не все характеристики соответствующего типа данных, заявляемый способ предполагает введение в пример данных уточняющих служебных полей, которые отличаются от полей примера данных специальным условленным обозначением. Например, если необходимо в приведенном примере указать, что поле "name" является обязательным, то пишут так:

{

"name": "Петров Иван",

"salary": 200.0,

"@@required": ["name"]

}

В данном примере поле "@@required" является служебным и предназначено для указания полей, которые являются обязательными в данном типе данных.

Подобным образом можно вводить в описание типа данных любое количество служебных полей, которые будут отражать разнообразные характеристики описываемого типа данных. В данном примере поле "@@required" начинается с двух символов "@@", что обозначает, что это поле является служебным.

Служебные описательные поля в заявляемом способе могут описывать: тип данных поля, например, «строка» или «логический» или «любой тип»; ограничения на значение поля, например, «целое в диапазоне от 0 до 100» или «длина строки не более 100 символов»;

обязательность поля;

варианты типов данных значения поля, если значение поля может быть представлено данными разных типов;

любые другие правила, которым должны соответствовать данные указанного типа;

текстовый комментарий к полю;

текстовый комментарий ко всему типу данных;

· любые другие способы документирования типа данных.

В описаниях полей могут быть использованы вычисляемые выражения.

После определяют правила интерпретации расширений описания составного типа данных. Например, одно из правил может звучать так: «Расширение описания служебного типа данных, которое вводится служебным полем "@@required", содержащим в качестве значения массив элементов типа string, следует интерпретировать следующим образом: все поля описываемого типа данных, имена которых совпадают с одной из строк массива строк поля "@@required", являются обязательными в описываемом типе данных».

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

Для удобства пользования на основе правил интерпретации присутствия или отсутствия элемента примера данных этого типа в описании составного типа данных, правил внедрения расширений описания и правил интерпретации б расширений описания создают электронную документацию на составной тип данных.

Примеры реализации.

На примере типа данных на языке JSON

{

"name": "John"

} Об этом типе данных можно сказать, что корневой элемент этого типа данных может быть объектом, в состав которого может входить поле name, которое может иметь тип строки.

Несмотря на то, что в приведённом выше описании несколько раз используется слово «может», этого описания уже достаточно для того, чтобы программист быстро «освоил» структуру этого типа данных.

Если дополнительно условиться о том, что элементы структуры данных не могут иметь разный тип в разных экземплярах этого типа данных, то об указанном примере можно сказать еще более определенно, что корневой элемент имеет тип «объект», в который может входить элемент «пате» типа «строка».

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

Описание того же самого типа данных на языке JSON-Schema выглядит так:

{

"type": "object",

"properties": {

"name": {

"type": "string"

}

}

} Это описание намного сложнее для восприятия человеком и не содержит в себе примеров данных этого типа.

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

Например, автор описания типа данных может пожелать указать, что элемент «пате» в приведенном примере является обязательным элементом корневого объекта.

Это пожелание нетрудно воплотить, если ввести в описание типа данных служебное поле "@@required" следующим образом:

{

"name": "John",

"@@required": ["name"]

}

В этом примере условлено, что элементы, имя которых начинается с символов "@@", являются «служебными» или «описательными» элементами. Понимая это условие, любой программист средней квалификации быстро сможет «расшифровать» данную запись: корневой элемент имеет тип «объект», в который обязательно должен входить элемент «пате» типа «строка».

Если автор описания типа данных хочет указать, что поле «пате» должно быть не длиннее 20 символов, то это может быть, например, решено так:

{

"name": "John", "@name": {"maxLength": 20},

"@@required": ["name"] В этом примере условлено, что элементы, имя которых начинается с символа «@», предназначены для того, чтобы описывать типы данных элементов того же уровня вложенности. Таким образом, элемент «@пагле» описывает элемент «пате».

ЭТОТ пример программист интуитивно расшифрует так: корневой элемент имеет тип «объект», в который должен входить элемент «пате» типа «строка», длиной не более 20 символов.

Таким же образом можно дополнить пример множеством других дополнительных описаний, которые используются в типе данных. Например, довольно сложный тип данных карточки работника может быть описан так:

"login": "lapkina",

"name": "Лапкина",

"email": "email@yandex.ru",

"salary": 12.5,

"isActive": true,

"roles": [

"manager",

"admin"

].

"birthday": "1990-02-23",

"address": {

"country": "Russia",

"zipcode": "123434",

"addressl": "pr. M. Bluhera, 31-24",

"address2": "",

"@zipcode": {

"regex": "\\d+",

"doc": "Address zipcode.",

"message": "One or more digits required."

},

"@@required": ["country", "addressl"] }.

"created" : "2015-05-31 TOO : 00 : 00Z" ,

"©login": {

"regex": "[A-Za-z1-9]+"

>.

"@name": {

"regex": "[ ^A \\t]"

}-

"@email": {

"type": "email"

}.

"©salary": {

"min": 10,

"max": 2000

}>

"@roles": {

"type": "array",

"enum": [

"manager",

"admin",

"superadmin"

].

"min": 1 ,

"max": 5

}.

"©birthday": {

"type": "date"

},

"©address": {

"default": {}

},

"©created": {

"type": "datetime"

}- "@@required": ["email", "salary", "login"]

}

Несмотря на то, что этот тип данных имеет достаточно сложную структуру, если программист знаком с описанными нами ранее правилами, то «усвоение» этого типа данных все равно происходит достаточно легко и может занять у него 1-2 минуты.

Та же самая структура данных на языке JSON-Schema будет описана так:

type": "object",

properties": {

"login": {

"type": "string",

"pattern": "[A-Za-z1-9]+"

},

"name": {

"type": "string",

"pattern": "[ ^A \\t]"

}>

"salary": {

"type": "number",

"minimum": 10,

"maximum": 2000

},

"isActive": {

"type": "boolean"

},

"roles": {

"type": "array",

"items": {

"enum": ["manager", "admin", "superadmin"],

"minimum": 1 ,

"maximum": 5

}

и },

"birthday": {

"type": "string",

"format": "date"

},

"address": {

"type": "object",

"properties": {

"country": {

"type": "string"

},

"zipcode": {

"type": "string",

"pattern": "\\d+",

"description": "Address zipcode.",

"message": "One or more digits required."

}.

"addressl": {

"type": "string"

},

"address2": {

"type": "string"

}

}.

"required": ["country", "addressl "],

"default": {}

},

"created": {

"type": "string",

"format": "date-time"

}

}.

"required": ["email", "salary", "login"] Вариант с использованием JSON-Schema читается сложнее и не содержит в себе примера использования.

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

ю

Поля с вариантами типа данных.

Ниже показан тип данных «геометрическая фигура». Этот тип данных содержит в себе поле «type» - тип фигуры и «size» - размер фигуры, причем структура поля «размер фигуры» зависит от типа фигуры. Например, если фигура 15 — прямоугольник, то пример данных может выглядеть так:

{

"type" : "rectangle",

"size" : {

20 "width" : 10,

"height" : 20

}

}

25 Если же фигура— круг, то пример данных будет выглядеть несколько иначе:

{

"type" : "circle",

зо "size" : {

"radius" : 35

}

} Видно, что внутренняя структура поля «size» может изменяться и при этом может принимать один из нескольких видов.

Для того, чтобы описать такое поведение поля «size», вводят служебное поле «@@сазе@[имя варианта]» для описания варианта типа данных родительского элемента. В этом случае получают такое описание типа данных «геометрическая фигура»:

{

"type" : "circle",

"size" : {

"@@case@circle" : {

"radius" : 35,

"@@required" : ["radius"]

},

"@@case@square" : {

"width" : 10,

"height" : 20,

"©©required" : ["width", "height"]

}

}.

"©©required" : ["type", "size"]

}

Вычисляемые выражения.

Показан тип данных «девушка», у которого есть три поля: «isBeautiful» (красивая), «isMarried» (замужем) и «phoneNumber» (телефонный номер). При этом поля «isBeautiful» и «isMarried» всегда обязательные, а поле «phoneNumber» обязательно только в том случае, если девушка красивая и не замужем. Это означает, что обязательность поля «phoneNumber» зависит от конкретных значений в полях «isBeautiful» и «isMarried». В этом случае для описания типа данных можно использовать так называемые «вычисляемые выражения», которые позволяют вычислять те или иные значения в зависимости от конкретных значений полей и от других параметров контекста, например, текущее время, суммарный размер данных в байтах и др. Пример использования вычисляемых выражений в описании типа данных «девушка» выглядит так: {

"isBeauitiful" : true,

"isMarried" : false,

"phoneNumber" : "+79043378139", "@isBeautiful" : {"required" : true},

"@isMarried" : {"required" : true},

"@phoneNumber" {"required" "this.isBeautiful && ! this. isMarried"}

}

В данном примере использовано вычисляемое выражение «this.isBeautiful && ! this. isMarried » для вычисления обязательности поля «phoneNumber». Это выражение записано в синтаксисе языка JavaScript и обозначает логическое выражение: «красивая И НЕ женатая». Синтаксис языка выражений не имеет решающего значения — можно использовать любой подходящий синтаксис. Выражение может возвращать данные любого допустимого типа, а также может содержать внутри себя операнды и функции для работы с любыми типами данных: строки, числа, объекты, массивы и т. д. Экранирование символов, обозначающие служебные поля.

При использовании заявляемого способа описания составных типов данных может возникнуть ситуация, при которой тип данных содержит поле, название которого соответствует принятому в данном языке обозначению служебных полей. Чтобы отличить это поле от служебного, используют технологию «экранирования» символов. Например, можно условиться, что начальный символ строки «@», который используется в указанных примерах для обозначения служебных полей можно экранировать символом «!». То есть последовательность символов «!@» в начале названия поля будет означать, что это не служебное поле, а обычное поле, которое начинается с символа «@». Например, если требуется в тип данных ввести поле «@name», то оно будет выглядеть так: «!@name». И тогда все описание типа данных может выглядеть так:

Jname" : "Николай"

Подобным способом можно экранировать и сам начальный символ «!», который в данном случае тоже стал служебным. То есть, например, если хотят ввести в тип данных поле с названием «!@name», то в описании типа данных нужно экранировать первый символ «!», таким образом получают:

"!!@name" : "Николай"

}

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

Пример в формате XML.

Пример типа данных «Сотрудник» выглядит так:

<?xml version="1.0" encoding="UTF-8"?>

<user login="lapkina">

<пате>Лапкина</пате>

<email>email@yandex.ru</email>

<salary>12.5</salary>

<isActive>true</isActive>

<roles>

<role>manager</role>

<role>admin</role>

</roles>

<birthday>1990-05-14</birthday>

<address> <country>Russia</country>

<zipcode>123434</zipcode>

<address1 >pr. M. Kazakova, 31-24</address1>

<address2 />

</address>

<created>2015-02-13T12:34:23Z</created>

</user>

На языке XSD схема для такого XML документа может выглядеть так:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:vc='^ttp://www.w3.org/2007/XMLSchema-versioning ^,, >

<xs:element name="user">

<xs:complexType>

<xs:sequence>

<xs:element type="xs:string" name="name'7>

<xs:element type="email" name="email"/>

<xs:element type="xs:float" name="salary"/>

<xs:element type="xs:boolean" name="isActive"/>

<xs:element name="roles">

<xs:complexType>

<xs:sequence>

<xs:element type="xs:string" name="role" maxOccurs="unbounded" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element type="xs: string" name="birthday"/>

<xs:element name="address">

<xs:complexType>

<xs:sequence>

<xs:element type="xs:string" name="country"/>

<xs:element type="xs:int" name="zipcode"/> <xs:element type="xs:string" name="address1"/>

<xs:element type="xs:string" name="address2"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element type="xs:dateTime" name="created"/>

</xs:sequence>

<xs:attribute type="login" name- 1ogin"/>

</xs : com plexType>

</xs:element>

<xs:simpleType name="login">

<xs: restriction base="xs:string">

<xs:pattern value="[A-Za-z1 -9]+"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="name">

<xs: restriction base="xs:string">

<xs:pattern value="[ ^A \\t]"/>

</xs: restriction >

</xs:simpleType>

<xs:simpleType name="email">

<xs: restriction base="xs:string">

<xs:pattern value="[ ^A @]+@[ ^A \.]+\..+'7>

</xs:restriction>

</xs:simpleType>

</xs:schema>

Применяя заявляемый способ, описание типа данных «Сотрудник» может выглядеть, например, так:

<?xml version="1.0" encoding="UTF-8"?>

<user login="lapkina">

<пате>Лапкина</пате>

<email>email@yandex.ru</email>

<salary>12.5</salary> <isActive>true</isActive>

<roles>

<role>manager</role>

<role>admin</role>

</roles>

<birthday>1990-05-14</birthday>

<address>

<country>Russia</country>

<zipcode> 123434 </zipcode>

<address1 >pr. M. Kazakova, 31-24</address1 >

<address2 />

</address>

<created>2015-02-13T12:34:23Z</created>

<_login regex="[A-Za-z1-9]+" />

<_name regex="[ ^A \\t]" />

<_email type="email" />

<_salary min="123" max="200" />

<_roles type="array" min="1" max="5">

<enum>

<item>manager</item>

< item >ad m i n </item >

<item>superadmin</item> </enum>

</_roles>

<_birthday type="date" />

<_address>

<default>

</default>

</_address>

<_created type="datetime" />

< required>

<item>email</item>

<item>salary</item> <item>login</item>

</ required>

</user>

В этом примере для обозначения служебных полей в качестве служебного символа используется символ «_», так как спецификация языка XML не позволяет использовать в начале названия элемента символ «@».

Очевидно, что схема документа на языке XSD воспринимается значительно сложнее, чем описание типа данных с применением заявляемого способа.

Этот пример наглядно показывает, что описанная нами методика демонстрирует свои описанные выше преимущества в том числе и на языке XML.

Ниже показано применение заявляемого способа к формату YAML. Пример типа данных «Сотрудник» выглядит следующим образом: login: lapkina

name: Лапкина

email: email@yandex.ru

salary: 12.1

isActive: true

roles: [manager, admin]

birthday: 1990-05-12

address:

country: Russia

zipcode: "123434"

addressl : "pr. M. Bluhera, 31-24"

address2: ""

created: 2015-05-12T12:34:23.003+04:21

На языке Kwalify схема для такого XML документа может выглядеть так: type: map

mapping:

login:

type: str pattern: /[A-Za-z1-9]+/ required: yes

name:

type: str

required: yes

email:

type: str

pattern: /@/

required: yes

salary:

type: number

range: {min: 10, max: 2000}

required: yes

isActive:

type: bool

roles:

type: seq

sequence:

- type: str

enum: [manager, admin, superadmin] birthday:

type: date

address:

type: map

mapping:

country:

type: str

required: yes

zipcode:

type: str

pattern: Ad+/

addressl :

type: str

required: yes

address2: type: str

created:

type: timestamp

Применяя заявляемый способ, описание типа данных «Сотрудн выглядеть, например, так: login: lapkina

name: Лапкина

email: email@yandex.ru

salary: 12.5

isActive: true

roles: [manager, admin]

birthday: 1990-05-12

address:

country: Russia

zipcode: 23434"

addressl : "pr. M. Bluhera, 31-24"

address2: ""

_zipcode":

regex: "\\d+"

doc: "Address zipcode."

message: "One or more digits required."

required: [country, addressl] created: 2015-05-12T12:34:23.003+04:21

Jogin:

regex: ⁿ [A-Za-z1-9]+"

_email:

type: email

_salary: {min: 10, max: 2000}

_roles:

type: array enum: [manager, admin, superadmin]

min: 1

max: 5

_birthday:

type: date

_created:

type: datetime required: [email, salary, login]

В этом примере для обозначения служебных полей в качестве служебного символа используется символ «_», так как спецификация языка YAML не позволяет использовать в начале названия элемента символ «@».

Очевидно, что схема документа на языке Kwalify воспринимается значительно сложнее, чем описание типа данных с применением нашей методики.

Этот пример наглядно показывает, что описанная нами методика демонстрирует свои описанные выше преимущества в том числе и на языке YAML.

Таким образом, в качестве языка описания типа данных за основу берут тот же язык, на котором будут формироваться данные указанного типа данных. Например, для данных типа JSON описание будет создаваться на языке JSON. Это требование не является обязательным, но при выполнении этого требования, разработчик получает дополнительные удобства при работе с описанием типа данных и примерами данных этого типа, когда они составлены на одном языке.

Минимальное описание типа данных в точности соответствует примеру данных этого типа.

Расширение описания типа данных осуществляют за счёт внедрения в минимальное описание типа данных дополнительных элементов по определённым заранее условленным правилам написания расширений описания типа данных.

Правила написания расширений описания типа данных должны удовлетворять следующим условиям:

- элементы расширений должны легко визуально отличаться от элементов, относящихся к минимальному описанию типа данных (в данном примере для JSON они все начинаются с символа «@»); - элементы расширений должны вводиться таким образом, чтобы можно было визуально легко определить, к какому элементу минимального описания типа данных они относятся, в данном примере, они имеют тот же уровень вложенности и имеют похожее имя, например, элемент расширения «@login» относится к элементу «login».

Заявляемый способ описания типов данных обладает теми же возможностями, что и традиционные методики описания типов данных, такие как JSON-Schema, XSD, Kwalify и др.

Заявляемый способ описания типов данных легко создается человеком и быстро воспринимается человеком.

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

Эти преимущества достигаются за счёт того, что основой для описания типа данных является пример данных этого типа, что позволяет быстро создавать основу для описания типа данных, а также позволяет легко усваивать структуру типа данных; а расширения описания типа данных не уменьшают преимущества, указанного в предыдущем пункте, так как эти расширения визуально отделены от «примера».

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

Приведённые примеры являются частными случаями и не исчерпывают всех возможных реализаций заявляемого изобретения.

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