Что такое json schema
JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.
Benefits
What now?
Learn, Get help, Shape the Community, Chat, with the JSON Schema team and Community!
Regular Activities
We hold weekly Office Hours and twice monthly Open Community Working Meetings.
Office Hours are every Tuesday at 15:00 UTC.
Open Community Working Meetings follow two patterns:
Need more?
About Our Community
We have an active and growing community. All are welcome to be part of our community, help shape it, or simply observe.
We want to keep our community welcoming and inclusive, so please read our JSON Schema Organizational Code of Conduct. (This is a combination of the Contributor Covenant and IETF BCP 54.)
The JSON Schema team and community are here to help!
At any point, feel free to join our Slack server.
Our Slack server has limited history, so we also use GitHub Discussions.
We monitor the jsonschema tag on StackOverflow.
Project Status
2021-02-01: Draft 2020-12 has been published!
We are using dates for meta-schemas, which are what implementations should use to determine behavior, so we will usually refer to 2020-12 (without the word “draft”) on this web site.
See the Specification page for details about naming and numbering.
The Path to Standardization
The JSON Schema project intends to shepherd all three draft series to either: RFC status, the equivalent within another standards body, and/or join a foundation and establish self publication rules.
Currently, we are continuing to improve our self-published Internet-Drafts. We are not actively pursuing joining a standards organisation.
We have a few contacts related to each potential path, but if you have experience with such things and would like to help, please still contact us!
In the meantime, publication of Internet-Draft documents can be tracked through the IETF:
Internet-Drafts expire after six months, so our goal is to publish often enough to always have a set of unexpired drafts available. There may be brief gaps as we wrap up each draft and finalize the text.
Use of the draft designation
Releases of the JSON schema specification and meta schemas use the draft designation primarily for historical reasons stemming from the relationship of this specification to IETF (explained here). The use of this designation is under review but will continue until this review process completes to avoid changing the designation style multiple times.
The JSON schema project recognizes, condones, and advocates for the use of the JSON schema standard in production.
Each release of the JSON schema specification is treated as a production release by the JSON schema project. All changes in each new release are made judiciously, with great care, thorough review and careful consideration of how the changes will impact existing users and implementations of the JSON schema specification.
Similarly to most specifications, the JSON schema specification will continue to evolve, and not all releases will be backwards compatible. The intention, particularly for vocabularies such as validation which have been widely implemented, is to remain as compatible as possible from release to release. However, major changes can still occur given a clear enough need validated with the user community.
When the draft designation is dropped this may indicate that the frequency of releases and amount of changes in each release will decrease, but it won’t indicate that no new releases will be made, or that all future releases will be backwards compatible.
Quickstart
The JSON document being validated or described we call the instance, and the document containing the description is called the schema.
The most basic schema is a blank JSON object, which constrains nothing, allows anything, and describes nothing:
You can apply constraints on an instance by adding validation keywords to the schema. For example, the “type” keyword can be used to restrict an instance to an object, array, string, number, boolean, or null:
JSON Schema is hypermedia ready, and ideal for annotating your existing JSON-based HTTP API. JSON Schema documents are identified by URIs, which can be used in HTTP Link headers, and inside JSON Schema documents to allow recursive definitions.
JSON Hyper-Schema
JSON Hyper-Schema is on hiatus / not currently maintained as of 2021.
This allows the team to focus the little time they do donate on JSON Schema core and validation.
We may revisit JSON Hyper-Schema at a later date.
More Links
Interested? Check out:
We encourage updating to the latest specification where possible, which is 2020-12.
Questions? Feeling helpful? Get involved on:
JSON Schema и ее использование для валидация JSON-документов в C++
В данной статье описывается стандарт JSON Schema и его использование для проверки соответствия заданному формату на языке C++ средствами библиотеки valijson.
Немного истории
Для начала вспомним, что привело к повсеместному вытеснению JSON-ом XML-а и что в этом было плохого. XML изначально создавался как метаязык разметки документов, позволяя использовать унифицированный код парсера и валидатора документов. Будучи первым стандартом такого рода, да еще и пришедшимся на период бурного внедрения цифровых корпоративных информационных систем, XML послужил основой для бесчисленного множества стандартов сериализации данных и протоколов взаимодействия, т.е. хранения и передачи структурированных данных. Тогда как создавался он прежде всего для разметки документов.
Будучи разрабатываемым комитетами, стандарт XML оказался дополнен множеством расширений, позволяющих, в частности, избегать конфликтов имен и выполнять сложные запросы в XML-документах. И, самое важное, поскольку получающееся нагромождение тэгов оказывалось совершенно нечитаемым никаким человеком, был разработан и широко реализован стандарт XML Schema, позволяющий на том же XML абсолютно строго описать допустимое содержимое каждого документа с целью последующей автоматической проверки.
Тем временем, все больше разработчиков под влиянием зарождающихся интерактивных web-технологий стало знакомиться с языком JavaScript, и они начали осознавать, что для представления структурированных объектов в текстовом виде совершенно не обязательно изучать много сотен страниц XML-спецификаций. И когда Дуглас Крокфорд предложил стандартизовать подмножество JavaScript для сериализации объектов (но не разметки документов!) безотносительно к языку, идея была поддержана сообществом. В настоящее время JSON является одним из двух (вместе с XML) языков, поддерживаемых всеми сколько-либо популярными технологиями программирования. Тот же YAML, призванный сделать JSON более удобным и человекочитаемым, ввиду своей сложности (т.е. широты возможностей) распространен не так широко (в моей компании не так давно были проблемы с работой с YAML из MATLAB, тогда как с JSON все хорошо).
Так вот, массово начав использовать JSON для представления данных, разработчики столкнулись с необходимостью вручную проверять содержимое документов, каждый раз на каждом языке переизобретая логику валидации. Людей, знакомых с XML Schema, это не могло не бесить. И постепенно аналогичный стандарт JSON Schema таки сформировался и живет по адресу http://json-schema.org/.
JSON Schema
Рассмотрим пример простой, но показательной, схемы, задающей словарь 2D или 3D геометрических точек в пространстве (-1, 1)x(-1, 1)x(-1, 1) с ключами, состоящими из цифр:
Но это в том случае, если для вашего языка/платформы реализован валидатор. В случае с XML такой вопрос вряд ли мог бы встать.
На http://json-schema.org/ сайте вы можете найти список ПО для валидации. И вот в этом месте незрелость JSON-Schema (и ее сайта) дает о себе знать. Для C++ указана одна (вроде бы интересная) библиотека libvariant, которая занимается валидацией лишь по совместительству и к тому же выпущена под зловредной лицензией LGPL (прощай, iOS). Для C у нас тоже один вариант, и тоже под LGPL.
Тем не менее, приемлемое решение существует и называется valijson. У этой библиотеки есть все что нам нужно (валидация схем и BSD-лицензия), и даже больше, — независимость от JSON-парсера. Valijson позволяет использовать любой json-парсер посредством адаптера (в комплекте адаптеры для jsoncpp, json11, rapidjson, picojson и boost::property_tree), таким образом не требуя переходить на новую json-библиотеку (или тащить за собой еще одну). Плюс ко всему, она состоит только из заголовочных файлов (header only) и не требует компиляции. Очевидный минус только один, и то не для всех, — зависимость от boost. Хотя есть надежда на избавление даже от этого недо-недостатка.
Разберем на примере документа составление JSON-схемы и валидацию этого документа.
Пример составления схемы
Допустим, у нас есть таблица неких полосатых объектов, для которых задана конкретная полосатая раскраска (в виде последовательности 0 и 1, соответствующих черному и белому).
Здесь мы имеем словарь с числовыми ключами, к которым может быть приписан суффикс «inv» (для инвертированных штрих-кодов). Все значения в словаре являются объектами и обязаны иметь поля «width», «stripe_length» (строго положительные числа) и «code» (строка нулей и единиц длины 12).
Начнем составлять схему, указав ограничения на формат имен полей верхнего уровня:
Здесь мы воспользовались конструктом patternProperties, разрешающим/специфицирующим значения, ключи которых удовлетворяют регулярному выражению. Также мы указали (additionalProperties=false), что неспецифицированные ключи запрещены. Используя additionalProperties, можно не только разрешить или запретить неуказанные явно поля, но и наложить ограничения на их значения, указав в качестве значения спецификатор типа, например, так:
Далее опишем тип значения каждого объекта в словаре:
Здесь мы явно перечисляем разрешенные поля (properties), требуя их наличие (required), не запрещая (по умолчанию) любые дополнительные свойства. Числовые свойства у нас строго положительные, а строка code должна соответствовать регулярному выражению.
В принципе осталось только вставить описание типа отдельного объекта в вышеописанную схему таблицы. Но прежде чем это сделать, отметим, что у нас дублируется спецификация полей «width» и «stripe_length». В реальном коде, из которого взят пример, таких полей еще больше, поэтому полезно было бы один раз определить данный тип, а потомы ссылаться на него отосвюду. Именно для этого есть механизм ссылок ($ref). Обратите внимание на секцию definitions в итоговой схеме:
Сохраним ее в файл и приступим к написанию валидатора.
Применение valijson
В качестве json-парсера используем jsoncpp. Имеем обычную функцию загрузки json-документа из файла:
Минимальная функция-валидатор, сообщающая нам о расположении всех ошибок валидации, выглядит примерно так:
Теперь мы можем загружать и валидировать документы:
Все, мы научились валидировать json-документы. Но обратим внимание, что теперь нам придется думать, где хранить схемы! Ведь если документ каждый раз меняется и получается, например, из web-запроса или из аргумента командной строки, то схема неизменна и должна поставляться вместе с приложением. А для небольших программ без развитого механизма загрузки статических ресурсов необходимость введения такового представляет значительный барьер для внедрения валидачии через схемы. Вот было бы здорово компилировать схему вместе с программой, ведь изменение схемы в любом случае потребует изменения кода, обрабатывающего документ.
Это возможно и даже довольно удобно, если в нашем распоряжении есть C++11. Решение примитивное, но работает прекрасно: мы просто определяем строковую константу с нашей схемой. А чтоб не заботиться о кавычках внутри строки, мы используем raw string literal:
Что такое json schema
JSON Schema — это распространенный стандарт описания структуры данных. Спецификация стандарта и популярные сценарии его использования доступны на ресурсе http://json-schema.org/
Схема создана для описания JSON-данных, но и сама она при этом является JSON-объектом. С помощью ключевых слов в схеме создаются правила валидации структуры объекта и типов его полей.
Рассмотрим простой пример.
У каждого пользователя ВКонтакте есть id (некоторое число), имя (строка) и фамилия (строка). В API эти данные представлены в виде объекта с набором соответствующих полей. В JSON объект выглядит вот так:
JSON-схема, описывающая этот объект:
Ключевое слово required задает перечень обязательных полей. Если хотя бы одно из перечисленных полей будет отсутствовать, объект не пройдет валидацию по такой схеме.
Ключевое слово additionalProperties задает возможность наличия дополнительных полей у объекта. В нашем случае дополнительные поля запрещены (при их наличии объект не пройдет валидацию по схеме).
Перейдем к более сложной структуре.
Вызовем метод users.get с параметрами user_ids=210700286,297428682, и v=5.52 (Посмотреть результат в браузере).
Вызовем метод users.get с параметрами user_ids=210700286,297428682, и v=5.52.
В ответе сервер вернет JSON:
Это объект с единственным полем response, которое, в свою очередь, содержит массив объектов с базовой информацией о пользователе ВКонтакте. Вложенный объект содержит все те же три поля: id — численное значение, идентификатор пользователя; first_name — строковое значение, имя пользователя; last_name — строковое значение, фамилия пользователя.
JSON-схема для этого объекта выглядит так:
Описывает все методы API. Например, метод users.get:
Описывает формат объектов, приходящих в ответах от методов. Например, объект «audio_audio_album»:
Название объекта состоит из названия секции, методы которой возвращают этой объект, и названия самого объекта после знака подчеркивания.
Описывает формат ответов методов. Например, ответ метода account.getProfileInfo:
Описывает дополнительные сущности, которые используются в схеме, такие как «method», «error», «parameter» и прочие. Это необходимо, чтобы расширить возможности JSON-схемы, придерживаясь спецификации. Например, у нас используется сущность «error»:
Разделение на файлы необходимо только для удобства ручного поиска данных. Использовать их по отдельности бессмысленно, поскольку каждая схема ссылается на все остальные.
На основе схемы можно создавать SDK для API на любой платформе. Вы можете работать только с одной секцией методов или использовать их все, чтобы реализовать полнофункциональный клиент.
Схема позволяет работать с кодогенераторами, такой подход дает Вам возможность уделить больше времени внутренней логике Вашего приложения, сэкономив ресурсы на изучении формата данных API.
Пример SDK, реализованного на основе схемы, Вы можете найти на этой странице.
Если ранее Вы не были знакомы с нашим API, мы бы советовали также прочитать это руководство перед началом работы.
JSON Schema. Быть или не быть?
Архитектура: искусство делать излишнее необходимым.
Ни для кого давно уже не секрет, что для любого web-сервиса на протоколе SOAP с сообщениями в формате XML верным и проверенным временем решением является предварительная разработка XML Schema (xsd-схемы), описывающей типы данных и структуру XML сообщений. При этом подходе у разработчиков существует явное преимущество: у них есть строгие стандартизированные правила по структуре сообщений, которые заданы в схеме, число правил конечно, и они позволяют автоматизировать проверку любого нового сообщения в формате XML.
Но также известно, что язык XML потеснился языком разметки JSON (JavaScript Object Notation) в виду его большей тяжеловесности (тяжеловесности XML), а также в виду распространения архитектурного стиля REST (REpresentational State Transfer) разработки программного обеспечения для распределенных систем. Хотя сам REST-стиль не требует использования JSON (он вообще, можно сказать, ничего не требует, а «рекомендует»), но как показывает практика, чаще при разработке REST API все-таки используется JSON для описания тела сообщений.
Так вот, практика разработки REST API с JSON–сообщениями прочно вошла в жизнь ИТ в России (и не только у нас), хотя опыт при этом по описанию структуры сообщений в виде XML Schema, значительно упростивший жизнь разработчиков web-служб в свое время, упорно игнорируется в случае c JSON–сообщениями. Но не всеми, что не может не радовать.
Когда разработчики, знакомые с XML Schema, столкнулись с необходимостью каждый раз заново изобретать велосипед с разбором документов и переизобретать логику валидации, сформировался аналогичный драфт JSON Schema. Он доступен по адресу json-schema.org, а также ряд документов по истории изменений и примеров использования. И несмотря на то что он публикуется в статусе «draft», его давно уже поддерживают все популярные платформы разработки и библиотеки на разных языках.
Сама JSON Schema предоставляет меньше возможностей по структуризации сообщений, чем XML Schema. То, что легко можно описать через XML Schema, не всегда будет тривиальной задачей повторить с помощью JSON Schema, если вообще это будет возможно. Но здесь же я бы данный факт стала рассматривать и как преимущество. Почему?
Известно, что чем проще и линейнее алгоритм работы системы, тем она и надежнее, что чем проще структура документа, тем легче он для восприятия и т.д.
Не могу удержаться, чтобы не процитировать: «Всё гениальное просто, и всё простое гениально». И если не удается с помощью схемы описать сложную структуру документа и множество допустимых вариантов, то, возможно, стоит посмотреть в сторону упрощения самой структуры и логики формирования этого документа?
Предисловие
Итак, о чем же эта статья?
Я бы хотела привлечь больше внимания к преимуществам описания передаваемых JSON сообщений схемой JSON Schema. Несмотря на то, что «на входе» разработка REST API без какой-либо JSON-схемы всегда проще и быстрее, но с ростом системы, ее отсутствие так или иначе приводит к удорожанию сопровождения и поддержки системы. Также любая предварительная проработка структуры сообщений способствует более качественной организации обмена сообщениями, без лишнего дублирования при обмене данными и общими правилами их обработки.
Также в целях распространения информации в русскоязычном сообществе о возможностях JSON Schema и правилах работы с ней я поделюсь своим некоторым опытом на конкретных примерах в рамках данной статьи.
Постановка задачи
Перед тем как приступить к изучению JSON и JSON Schema, опишу задачу, на которой мы будем рассматривать все примеры далее.
Рассмотрим ролевую модель управления в организации. Предполагаем, что справочную информацию по существующей ролевой модели мы должны будем передавать в зависимые системы в сообщениях в формате JSON посредством вызова REST-сервиса.
В организации есть сотрудники, им часто приходится работать одновременно в нескольких системах. При этом уровень доступа (полномочий) к тем или иным компонентам системы (ресурсам) для разных сотрудников в зависимости от их роли в организации может отличаться, и должен контролироваться при авторизации пользователя в системе.
Например, бухгалтер (роль) будет иметь доступ на чтение и редактирование (операции/полномочия) к расчетным листкам (ресурс) по заработной плате всех сотрудников, а у аналитика (роль), к примеру, будет доступ на чтение (операция/полномочия) только по своему расчетному листку (ресурс).
Необходимо спроектировать и описать ролевую модель управления в организации. Доступные роли, набор возможных полномочий и ресурсов в системе необходимо передавать другим системам по запросу.
Рисунок 1. Представление компонентов ролевой модели
Способы описания и реализации ролевой модели могут отличаться, но независимо от реализации чаще всего в ролевой модели в таком случае мы можем выделить следующие базовые составляющие:
Таблица 1. Дискретная матрица доступов.
| Ресурс: documents | Ресурс: objects | |
|---|---|---|
| Роль: manager | read, print | read, create |
| Роль: accountant | read, create | read |
Далее в статье мы ознакомимся сначала с теоретической составляющей текстового формата обмена данными JSON и правилами их структурирования с помощью JSON Schema, а в качестве примеров буду приводить описание сущностей-справочников для ролей, ресурсов и операций на языке JSON и их JSON–схем в рамках нашей поставленной задачи.
JavaScript Object Notation (JSON)
JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript.
Теория
Язык разметки JSON задает ограниченный набор типов данных. Для пары <“ключ”: значение>для «ключа» всегда используют тип string, для «значения» применимы типы: string, number, object (тип JSON), array, boolean (true или false) и null.
Рисунок 2. Типы данных JSON
На рисунке приведены базовые типы и примеры их использования. Достаточно просто все, на мой взгляд.
Синтаксис JSON является подмножеством синтаксиса JavaScript, где:
Практика
Рассмотрим пример справочника ролей, который мы будем передавать в сервисе:
Рисунок 4. Описание справочника ролей в формате json
Из примера видно, что даже несмотря на столь небольшое число базовых типов, при их комбинации мы можем создавать более сложные структуры сообщений при необходимости. Здесь, в частности, я описываю справочник ролей через объект массивов, содержащих другие объекты (на рисунке 4 выделены двумя прямоугольниками).
В табличном виде с помощью средств визуализации json-сообщений справочник может быть представлен следующим образом:
Рисунок 5. Визуализации справочника ролей в формате JSON
Справочник, условно говоря, представляет собой 3 «таблицы» для задания ролей в группе администраторов, бухгалтеров и рабочих. Состав «атрибутов» может быть расширен, при необходимости.
Визуальное представление, на мой взгляд, упрощает восприятие текстового описания. Аналогичную структуру зададим и для двух других справочников. Приведу ниже пример только табличного представления для справочника полномочий (операций) и ресурсов.
Рисунок 6. Визуализации справочника полномочий в формате JSON
Рисунок 7. Визуализации справочника ресурсов в формате JSON
Исходные сообщения в текстовом формате JSON для справочника ролей, ресурсов и полномочий можно скачать/просмотреть по ссылке.
Теперь перейдем к самому интересному: к изучению JSON Schema и созданию схемы под наши справочники!
JSON Schema
Теория
Поскольку схема json написана в формате JSON, она поддерживает все типы JSON плюс дополнение: тип integer, который является подтипом типа number. Сама схема является JSON-объектом и предназначена для описания данных в формате JSON. Ниже приводится схема типов данных, используемых при создании самой схемы:
Рисунок 8. Типы данных JSON Schema
Как видно из рисунка, для схемы используются все те же типы данных, а также все те же принципы синтаксиса, что и для обычного документа JSON, приведенные на рисунке 3.
Теперь рассмотрим самое важное — правила, используемые в схеме для задания ограничений и структурирования JSON-сообщений.
JSON Schema позволяет:
Здесь очень важно обратить внимание, что не все версии могут поддерживаться вашим инструментом работы со схемой. Но 4-й драфт поддерживают практически все. О последних изменениях (JSON Schema 2019-09 Release Notes) для разных версий можно познакомиться по ссылке json-schema.org/draft/2019-09/release-notes.html.
Остальные ключевые слова используются непосредственно для проверки документа JSON. Их мы сейчас и рассмотрим.
Таблица 2. Анализ структуры JSON Schema. Ключевые слова и их примеры использования.
| Тип | Keyword(s) | Пример/описание |
|---|---|---|
| «Keywords» для описания схемы | «$schema» | Используется для задания версии драфта схемы. |
| «$id» | Используется для указания уникального идентификатора документа или его подсхем. | |
| «title» «description» «examples» «comment» | ||
| Общие «Validation keywords», независимые от типа данных элемента | «enum» | Выполняется проверка на совпадение с хотя бы 1 значением. |
| «const» | Выполняется проверка на точное соответствие заданному значению. | |
| «type» | Указывает тип данных, который будет использоваться схемой. Это ключевое слово не является обязательным, и значением ключевого слова может быть строка, представляющая допустимый тип данных, или массив строк, представляющих допустимые типы данных. | |
| Keywords, зависимые от того типа данных, с которым они используются | «type»: «string» |
minLength
maxLength
pattern
contentEncoding
contentMediaType
minimum
exclusiveMinimum
maximum
exclusiveMaximum
multipleOf
properties
required
dependencies
minProperties
maxProperties
propertyNames
patternProperties
additionalProperties
minItems
maxItems
uniqueItems
contains
items
additionalItems
Ключевые слова не используются
Ключевые слова не используются
«format»: «____»
«default»: «____»
Это ключевое слово не является обязательным, и значение этого ключевого слова может быть любым.
«if-then-else»
«oneOf»
«allOf»
Ссылаемся на схему 1 с помощью $ref (приведена часть схемы со ссылкой):
Мы рассмотрели ключевые слова схемы JSON, позволяющие описать нам будущую структуру наших сообщений в формате JSON.
Практика
При рассмотрении примеров завершенных JSON-схем мы поступим аналогично примерам работы с самими сообщениями в формате JSON. Т.е. мы будем использовать визуальное представление в древовидном и табличном виде для наших схем справочников ролей, ресурсов и полномочий (операций), а с текстом схем предлагаю ознакомиться заинтересовавшихся читателей самостоятельно в git.
Ниже приводится схема для справочника ролей.
Рисунок 9. Пример JSON Schema для справочника ролей
Как мы видим на рисунке, схема представляет собой JSON-объект и описывает наше сообщение для передачи справочника ролей в формате JSON, которое приводилось на рисунке 4. На текущем примере представлено как с помощью JSON схемы может быть описан объект массивов, состоящий из объектов.
Схемы двух других справочников (полномочий и ресурсов) по своей структуре идентичны со схемой для справочника ролей, поэтому не буду их здесь приводить, а приведу схему, объединяющую в себе все 3 справочника.
К сожалению, схема всего справочника при раскрытии не поместится на экране, поэтому рассмотрим ее часть.
Рисунок 10. Пример JSON Schema справочника, объединяющего в себе справочник ролей, полномочий и ресурсов
На рисунке мы видим, что часть объектов массива справочников подключена с использованием ключевого слова «anyOf».
Также, возможно, нагляднее будет табличное представление справочника.
Рассмотрим еще одну важную особенность нашей схемы:
Рисунок 11. Пример JSON Schema справочника, объединяющего в себе справочник ролей, полномочий и ресурсов в табличном представлении
Из рисунка мы видим, что объединяющий справочник не дублирует в себе код из ранее разработанных справочников ролей, полномочий и ресурсов, а использует ключевое слово «$ref».
Справочники, рассматриваемые в примерах, находятся в одной директории, но, при необходимости, это правило можно не соблюдать, а размещать в разных директориях, указав корректно путь к ним при подключении. Данная возможность очень полезна, так как позволяет переиспользовать ранее созданные схемы, лишь подключая их в нужные структуры.
На этом мой обзор JSON и JSON Schema я завершаю. Надеюсь, что приведенный здесь материал и рассмотренные примеры, окажутся полезными при изучении возможностей JSON Sсhema.
Вместо заключения
Думаю, пора подводить итоги. Так что же применение JSON Schema в итоге нам может дать?
Возможно, читатели захотят помочь мне продолжить этот список?
Я буду признательна 🙂
Также приведу список ссылок, на мой взгляд, полезных для работы с JSON и JSON Schema
Системный архитектор,
© Ирина Блажина
