Криво разбраната сертификация (3)

 

 (Една статия, която никой не пожела да публикува през 2010г.)

РАБОТАТА НА СЪВЕТА ПО ВПИСВАНИЯТА РЕАЛНО Е БЛОКИРАНА.

 

Но тя е блокирана и поради една друга промяна в наредбите. Това е въвеждането на задължението (чрез промяната в чл.10 на Наредбата за регистрите на информационните обекти и на електронните услуги) за използването на XSD-спецификацията при описание на XML-конструкциите на данни. Самите създатели на тази спецификация и институцията (W3C), която я поддържа и развива, никъде и никога не са твърдели, че с нея е възможно да се опишат произволни конструкции от данни, а за описание на заложена в тях семантика и дума не става.

Нещо повече, в момента има два мащабни проекта- SEMIC.eu (SEMantic Interoperability Center) на ЕС и iECM (Interoperable Enterprise Content Management) на организацията AIIM, които са си поставили за цел именно да решат проблема с формализация на описанието на семантиката на данните, но това още не е постигнато.

Но дори и да приемем неприемливия компромис със семантиката- остава проблемът с невъзможността да се описват произволни конструкции от данни. Казано по друг начин, XSD-спецификацията успешно се прилага там където ИТ-проектантите имат водеща роля при създаването на даннови конструкции. При е-Правителството тези конструкции се създават не от инженери, а от създателите на нормативните документи. Тоест, ИТ-проектантите получават като задание вече „семантично конструирани” документи.

Административната практика изобилства с примери на нормативно регламентирани документи, в които съществуването (попълването) на части от тях се управлява с условия, формулирани със съдържание на данни в други части на документите. Тези условия често пъти са твърде сложни, за да бъдат описани с XSD-спецификацията. Такива документи практически не може да бъдат описани с нея, а трудно може да се допусне, че създателите на съответния нормативен акт ще се съгласят да го променят, само защото не може да се приложи „някакъв формализъм”, наложен абсолютно безотговорно от „някой си”.

При това самото налагане на този формализъм не само не е нужно, но то не е заложено при първоначалното създаване на ЗЕУ и наредбите към него и практически не е доказана необходимостта от налагането му, за да се въвежда в последствие с  промени в нормативната уредба.

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

Парадоксалното е, че с налагането на XSD-спецификацията те косвено отново блокират възможността за извършване на каквито и да било вписвания. Внесените промени не отменят изискването, вписваните XML-дефиниции на данни да цитират, тоест да съдържат САМО вече вписани такива. Казано по друг начин, всяка конструкция която е базирана на XML-синтаксиса трябва да бъде описана, за да бъде използвана, което безусловно се отнася и за езиковите елементи на XSD-спецификацията.

Тоест, за да се впише каквато и да било данна с XSD-описание, преди нея

 

ТРЯБВА ДА СЕ ВПИШЕ ЦЯЛАТА XSD-СПЕЦИФИКАЦИЯ

 

в Регистъра на информационните обекти. Това е не само колосален труд, но е и абсолютно безсмислено. До сега МТИТС се провали при изпълнението на задължението си по цитирания по-горе §1 за извършване на начални вписвания на данни и е ясно, че вписването на XSD-спецификацията също няма да се случи. Ето защо можем да очакваме извършване на незаконосъобразни вписвания, които лесно могат да бъдат отменени с жалба до Върховния административен съд. Как тогава да разчитат на тях ИТ-специалистите, при разработване на АИС и приложения за визуализация и редактиране на електронни документи?

Между другото, налагането на XSD-спецификацията като средство за цитиране в даден сегмент на други дефиниции на данни е недомислено от където и да се погледне. Съветът по вписванията трябва да прави преглед на XSD-кода в дефиницията на данна и да оценява неговата валидност. На всеки запознат с проблема е ясно, че това означава изпълнение на специфична процедура по тестване, с което самият Съвет по вписванията въобще не е натоварен. Ако не се изпълни подобна процедура е абсолютно сигурно, че ще бъдат извършени вписвания на некачествен, а може би и грешен XSD-код.

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

От друга страна не бива да се забравя, че в Съвета по вписванията задължително участват юристи, които въобще не са задължени да познават XSD-спецификацията и естествено не я познават. Как ще четат тези юристи XSD-код, за да определят законосъобразността на състава на предложена XML‑ дефиниция?

Във връзка с казаното може да се посочи като особено интересен фактът, че на сайта на МТИТС все още може да се открият предложения за вписване, за които дори се посочва, че са приети от (предишния състав на) Съвета по вписванията. Веднага прави впечатление, че далеч преди да се внесат коментираните промени в наредбите, са предложени за вписване данни, в чиито дефиниции има XSD-код.

 

ТОВА Е В ГРУБО ПРОТИВОРЕЧИЕ СЪС ЗАКОНОДАТЕЛСТВОТО,

 

действащото по това време (още не са направени промените в трите наредби) и неясно как тогавашният Съвет по вписванията ги е приел.

Известно основание за използване на XSD-код може да се намери в издадената от Министъра на ТИТС „Инструкция за критериите и правилата за прилагането им при вписвания в регистрите на информационните обекти и електронните услуги”. Но именно въвеждането на XSD-спецификацията е в противоречие с действащото законодателство, във връзка с което една фирма подава жалба (а друга се присъединява към нея) до Върховния административен съд и той насрочва дело под номер 6339/2010 за 12.01.2011г.

Така МТИТС създаде една комплицирана обстановка, в която разработването на дефиниции на данни не беше ясно по какви критерии трябва да се извършва. Но очевидно разработчиците, предложили за вписване посочените по-горе данни са имали изпреварваща информация за предстоящите промени в законовата уредба. Явно със същата изпреварваща информация е разполагал и тогавашният Съвет по вписванията. Но това не беше съобщено на всички разработчици. Така МТИТС създаде условия на неравнопоставеност между тях, като постави под въпрос текущо реализираните проекти, а повечето от тях са по ОПАК!

Между другото, дори и бегъл преглед върху така одобрените данни за вписване би открил формални грешки, за които се сигнализира при отваряне на предложения XSD- код със стандартен XSD‑ процесор. По-подробен анализ на кода открива логически грешки, за някои данни има и противоречия с приложеното текстово описание за тях, а за други- поради раздвояване между текстови и XSD- описания се е стигнало до явна непълнота на общата им дефиниция.

Независимо от това, че за тези вписвания е посочено приемането им от (предишния състав на) Съвета по вписванията, за щастие самото вписване още не е извършено и това поне временно е успокоително. Може само да се надяваме, че новият състав на съвета няма да потвърди несъществуващата им валидност. Ако се стигне до евентуалното им вписване, не е ясно как те ще се използват от разработчиците и как ще се извършва в последствие сертификация на АИС и приложения за визуализация и редактиране на документи.

 

 

Любомир Благоев, 2010г.