Инструкция № Ин-1 от 21 януари 2010 г. за критериите и правилата за прилагането им при вписвания в регистрите на информационните обекти и електронните услуги

След постъпване на заявление за вписване в регистрите на информационните обекти и електронните услуги се проверява дали заявлението е подадено от административен орган, лице, осъществяващо публични функции, или организация, предоставяща обществени услуги, както и неговия идентификатор. Обстоятелствата относно заявителя се проверяват служебно чрез справки от съответния регистър, в който заявителят е вписан.

Когато се установи, че заявител не е административен орган, лице, осъществяващо публични функции, или организация, предоставяща обществени услуги, както и когато заявителят, поискал вписване на електронна услуга, не е първичен администратор, заявлението не се разглежда, а на заявителя се изпраща съобщение за това.

Когато заявлението не е подадено от оправомощено лице – представител на административния орган, на лицето, осъществяващо публични функции, или на организацията, предоставяща обществени услуги, на заявителя се изпраща съобщение за отстраняване на нередовността.

При успешни проверки по чл. 6 и 7 се проверява:

1. 1. дали наборът от данни следва да се поддържа в съответствие с нормативната уредба и дали е допустимо статусът на набора от данни да бъде „използваем“; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на набора от данни, за вписването му по партидата на обекта;
2. 2. дали наименованието на набора от данни и на раздела от набора от данни са отразени по начина, установен в съответния нормативен акт;
3. 3. дали посоченото лице по чл. 2, ал. 1 ЗЕУ има право да поддържа набора от данни съгласно закона;
4. 4. дали заявителят е посоченото лице по чл. 2, ал. 1 ЗЕУ съгласно закона; когато това не е така, се уведомява лицето по чл. 2, ал. 1 ЗЕУ и при наличие на бележки те се вземат предвид;
5. 5. дали посоченото лице по чл. 2, ал. 1 ЗЕУ е вписано или е заявено вписването му с приложение от същото заявление; ако лицето не е вписано, се извършва служебното му вписване;
6. 6. дали посочените видове обстоятелства и унифицираните данни подлежат на поддържане от посоченото лице по чл. 2, ал. 1 ЗЕУ съгласно закона и кои измежду тях са първичните данни;
7. 7. дали видовете обстоятелства и унифицираните данни, посочени в заявлението, са вече вписани или са заявени за вписване с приложение към разглежданото заявление;
8. 8. дали е налице дублиран вид обстоятелство в списъка „Видове обстоятелства“, посочен в заявлението;
9. 9. дали са налице дублирани унифицирани данни в списъка „Унифицирани данни“, посочен в заявлението.

Ако при извършване на някоя от проверките по чл. 8 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

При наличие на вече вписан набор от данни заявяването на промяна или допълване се извършва, като се посочи УРИ на набора от данни, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверки се извършват само по отношение на променените и допълнените обстоятелства.

При успешни проверки по чл. 13 и 14 се проверява:

1. 1. дали видът обстоятелство следва да се поддържа в съответствие с нормативната уредба и дали е допустимо статусът на вида обстоятелство да бъде „използваем“; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на вид обстоятелство, за вписването му по партидата на обекта;
2. 2. дали наименованието на вида обстоятелство е отразено по начина, установен в съответния нормативен акт.

Ако при извършване на някоя от проверките по чл. 15 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Съветът по вписванията определя уникалния регистров идентификатор на унифицирано определение на данни, което следва да се използва вместо вид обстоятелство, по който е вписано.

Когато видът обстоятелство е вече вписан, заявяването на промяна или допълване се извършва, като се посочи УРИ на вида обстоятелство, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверки се извършват само по отношение на променените и допълнените обстоятелства.

При успешни проверки по чл. 19 и 20 се проверява:

1. 1. дали унифицираните данни следва да се поддържат в съответствие с нормативната уредба и дали е допустимо статусът на унифицираните данни да бъде „използваем“; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на унифицираните данни, за вписването му по партидата на обекта;
2. 2. дали наименованието на унифицираните данни е уникално по отношение на наименованията на останалите вписани унифицирани данни, които са със статус „използваем“;
3. 3. дали посочените вид и състав на данните отговарят на изискванията на нормативната уредба;
4. 4. списъкът от унифицирани данни, ако такъв е посочен в обстоятелството „Вид или състав на данните“ в заявлението, за наличие на дублирани унифицирани данни и за наличието на циклична свързаност;
5. 5. дали посочените лица с право на достъп до данните отговарят на изискванията на нормативната уредба или дали не са посочени лица с право на достъп до данните, но такива следва да бъдат посочвани.

Ако при извършване на някоя от проверките по чл. 21 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато унифицираните данни са вече вписани, заявяването на промяна или допълване се извършва, като се посочи УРИ на унифицираните данни, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

При успешни проверки по чл. 24 и 25 се проверява:

1. 1. дали унифицираният етап следва да се поддържа в съответствие с нормативната уредба и дали е допустимо статусът на унифицирания етап да бъде „използваем“; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на унифицирания етап, за вписването му по партидата на обекта;
2. 2. дали наименованието на унифицирания етап е уникално по отношение на наименованията на останалите вписани унифицирани етапи, които са със статус „използваем“.

Ако при извършване на някоя от проверките по чл. 26 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато унифицираният етап е вече вписан, заявяването на промяна или допълване се извършва, като се посочи УРИ на унифицирания етап, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

При успешни проверки по чл. 29 и 30 се проверява:

1. 1. дали пакетът от данни следва да се поддържа в съответствие с нормативната уредба и дали е допустимо статусът на пакета от данни да бъде „използваем“; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на пакет от данни, за вписването му по партидата на обекта;
2. 2. дали наименованието на пакета от данни е уникално по отношение на наименованията на останалите вписани пакети от данни, които са със статус „използваем“;
3. 3. дали е предоставен като приложение документ с файловото съдържание на пакета от данни; проверява се дали приложеният документ съответства на документ, регистриран в регистъра на информационните обекти или заявен за вписване със същото заявление; проверява се дали документът е подписан от административния орган, заявил вписването;
4. 4. дали съгласно нормативната уредба заявителят е първичен администратор на данни по отношение на заявения пакет от данни; когато това не е така, се уведомява първичният администратор и при наличие на бележки те се вземат предвид.

Ако при извършване на някоя от проверките по чл. 31 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато пакетът от данни е вече вписан, заявяването на промяна или допълване се извършва, като се посочи УРИ на пакета от данни, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

При успешни проверки по чл. 34 и 35 се проверява:

1. 1. дали посоченото лице е такова по чл. 2, ал. 1 ЗЕУ в съответствие с нормативната уредба; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на лицето по чл. 2, ал. 1 ЗЕУ, за вписването му по партидата на обекта;
2. 2. дали наименованието на лицето е нормативно регламентирано и дали е заявено точно по начина, установен в нормативния акт;
3. 3. дали за лицето по чл. 2, ал. 1 ЗЕУ има установен със закон идентификатор; при наличие на такъв се проверява дали същият е вписан и дали на него отговаря заявеното наименование.

Ако при извършване на някоя от проверките по чл. 36 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато лицето по чл. 2, ал. 1 ЗЕУ е вече вписано, заявяването на промяна или допълване се извършва, като се посочи УРИ на лицето по чл. 2, ал. 1 ЗЕУ, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

При успешни проверки по чл. 39 и 40 се проверява:

1. 1. дали терминът следва да се поддържа в съответствие с нормативната уредба и дали е допустимо статусът на термина да бъде „използваем“;
2. 2. дали наименованието е нормативно регламентирано и ако е така, дали е заявено точно по начина, установен в нормативния акт; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на термина, за вписването му по партидата на обекта;
3. 3. дали наименованието на термина е уникално по отношение на наименованията на останалите вписани термини, номенклатури, стойности и сегменти, които са със статус „използваем“.

Ако при извършване на някоя от проверките по чл. 41 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато терминът е вече вписан, заявяването на промяна или допълване се извършва, като се посочи УРИ на термин, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

Ако при извършване на някоя от проверките по чл. 46 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато номенклатурата е вече вписана, заявяването на промяна или допълване се извършва, като се посочи УРИ на номенклатура, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

Ако при извършване на някоя от проверките по чл. 51 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато стойността е вече вписана, заявяването на промяна или допълване се извършва, като се посочи УРИ на стойността, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

Ако при извършване на някоя от проверките по чл. 56 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато сегментът е вече вписан, заявяването на промяна или допълване се извършва, като се посочи УРИ на сегмента, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

При успешни проверки по чл. 59 и 60 се проверява:

1. 1. дали документът следва да се поддържа в съответствие с нормативната уредба и дали е допустимо статусът на документа да бъде „използваем“; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на документа, за вписването му по партидата на обекта;
2. 2. дали наименованието на документа е уникално по отношение на наименованията на останалите вписани документи;
3. 3. дали има вписан или заявен за вписване с приложение към същото заявление сегмент, с който се представят данните в документа;
4. 4. дали има сертифицирано приложение в списъка на сертифицираните информационни системи, даващо възможност за пълно, точно и вярно възпроизвеждане на съдържанието на данните в сегмента; ако заявителят е посочил, че такова е в процес на сертификация, се проверява дали посоченото акредитирано лице е започнало сертификацията; в този случай за статус на документа се посочва „приложение за визуализация в процедура по сертификация“; Съветът по вписванията служебно следи за сертификацията на приложението; ако поради сертификацията има промяна във вписаните за сегмент и документ обстоятелства, заявителят е длъжен да заяви тази промяна.

Ако при извършване на някоя от проверките по чл. 61 се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато документът е вече вписан, заявяването на промяна или допълване се извършва, като се посочи УРИ на документа, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

При успешни проверки по чл. 66 и 67 се проверява:

1. 1. дали услугата следва да се поддържа в съответствие с нормативната уредба и дали е допустимо статусът на услугата да бъде „използваема“; определя се „източникът“ – наименованието на стандарта, нормативният акт или друг документ, с който е въведено определението на услугата, за вписването му по партидата на обекта;
2. 2. дали наименованието на услугата е уникално по отношение на наименованията на останалите вписани услуги със статус „използваема“;
3. 3. дали е налице административна услуга, вписана в Списъка на унифицираните наименования на административните услуги, или е заявена за вписване с приложение към същото заявление, когато електронната услуга се предоставя от администрации; проверява се дали наименованието и предназначението на електронната услуга са същите като тези на административната услуга;
4. 4. дали има вписан или заявен за вписване с приложение към същото заявление сегмент, с който се представят данните в заявлението за електронната услуга; ако няма, проверява се дали закон предвижда особена форма за заявяване на електронната услуга;
5. 5. дали заявлението, съответно отговорите по услугата, отговарят на изискванията на нормативната уредба по отношение на предоставянето на конкретната услуга;
6. 6. дали е вписано сертифицирано приложение в списъка на сертифицираните информационни системи, даващо възможност за пълно, точно и вярно редактиране на съдържанието на данните в заявлението за електронната услуга; тази проверка не се прави, ако закон предвижда особена форма за заявяване на електронната услуга; ако заявителят е посочил, че такова приложение е в процес на сертификация, се проверява дали посоченото акредитирано лице е започнало сертификацията; в този случай за статус на услугата се посочва „приложение за редактиране в процедура по сертификация“; Съветът по вписванията служебно следи за сертификацията на приложението; ако поради сертификацията има промяна във вписаните за услугата и съответстващите информационни обекти обстоятелства, заявителят е длъжен да заяви тази промяна;
7. 7. дали има вписани или заявени за вписване с приложения към същото заявление документи, с които се представят данните в отговор по заявена електронна услуга или когато резултатът от изпълнението на услугата е административен акт, изразяващ се в действие по вписване в публичен регистър, дали е посочен уникалният регистров идентификатор на регистъра, в който се извършва вписването; проверява се списъкът с документи – отговори за наличие на дублиран документ; при липса на такъв се проверява дали нормативен акт не предвижда особена форма за отговор на електронната услуга;
8. 8. дали има вписан или заявен за вписване с приложение към същото заявление документ, с който се отказва извършването на електронната услуга; при липса на такъв се прави проверка дали съгласно нормативната уредба за административната услуга не може да се прави отказ;
9. 9. ако услугата е вътрешна електронна административна услуга, се проверява дали нормативен акт определя само определен кръг от лица по чл. 2, ал. 1 ЗЕУ да имат право на достъп до данните, предоставяни с нея; в този случай се определя списъкът от лицата, нормативният акт и условията, при които могат да ги получат;
10. 10. дали в списъка с доставчици е посочен поне един доставчик на електронната услуга;
11. 11. ако заявената услуга се предоставя от повече от едно лице по чл.2, ал. 1 ЗЕУ, се прави съгласуване с представители на групите лица по чл. 2, ал. 1 ЗЕУ;
12. 12. в случай, че има вече вписана услуга със същото съдържание, се допълва само списъкът с доставчици на услугата; ако услугата се заяви с различно съдържание, за нея се прилагат резултатите от съгласуването при първоначалното вписване или по преценка на Съвета по вписванията се прави ново съгласуване;
13. 13. при заявено вписване на комплексна услуга се проверява дали в описанието на комплексната услуга са посочени УРИ на всички услуги, които участват в описанието на процедурите за предоставянето на комплексната услуга.

Ако при извършване на някоя от проверките по предходния член се установи несъответствие, на заявителя се изпраща съобщение за отстраняването му.

Когато услугата е вече вписана, заявяването на промяна или допълване се извършва, като се посочи УРИ на услугата, а за обстоятелството, което се променя, се въвежда пълното съдържание, което следва да бъде вписано. В този случай проверките се извършват само по отношение на променените и допълнените обстоятелства.

По смисъла на тази инструкция използваните думи и изрази имат следното значение: 1. „Енкодинг“ е кодова таблица, определяща съответствието между даден набор от символи и съответстващия на всеки символ числен код. 2. „Фасет“ е понятие, част от XML Schema стандарта, което задава определен вид ограничение за дефиниция на тип, базиран на вече дефиниран тип.

Инструкцията се приема на основание чл. 10 от Наредбата за регистрите на информационните обекти и на електронните услуги, приета с ПМС № 98 от 2008 г. (обн., ДВ, бр. 48 от 2008 г.; изм., бр. 58 и 102 от 2010 г.).

към чл. 1, ал. 2 Критерии за формиране наименованията и конструкцията на данните на дефинициите на информационните обекти в XML формат I. Общи изисквания 1. За описание на XML структурата на информационните обекти трябва да се използва стандартът XML Schema Definition Language (XSD) 1.0, основан на Препоръка XML Schema на Работна група „XML Schema Working Group“ на консорциума W3C. Допълнителна информация: Вж. http://www.w3.org/XML/Schema Допълнителна информация: Вж. http://www.w3.org/XML/Schema 2. Обстоятелството „XML дефиниция“ на всеки един информационен обект от вид „номенклатура“, „стойност“ и „сегмент“ трябва да съдържа добре формиран и валиден XML Schema документ. В случай че се използват дефиниции на други информационни обекти, тези обекти трябва да са вече вписани в регистъра на информационните обекти или да са обекти, заявени за вписване със същото заявление. 3. За енкодинг на XML дефиницията трябва да се използва UTF-8: Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema ...... Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema ...... UTF-8 е Unicode базиран енкодинг, който позволява използване на всички букви не само от българския език, но от всички езици, които се поддържат от него. 4. За всеки глобален тип и глобален елемент в рамките на XML дефиницията трябва да е предоставено описание на български език, поясняващо предназначението на съответния тип или елемент. Описанието трябва да е предоставено чрез използването на „documentation“ елемент в рамките на „annotation“ елемента, определен от XML Schema стандарта. Атрибутът „xml:lang“ на елемента „documentation“ трябва да присъства задължително със стойност „bg“. Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000022“ 3 xmlns=“http://ereg.egov.bg/value/0008-000022“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“pseudonim“> 9 <xsd:annotation> 10 <xsd:documentation xml:lang=“bg“>Псевдоним на регистрирано → физическо лице 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:string“/> 14 </xsd:simpleType> 15 </xsd:schema> Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000022“ 3 xmlns=“http://ereg.egov.bg/value/0008-000022“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“pseudonim“> 9 <xsd:annotation> 10 <xsd:documentation xml:lang=“bg“>Псевдоним на регистрирано → физическо лице 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:string“/> 14 </xsd:simpleType> 15 </xsd:schema> II. Изисквания към типовете данни 1. В XML дефиницията на един информационен обект трябва да се използват типове данни, които възможно най-точно описват характера на данните, съдържащи се в информационния обект: а) за описание на дати трябва да се използва вграденият в XML Schema тип „date“ или производен на него; б) за описание на дати с час трябва да се използва вграденият в XML Schema тип „datetime“ или производен на него; в) за описание на числени обекти трябва да се използват вградените в XML Schema типове „decimal“, „float“ или „double“ или производни на тях. 2. XML дефиницията на информационен обект от вид „номенклатура“ трябва да съдържа на глобално ниво дефиницията на един прост тип („simpleType“), производен от вградения в XML Schema тип „string“. Допълнително XML дефиницията може да съдържа и декларацията на един елемент от този тип. Типът трябва да съдържа списъка от уникалните регистрови идентификатори (УРИ) на термините в състава на номенклатурата. Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/nomenclature/0007-000022“ 3 xmlns=“http://ereg.egov.bg/ nomenclature/0007-000022“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“Gender“> 9 <xsd:annotation> 10 <xsd:documentation>Пол на физическо лице 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:string“> 14 <xsd:enumeration value=“0006-000003“/> 15 <xsd:enumeration value=“0006-000004“/> 16 <xsd:enumeration value=“0006-000005“/> 17 </xsd:restriction> 18 </xsd:simpleType> 19 </xsd:schema> Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/nomenclature/0007-000022“ 3 xmlns=“http://ereg.egov.bg/ nomenclature/0007-000022“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“Gender“> 9 <xsd:annotation> 10 <xsd:documentation>Пол на физическо лице 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:string“> 14 <xsd:enumeration value=“0006-000003“/> 15 <xsd:enumeration value=“0006-000004“/> 16 <xsd:enumeration value=“0006-000005“/> 17 </xsd:restriction> 18 </xsd:simpleType> 19 </xsd:schema> 3. XML дефиницията на информационен обект от вид „стойност“ трябва да съдържа на глобално ниво дефиницията на един тип от изброените по-долу варианти. Допълнително XML дефиницията може да съдържа и декларацията на един елемент от този тип: а) прост тип („simpleType“): Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000033“ 3 xmlns=“http://ereg.egov.bg/value/0008-000033“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“Age“> 9 <xsd:annotation> 10 <xsd:documentation>Възраст на физическо лице 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:integer“> 14 <xsd:minInclusive value=“0“/> 15 <xsd:maxInclusive value=“150“/> 16 </xsd:restriction> 17 </xsd:simpleType> 18 </xsd:schema> Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000033“ 3 xmlns=“http://ereg.egov.bg/value/0008-000033“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“Age“> 9 <xsd:annotation> 10 <xsd:documentation>Възраст на физическо лице 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:integer“> 14 <xsd:minInclusive value=“0“/> 15 <xsd:maxInclusive value=“150“/> 16 </xsd:restriction> 17 </xsd:simpleType> 18 </xsd:schema> б) съставен тип („complexType“), определящ празен елемент: Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000034“ 3 xmlns=“http://ereg.egov.bg/value/0008-000034“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:complexType name=“EmptyType“> 9 <xsd:annotation> 10 <xsd:documentation>Пример за празен елемент 11 </xsd:documentation> 12 </xsd:annotation> 13 </xsd:complexType> 14 </xsd:schema> Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000034“ 3 xmlns=“http://ereg.egov.bg/value/0008-000034“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:complexType name=“EmptyType“> 9 <xsd:annotation> 10 <xsd:documentation>Пример за празен елемент 11 </xsd:documentation> 12 </xsd:annotation> 13 </xsd:complexType> 14 </xsd:schema> в) съставен тип („complexType“), определящ елемент само с текст: Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000035“ 3 xmlns=“http://ereg.egov.bg/value/0008-000035“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:complexType name=“TextOnlyType“> 9 <xsd:annotation> 10 <xsd:documentation>Пример за елемент, съдържащ само текст 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:simpleContent> 14 <xsd:extension base=“xsd:unsignedByte“> 15 <xsd:attribute name=“used“/> 16 </xsd:extension> 17 </xsd:simpleContent> 18 </xsd:complexType> 19 </xsd:schema> Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000035“ 3 xmlns=“http://ereg.egov.bg/value/0008-000035“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:complexType name=“TextOnlyType“> 9 <xsd:annotation> 10 <xsd:documentation>Пример за елемент, съдържащ само текст 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:simpleContent> 14 <xsd:extension base=“xsd:unsignedByte“> 15 <xsd:attribute name=“used“/> 16 </xsd:extension> 17 </xsd:simpleContent> 18 </xsd:complexType> 19 </xsd:schema> 4. XML дефиницията на информационен обект от вид „сегмент“ трябва да съдържа на глобално ниво дефиницията на един или повече съставни типа („complexType“). Допълнително XML дефиницията може да съдържа и декларацията на един елемент от един от тези типове. 5. Списъци, които съдържат йерархия или код, трябва да се заявят за вписване като пакет от данни в регистъра на регистрите и данните. 6. Списъци, които не съдържат йерархия или код, трябва да се заявят за вписване като номенклатури. По изключение такъв списък може да се заяви за вписване като информационен обект от вид стойност. III. Конвенция за именуване 1. Имената на типове или елементи в XML дефинициите на информационните обекти трябва да включват символи само от следния набор: а) „A – Z“ – големи букви от латинската азбука; б) „a – z“ – малки букви от латинската азбука; в) „0 – 9“ – цифри от 0 до 9; г) „–“ – тире; д) „.“ – точка; е) „_“ – знак за подчертаване. Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000022“ 3 xmlns=“http://ereg.egov.bg/value/0008-000022“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“pseudonim“> 9 <xsd:annotation> 10 <xsd:documentation>Псевдоним на регистрирано физическо лице 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:string“/> 14 </xsd:simpleType> 15 </xsd:schema> Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000022“ 3 xmlns=“http://ereg.egov.bg/value/0008-000022“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“pseudonim“> 9 <xsd:annotation> 10 <xsd:documentation>Псевдоним на регистрирано физическо лице 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:string“/> 14 </xsd:simpleType> 15 </xsd:schema> 2. Пространството от имена на самата XML Schema („http://www.w3.org/2001/XMLSchema“) трябва да се използва с префикса „xsd“. Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000022“ 3 xmlns=“http://ereg.egov.bg/value/0008-000022“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 ........... Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000022“ 3 xmlns=“http://ereg.egov.bg/value/0008-000022“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 ........... IV. Изисквания към пространствата от имена (namespaces) 1. XML дефиницията на всеки информационен обект трябва да определя собствено, уникално пространство от имена („namespace“). Начинът на формиране на пространството от имена се определя по следния начин, в зависимост от вида на информационния обект: (по-долу <objectURI> е уникалният регистров идентификатор (УРИ) на съответния информационен обект): а) за информационен обект от вид „номенклатура“ пространството от имена има вида: http://ereg.egov.bg/nomenclature/<objectURI>, например за номенклатура с УРИ 0007-000041 пространството от имена е http://ereg.egov.bg/nomenclature/0007-000041; Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/nomenclature/0007-000041“ ... Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/nomenclature/0007-000041“ ... б) за информационен обект от вид „стойност“ пространството от имена има вида: http://ereg.egov.bg/value/<objectURI>, например за стойност с УРИ 0008-000276 пространството от имена е http://ereg.egov.bg/value/0008-000276; Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000276“ ... Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/value/0008-000276“ ... в) за информационен обект от вида „сегмент“ пространството от имена има вида: http://ereg.egov.bg/segment/<objectURI>, например за сегмент с УРИ 0009-000203 пространството от имена е http://ereg.egov.bg/segment/0009-000203. Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/segment/0009-000203“ ... Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/segment/0009-000203“ ... 2. При заявления за вписване на нов информационен обект неговият УРИ е все още неопределен. В тези случаи в описанието на пространството от имена, свързано със заявения за вписване обект, се използва поредният номер на информационния обект в заявлението за вписване във формата „R-<NNNN>“, където <NNNN> e поредният номер на информационния обект в заявлението. Например: http://ereg.egov.bg/nomenclature/R-0023 http://ereg.egov.bg/value/R-0034 http://ereg.egov.bg/segment/R-0012 Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/segment/R-0023“ ... Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/segment/R-0023“ ... 3. Горните правила за определяне на пространството от имена не се прилагат, когато вписваните схеми на информационни обекти са предмет на авторско право или по друга причина не допускат използването им чрез пространство на имена, различно от оригиналното. Изключение са и служебните пространства от имена „http://www.w3.org/2001/XMLSchema“ и „http://www.w3.org/2001/XMLSchema-instance“. V. Референции към други информационни обекти 1. XML дефинициите на вече вписани в регистрите други информационни обекти, използвани в дефинициите на даден информационен обект, трябва да се включват чрез използване на XML Schema елемента <import>: Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/segment/0009-000090“ 3 xmlns=“http://ereg.egov.bg/segment/0009-000090“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 xmlns:m=“http://ereg.egov.bg/value/0008-000004“ 6 elementFormDefault=“qualified“ 7 attributeFormDefault=“unqualified“> 8 9 <xsd:import namespace=“http://ereg.egov.bg/value/0008-000004“> 10 ………… Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/segment/0009-000090“ 3 xmlns=“http://ereg.egov.bg/segment/0009-000090“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 xmlns:m=“http://ereg.egov.bg/value/0008-000004“ 6 elementFormDefault=“qualified“ 7 attributeFormDefault=“unqualified“> 8 9 <xsd:import namespace=“http://ereg.egov.bg/value/0008-000004“> 10 ………… 2. При използването на „import“ елемента не трябва да присъства атрибутът „schemaLocation“. 3. В случай на необходимост от рефериране на информационен обект, заявен за вписване със същото заявление, в XML дефинициите вместо УРИ на реферирания обект трябва да се използва поредният номер на този обект от заявлението за вписване чрез следния формат: „R-<NNNN>“, където <NNNN> e поредният номер на информационния обект в заявлението за вписване. Например: нов информационен обект от тип „стойност“ с пореден номер в заявлението „15“ се реферира чрез следното пространство от имена: http://ereg.egov.bg/value/R-0015 Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/segment/R-0012“ 3 xmlns=“http://ereg.egov.bg/segment/R-0012“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 xmlns:m=“http://ereg.egov.bg/value/R-0015“ 6 elementFormDefault=“qualified“ 7 attributeFormDefault=“unqualified“> 8 9 <xsd:import namespace=“http://ereg.egov.bg/value/R-0015“> 10 ………… Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/segment/R-0012“ 3 xmlns=“http://ereg.egov.bg/segment/R-0012“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 xmlns:m=“http://ereg.egov.bg/value/R-0015“ 6 elementFormDefault=“qualified“ 7 attributeFormDefault=“unqualified“> 8 9 <xsd:import namespace=“http://ereg.egov.bg/value/R-0015“> 10 ………… 4. Ако в XML дефиницията на номенклатура се използват термини, заявени за вписване със същото заявление, то вместо УРИ на съответния термин се използва форматът „R-<NNNN>“, където <NNNN> e поредният номер на термина в заявлението за вписване. Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/nomenclature/R-0043“ 3 xmlns=“http://ereg.egov.bg/ nomenclature/R-0043“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“PropertyType“> 9 <xsd:annotation> 10 <xsd:documentation>Вид на имот 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:string“> 14 <xsd:enumeration value=“R-0040“/> 15 <xsd:enumeration value=“R-0041“/> 16 <xsd:enumeration value=“R-0042“/> 17 </xsd:restriction> 18 </xsd:simpleType> 19 </xsd:schema> Пример: 1 <?xml version=“1.0“ encoding=“UTF-8“?> 2 <xsd:schema targetNamespace=“http://ereg.egov.bg/nomenclature/R-0043“ 3 xmlns=“http://ereg.egov.bg/ nomenclature/R-0043“ 4 xmlns:xsd=“http://www.w3.org/2001/XMLSchema“ 5 elementFormDefault=“qualified“ 6 attributeFormDefault=“unqualified“> 7 8 <xsd:simpleType name=“PropertyType“> 9 <xsd:annotation> 10 <xsd:documentation>Вид на имот 11 </xsd:documentation> 12 </xsd:annotation> 13 <xsd:restriction base=“xsd:string“> 14 <xsd:enumeration value=“R-0040“/> 15 <xsd:enumeration value=“R-0041“/> 16 <xsd:enumeration value=“R-0042“/> 17 </xsd:restriction> 18 </xsd:simpleType> 19 </xsd:schema> VI. Ограничения в използването на възможни конструкции от XML Schema 1. Не се допуска използването на възможността, предоставена от XML Schema стандарта, за предефиниране на типове чрез употребата на „redefine“ елемента от XML Schema. 2. Не се допуска използването на възможностите, предоставени от XML Schema стандарта, за заместване на вече декларирани елементи с други елементи в рамките на дефинираните структури чрез използване на механизма „substitution groups“. 3. Не се допуска използването на атрибути, декларирани със стойности по подразбиране (use=“optional“ default=“defaultValue“). 4. Не се допуска използването на атрибути, които са декларирани едновременно като опционални и с фиксирани стойности (use=“optional“ fixed=“fixedValue“). 5. Не се допуска използването на елементи, декларирани със стойности по подразбиране (default=“defaultValue“). 6. Не се допуска използването на елементи, декларирани с фиксирани стойности (fixed=“fixedValue“). Изключение се прави в случаите, в които не е възможно в конкретен XML документ елементът да бъде използван с празна стойност (например елементът/типът на елемента със сигурност не съдържа празен низ, дефинирано чрез използване на фасета <xsd:minLength value=“1“/>).