WO2019039958A1 - Method of describing a composite data type - Google Patents

Abstract

The invention relates to methods of processing data that is stored and transmitted in text format, and can be used for describing composite data types in information systems, which are stored or transmitted in text format, including XML, JSON, YAML. The technical result of the claimed invention is that of simplifying the description of a composite data type and reducing the development time thereof, while increasing ease of use by increasing intelligibility to developers. In a method of describing a composite data type an example of data of the type in question is used for a minimal description of the composite data type. Then rules for interpreting the presence or absence of an element of the example of data of the type in question in the description of the composite data type are defined separately. Rules for introducing expansions of the description of the data type into the description of the composite data type are defined. The minimal description of the composite data type is expanded by introducing additional elements into the minimal description of the composite data type according to the rules defined for introducing expansions of the description of the data type into the description of the composite data type, and rules for interpreting expansions of the description of the composite data type are defined.

Description

 METHOD FOR DESCRIPTION OF COMPOSITE TYPE OF DATA The invention relates to data processing methods that are stored and transmitted in text format, and can be used to describe composite data types in information systems, including XML, JSON, YAML.

 The following terms and abbreviations are used in the description.

 JavaScript is a multi-paradigm programming language.

 JSON (English JavaScript Object Notation) is a text-based data exchange format based on JavaScript. This document uses the JSON version of the RFC 7159 standard.

 JSON Schema is one of the languages for describing the structure of a JSON document. This document uses the JSON Schema Draft 6 version.

 Kwalify is a parser, schema validator, and data binding tool for YAML and JSON. This document uses version Kwalify 0.7.2.

 XML (English extensible Markup Language) is an extensible markup language. This document uses the XML version 1.0.

 XSD (XML Schema) is a language for describing the structure of an XML document. This document uses version XSD 1.0.

 YAML (a recursive acronym for English: “Yet Another Markup Language” - “Another Markup Language”, later - “YAML Ain't Markup Language” - “YAML — not a Markup Language”) is a “friendly” data serialization format conceptually similar to markup languages, but focused on the convenience of input-output typical data structures of many programming languages. This document uses version YAML 1.1.

 A complex (structured, composite) type is a data type whose objects (variable or constant) have an internal structure accessible to the programmer.

Currently, information technologies are widely used text formats for the transfer and storage of structured (composite) data, such as XML, JSON, YAML. When working with this data, it is constantly necessary to solve the following tasks: data validation (data verification for compliance with a particular type); automatic creation of documentation for data types and automatic generation of program code for working with a specific data type. To solve these problems it is necessary to formally describe the composite data types.

 Several languages are known for describing composite data types. The most popular of them: XSD, JSON-Schema, Kwalify.

 The closest analogue of the claimed invention is a technical solution from the patent application US 20140067866. The method determines whether the object specified in JavaScript (JSON) object notation corresponds to the JSON scheme, and the scheme contains an object containing properties containing an array of one or more pairs name values.

 However, for the above languages, descriptions of composite data types are rather cumbersome and relatively time consuming to develop. In addition, the resulting descriptions of composite data types are hard and slowly perceived by developers.

 The described drawbacks are due to the fact that these languages are focused on the description of complex data types. Therefore, they have great flexibility, as a result of which the syntax of these languages becomes too cumbersome.

 Meanwhile, the last few years in the world there are trends towards the use of fairly simple data structures in information systems. The simpler the structure, the easier it is for developers to delve into the program, the easier it is to look for errors. This, by the way, is due to the increased popularity of the JSON language as compared to the XML language. JSON is less flexible than XML, but much more visual.

 The technical problem that the claimed invention addresses is to create a new way of describing composite data types, on the basis of which it would be possible to create fundamentally new languages for describing composite data types that could surpass the existing analogues mentioned above and which would not have the above disadvantages.

The technical result of the claimed invention is to simplify and reduce the time to develop a description of a composite data type while increasing usability by increasing the efficiency of perception by developers. This technical result is achieved due to the fact that in the method of describing a composite data type for a minimal description of a composite data type, an example of this type of data is used, the rules for interpreting the presence or absence of an example data element of this type 5 in the description of a composite data type are determined, the rules for implementing extensions descriptions of the data type in the description of the composite data type, extend the minimum description of the composite data type by embedding it in the minimum description the composite data type of additional elements according to the previously defined rules for introducing data type description extensions into the description of the composite data type and determine the rules for interpreting the extensions of the description of the composite data type.

 The method can additionally check the correctness of the data for compliance with the description of the composite data type.

 The method can display error messages in the data to be checked 15 and / or tips on eliminating errors in the data being checked.

 The method can create electronic documentation on a composite data type.

 The method can visually highlight the syntactic constructs describing the composite data type.

20 In the method, an example data type can be generated based on the description of the composite data type.

 The core for describing a composite data type is an example of data of this type, i.e. in the extreme case, the example of the data type itself is the minimum description of this data type. Additional specification 25 data type descriptions are introduced into the same example using service fields.

 The inventive method allows you to create languages describing composite data types that can significantly simplify the work of a software developer to create, study, use and change zo descriptions of composite data types compared to existing similar languages. This is achieved due to the fact that the description of the data type is easily created by the developer, i.e. it is enough to write an example of the data and, if necessary, add clarifications. In addition, the description of the type of data is quickly perceived by the developer, i.e. when looking at sample data developer quickly

35 intuitively assimilates the structure of this data type, with further analysis descriptive utility fields, he quickly learns the characteristics of the data type. The data type description is easily converted to a valid data type example that can be used in development. To do this, it is enough to remove service fields from the data type description. The visual highlighting of syntactic structures in a text editor allows you to significantly speed up the process of mastering the data type by the developer, for example, you can highlight the sample data fields and obscure the service fields.

 The invention is particularly useful in the development of the following types of computing systems: distributed network applications and data storage systems.

 The claimed invention is illustrated using the figure, which shows a block diagram of the method.

 The method is as follows.

 The essence of the invention is to use the sample data of some composite data type as the basis for the description of this data type.

 The reason for this is the fact that the sample data of some type in an obvious way somehow describes this data type. For example, the following data (in JSON language):

 {

 "name": "Petrov Ivan",

 "salary": 200.0

 }

Obviously, they say that the corresponding data type contains the field "name" of type string and the field "salary" of type number.

Then separately determine the rules for interpreting the presence or absence of an element of an example of data of this type in the description of the composite data type. For example, the rule of interpreting presence may sound like this: “If some type of field is present in the sample data, this should be interpreted so that this field is not mandatory in the described data type, but if this field is present, then the type of this field must strictly correspond the type of this field in the sample data ". The rule of missing interpretation may sound like this: “If there is no some type of field in the sample data, then such a field cannot be present in the data of the described data type.” Applying the described rules to the above For example, we can say the following about this data type: “The data of the described data type“ may ”contain a field“ pat ”of type string, also they“ may ”contain a field of“ salary ”of type number. Other data fields of this data type can not ". These rules can be formulated somewhat differently, depending on the implementation of a specific data type description language.

 Determine the rules for the introduction of extensions of the description of the data type in the description of the composite data type by the introduction of service fields, equipped with symbols.

 Expand the minimum description of a composite data type by introducing additional elements into the minimum description of a composite data type according to the rules already defined for introducing data type description extensions into the description of a composite data type.

 Due to the fact that the data example does not describe all the characteristics of the corresponding data type, the inventive method involves the introduction of data specifying service fields into the data sample, which differ from the data fields of the data by a special conventional designation. For example, if it is necessary to indicate in the given example that the "name" field is mandatory, then write so:

 {

 "name": "Petrov Ivan",

 "salary": 200.0,

 "@@ required": ["name"]

 }

 In this example, the "@@ required" field is a service one and is intended to specify the fields that are required in this data type.

 Similarly, you can enter in the description of the data type any number of service fields that will reflect the various characteristics of the described data type. In this example, the "@@ required" field begins with two characters "@@", which means that this field is official.

Service descriptive fields in the claimed method can describe: the data type of the field, for example, "string" or "logical" or "any type"; restrictions on the value of the field, for example, "integer in the range from 0 to 100" or "string length not more than 100 characters";

 required field;

 variants of data types of the field value, if the field value can be represented by data of different types;

 any other rules that must comply with the data of the specified type;

 text comment to the field;

 text commentary to the entire data type;

 · Any other ways of documenting the data type.

 In the field descriptions can be used calculated expressions.

 After determine the rules for interpreting the extension description of the composite data type. For example, one of the rules might sound like this: “The extension of the description of the service data type, which is entered by the service field" @@ required ", containing as its value an array of elements of type string, should be interpreted as follows: all fields of the described data type, whose names coincide with one of the strings in the array of strings of the "@@ required" field are mandatory in the described data type ".

 In a method implemented using software, the correctness of the data is checked for compliance with the description of the composite data type. The software verifies the correctness of the data using algorithms that are a technical implementation in one of the algorithmic programming languages of certain rules for interpreting the presence or absence of data in an example of a data type, rules for implementing data type description extensions, rules for interpreting data type description extensions. The meanings of these rules have been described above. For convenience, the software has a graphical user interface that displays error messages in the data to be checked and / or tips for eliminating errors in the data being checked, and also visually highlights the syntax for describing the composite data type and generates an example of the data type based on the description of the composite type. data.

For convenience, based on the rules for interpreting the presence or absence of an element of sample data of this type in the description of a composite data type, rules for implementing description extensions, and rules for interpreting b description extensions create electronic documentation on the composite data type.

 Examples of implementation.

 On the example of the data type in JSON

{

 "name": "John"

 } About this data type, we can say that the root element of this data type may be an object, which may include the name field, which may be of the string type.

 Although the word “may” is used several times in the above description, this description is sufficient for the programmer to quickly “master” the structure of this data type.

 If we additionally agree that the elements of the data structure cannot have a different type in different instances of this data type, then it can be said even more specifically about this example that the root element is of the type “object”, which may include the element “stale” of the type "line".

 In addition to this understanding of the structure of the data type, the programmer also sees in front of him a real example of data of this data type. The vision of the example allows the programmer to better understand the purpose of the data and, accordingly, to quickly understand the data structure.

 The description of the same data type in JSON-Schema language looks like this:

{

 "type": "object",

 "properties": {

 "name": {

 "type": "string"

 }

 }

} This description is much more difficult for human perception and does not contain examples of data of this type.

 Although the example of the data type allows judging the structure of the data type, as shown above, these judgments are not enough to fully describe the data type so that this description is suitable for practical use.

 For example, the author of a description of a data type may wish to indicate that the element “pate” in the example given is a required element of the root object.

 It is not difficult to translate this wish, if you enter the service field "@@ required" in the description of the data type as follows:

{

 "name": "John",

"@@ required": ["name"]

 }

In this example, it is agreed that elements whose name begins with the characters "@@" are "service" or "descriptive" elements. Understanding this condition, any programmer of average qualification can quickly “decipher” this record: the root element is of the type “object”, which must include an element of “string” of the type “string”.

 If the author of the description of the data type wants to indicate that the "pate" field should be no longer than 20 characters, then this can be, for example, solved like this:

{

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

"@@ required": ["name"] In this example, it is assumed that elements whose name begins with the “@” symbol are intended to describe the data types of elements of the same nesting level. Thus, the element "@pagle" describes the element "pate".

 THIS example the programmer will intuitively decipher like this: the root element has the type “object”, which should include the element “pat” of the type “string”, no longer than 20 characters.

 In the same way, it is possible to supplement the example with many other additional descriptions that are used in the data type. For example, a fairly complex data type employee card can be described as:

"login": "lapkina",

 "name": "Lapkina",

 "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"]

 }

 Despite the fact that this type of data has a rather complicated structure, if the programmer is familiar with the rules we described earlier, the “assimilation” of this type of data still happens quite easily and can take him 1-2 minutes.

 The same data structure in JSON-Schema will be described as follows:

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

 }

and },

 "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"] The variant using JSON-Schema is more difficult to read and does not contain an example of use.

 It should be noted that the simpler the data type, the more advantageous the proposed 5 method differs from the traditional way of describing data types using the JSON-Schema language. This is especially important because in practice, simple data types are used much more often than complex ones. This means that, in practice, the claimed method of describing data types will have a significant effect on the accepted criteria.

Yu

 Fields with data type options.

 Below is the geometric shape data type. This data type contains the “type” field - the type of the figure and “size” - the size of the figure, and the structure of the “size of the figure” field depends on the type of the figure. For example, if figure 15 is a rectangle, then the data example might look like this:

{

 "type": "rectangle",

 "size": {

 20 "width": 10,

 "height": 20

 }

 }

25 If the figure is a circle, then the data example will look a little different:

{

 "type": "circle",

"size": {

 "radius": 35

 }

} It is seen that the internal structure of the size field can change and at the same time can take one of several types.

 In order to describe this behavior of the “size” field, enter the service field “@@ saze @ [option name]” to describe the variant of the data type of the parent element. In this case, get the following description of the data type "geometric figure":

{

 "type": "circle",

"size": {

 "@@ case @ circle": {

 "radius": 35,

 "@@ required": ["radius"]

 },

"@@ case @ square": {

 "width": 10,

 "height": 20,

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

 }

 }.

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

 }

Calculated expressions.

The data type is “girl”, which has three fields: “isBeautiful” (beautiful), “isMarried” (married) and “phoneNumber” (phone number). At the same time, the “isBeautiful” and “isMarried” fields are always obligatory, and the “phoneNumber” field is mandatory only if the girl is beautiful and not married. This means that the obligatory “phoneNumber” field depends on specific values in the “isBeautiful” and “isMarried” fields. In this case, to describe the data type, you can use the so-called "calculated expressions", which allow you to calculate certain values depending on specific field values and other context parameters, for example, current time, total data size in bytes, etc. An example of using calculated expressions in describing the data type “girl” looks like this: {

 "isBeauitiful": true

 "isMarried": false,

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

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

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

 }

In this example, the calculated expression “this.isBeautiful &&! this. isMarried "to calculate the mandatory field" phoneNumber ". This expression is written in the syntax of the JavaScript language and denotes a logical expression: "beautiful and NOT married." The syntax of the expression language is not decisive - you can use any suitable syntax. The expression can return data of any valid type, and also can contain operands and functions for working with any data types: strings, numbers, objects, arrays, etc. Shielding of characters denoting service fields.

When using the proposed method of describing composite data types, a situation may arise in which the data type contains a field whose name corresponds to the designation of service fields adopted in this language. To distinguish this field from service, use the technology of "shielding" characters. For example, it can be agreed that the initial character of the string “@”, which is used in these examples to denote service fields, can be escaped with the symbol “!”. That is, the sequence of characters "! @" At the beginning of the field name will mean that this is not a service field, but a regular field that starts with the "@" symbol. For example, if required in the data type to enter the field "@name", then it will look like this: "! @name". And then the entire description of the data type may look like this:

Jname ":" Nikolay "

In a similar way, the initial “!” Symbol itself can also be escaped, which in this case also became official. That is, for example, if they want to enter a field with the name “! @Name” in the data type, then in the description of the data type, the first character “!” Must be escaped, so that:

"!! @ name": "Nikolay"

 }

Such a technique can solve any problems associated with the need to distinguish when the service characters have a service value, and when their own value.

XML example.

 An example of the “Employee” data type is:

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

 <user login = "lapkina">

 <pate> Lapkina </ pate>

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

In XSD, the schema for this XML document might look like this:

<? 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>

Using the inventive method, the description of the “Employee” data type may look like this:

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

 <user login = "lapkina">

 <pate> Lapkina </ pate>

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

In this example, the symbol “_” is used to denote service fields as the service symbol, since the XML specification does not allow the “@” symbol to be used at the beginning of the element name.

It is obvious that the scheme of the document in the XSD language is perceived much more complicated than the description of the data type using the proposed method.

 This example clearly shows that the technique described by us demonstrates its advantages described above, including in XML.

 The following shows the application of the proposed method to the format YAML. An example of the data type “Employee” is as follows: login: lapkina

 name: Lapkina

 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

In Kwalify, the schema for such an XML document might look like this: 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

Using the inventive method, the description of the data type “It looks like, for example, login: lapkina

 name: Lapkina

 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]

In this example, the symbol “_” is used to denote service fields as a service symbol, since the YAML language specification does not allow the use of the symbol “@” at the beginning of the element name.

 It is obvious that the scheme of the document in the Kwalify language is perceived to be much more complicated than the description of the data type using our methodology.

 This example clearly shows that the technique described by us demonstrates its advantages described above, including in the YAML language.

 Thus, as a language for describing a data type, the basis is the same language in which data of a specified data type will be formed. For example, for JSON type data, a description will be created in JSON. This requirement is not mandatory, but when this requirement is fulfilled, the developer gets additional convenience when working with the description of the data type and examples of this type of data when they are compiled in one language.

 The minimum description of the data type corresponds exactly to the sample data of this type.

 Expansion of the description of the data type is carried out by introducing into the minimum description of the data type of additional elements according to certain predetermined rules for writing extensions of the description of the data type.

 The rules for writing data type description extensions must satisfy the following conditions:

- elements of extensions should be easily visually different from elements related to the minimum description of the data type (in this example, for JSON, they all begin with the “@” symbol); - extension elements must be entered in such a way that it is visually easy to determine which element of the minimum description of the data type they belong to; in this example, they have the same nesting level and have a similar name, for example, the @login extension element refers to the login element.

 The inventive method of describing data types has the same capabilities as traditional methods of describing data types, such as JSON-Schema, XSD, Kwalify, etc.

 The inventive method of describing data types is easily created by man and quickly perceived by man.

 Additional advantages of the described methodology are: the description of the data type contains examples of use that may be useful in the development; The use of visual highlighting of syntactic structures makes it possible to significantly simplify the perception of the structure of the described data type.

 These advantages are achieved due to the fact that the basis for describing a data type is an example of data of this type, which allows you to quickly create a basis for describing a data type, and also makes it easy to assimilate the structure of a data type; and data type description extensions do not diminish the advantages indicated in the previous paragraph, since these extensions are visually separated from the “example”.

 These positive effects of the proposed method are more pronounced when describing simple data types, which is especially important, since in practice the overwhelming number of data types used are quite simple.

 These examples are special cases and do not exhaust all possible implementations of the claimed invention.

 It should be clear to a person skilled in the art that various variations of the proposed method do not change the essence of the invention, but only determine its specific embodiments.

Claims

CLAIM 1. A method for describing a composite data type, characterized in that, for a minimal description of a composite data type, an example of data is used. 5 of this type, separately determine the rules for interpreting the presence or absence of an element of an example of this type of data in the description of a composite data type, define the rules for introducing data type description extensions into the description of a composite data type, expand the minimum description of a composite data type by embedding it into a minimal description data type of additional elements according to the previously defined rules for introducing data type description extensions into the description of a composite data type and define rules interpretation of a composite data type description of extensions.  2. The method according to claim 1, characterized in that they check the correctness of 15 data for compliance with the description of the composite data type.  3. The method according to claim 2, characterized in that the display error messages in the data being verified.  4. The method according to p. 2, characterized by the fact that display tips on eliminating errors in the data being verified.  20 5. The method according to claim 1, characterized in that it creates electronic documentation on the composite data type.  6. The method according to claim 1, characterized in that the syntactic constructions describing the composite data type are visually distinguished.  7. The method according to claim 1, characterized in that generate an example of the type 25 data based on the description of the composite data type.