Page tree
Skip to end of metadata
Go to start of metadata


Dátum zasadnutia: 19. júna 2017 

Prítomní: 

Marek Šurek (SOIT), Roman Fordinál (SOIT), Ján Tovarňák (ÚGKK SR), Antónia Vojtičková (ŠÚ SR), Rastislav Machel (MK SR), Juraj Hájek (Ardaco), Zita Šupáková (MS SR), Milan Semančák (Softec), Ladislav Janko (MH SR), Pavol Frič (Ditec), Ján Domankuš (NASES), Petra Rečná (NASES), Marek Malovec (MDVaRR SR), Milena Ficzova (Sociálna poisťovňa), Ján Rado (Sociálna poisťovňa), Martina Vrbiková (NCZI), Ivan Turčan (NESS), Anna Vančíková (MV SR), Ervín Šimko (ÚPPVII), Štefan Szilva 

Úvod 

Predseda pracovnej skupiny Ervín Šimko privítal členov pracovnej skupiny a prizvaných hostí. Pracovná skupina priamo nadväzuje na prácu pôvodnej pracovnej skupiny PS6 Komisie pre štandardizáciu pre informačné systémy verejnej správy, ktorá bola na krátke obdobie v roku 2015 premenovaná na PPS1-f a na základe rozhodnutia Komisie bola opäť označená PS6. Predseda požiadal členov, aby informácie o prerokúvaných témach a výstupoch pracovnej skupiny poskytovali členovi Komisie pre štandardizáciu, ktorý ich organizáciu zastupuje. Upozornil, že členovia skupiny majú vytvorený účet v Centrálnom metainformačnom systéme (MetaIS), k čomu dostali e-mail o aktivácii účtu s odkazom na nastavenie hesla, ktoré je potrebné nastaviť do 48 hodín, v opačnom prípade sa účet zablokuje a je potrebné následne skontaktovať ÚPPVII. MetaIS slúži ako hlavný pracovný nástroj pre pripomienkovanie dokumentov, vytváranie vlastných návrhov, zasielanie pozvánok. Požiadal členov, aby sa predstavili. 

Členovia PS6 jednohlasne súhlasili s presunutím bodu č. 4 rokovania o používaní sémantických dátových štandardov na začiatok rokovania. 

1. Používanie sémantických dátových štandardov (informácia).

Štefan Szilva informoval o ukončenom hlasovaní v PS1 o schválenej prvej verzii sémantických dátových štandardov. V ďalšej verzii, o ktorej bude PS1 hlasovať v krátkej dobe, bude riešená aj problematika prepojenia XSD na centrálny model údajov, podoba URI pre identifikátor elektronických formulárov a URI pre deklaráciu menného priestoru v XML a v XSD. V prípade záujmu o tému sa je vhodné sa zúčastňovať zasadnutí PS1. 

V roku 2015 a 2016 bol na základe §46 Výnosu o štandardoch vydaný a aktualizovaný zoznam referencovateľných identifikátorov, ktorý definoval podobu identifikátora e-formulára a menného priestoru XSD pre e-formuláre. Je plánovaný presun katalógu dátových prvkov do ontológií v OWL súboroch. 

Marek Šurek upresnil, že sa v PS1 schválila všeobecná metodika a do PS1 boli predložené 4 varianty možnosti prepojenia XSD schém s centrálnym modelom údajov. Jednotlivé dátové prvky v e-formulároch budú mať povinnosť referencovať centrálny model údajov. Výstupy z PS1 je pán Šurek ochotný prísť odprezentovať do PS6. 

Funkčné priame odkazy (URL) na jednotlivé súčasti e-formulárov - body 3.1.5 až 3.1.9 prílohy č. 3 Výnosu o štandardoch

Pán Hájek sa spýtal, od kedy je v pláne sfunkčniť referencovanie schém z e-formulárov na živých URL ako to vyžaduje Výnos o štandardoch pre účely podpisovania elektronickým podpisom. Tiež sa spýtal, čo sa v tomto smere spraví so starými e-formulármi, keďže sa v nich vyžaduje uvádzanie živej URL v atribúte full-path-url, ktorý staré e-formuláre nevyužívajú v rozpore s Výnosom. 

Pán Major doplnil, že problém je, že staré e-formuláre v atribúte full-path-url v manifest.xml neobsahujú URL a je otázka, či takéto doplnenie nebude mať za následok navýšenie verzie e-formulára. 

Pán Šurek uviedol, že referencovanie bude v PS1 riešené. Podľa neho by nemalo byť cieľom dať povinnosť gestorom prepisovať staré e-formuláre, a to z dôvodu finančnej efektivity. 

Pán Szilva požiadal o vyjadrenie pána Turčana a pána Domankuša, ktorí na predošlých zasadnutiach PS1 v roku 2015 avizovali zabezpečenie dodržiavania bodov 3.1.5 až 3.1.9 prílohy č. 3 Výnosu. 

Pán Turčan uviedol, že je naimplementované sprístupnenie schém z e-formulárov na živých linkách v zmysle Výnosu o štandardoch, avšak nie sú ešte verejne sprístupnené cez data.gov.sk. Pán Domankuš potvrdil informáciu od pána Turčana, nevie sa však vyjadriť, kedy budú schémy reálne dostupné cez data.gov.sk, môže skúsiť zistiť, kedy sa to môže zrealizovať. Je potrebné niečo upraviť infraštruktúre. Technicky by to už dnes malo byť pripravené tak, aby sa to dalo do niekoľkých mesiacov spustiť, avšak p. Domankuš nemá kompetenciu o tom rozhodovať. Pán Szilva uviedol, že v rámci úprav ÚPVS v najbližších mesiacoch by sa mohlo podariť tento problém riešiť. Aktuálne podľa informácií od Ditec funguje starý spôsob referencovania v tvare http://schemas.gov.sk/form/identifikator-formulara/verzia/form.xsd alebo .xslt. 

Pán Hájek upozornil, že tento starý spôsob funguje len v prípade integrácie s ÚPVS/MEF, nejde teda o verejne dostupné odkazy na súbory. Je zverejnený dataset, kde je zoznam všetkých e-formulárov, avšak aktualizuje sa len raz mesačne, čo je nedostatočné. Tento dataset by sa potenciálne dal použiť na vyskladanie liniek na súbory e-formulárov a tiež ako zdroj informácií o platnosti a účinnosti jednotlivých e-formulárov, o čom sa bude hovoriť v ďalších bodoch rokovania. 

Pán Šurek uviedol, že problém referencovania jednotlivých súborov e-formulárov bude potrebné riešiť centrálnym jedným spôsobom dereferenciáciou referencovateľných identifikátorov, čo sa bude riešiť v PS1. 

2. Riešenie technických problémov kontajnera pre publikáciu e-formulárov – zmena vlastností elementov a atribútov (na schválenie)

V Prílohe č. 3 Výnosu o štandardoch v bode 7 je definovaný formát pre publikáciu elektronických formulárov (e-form kontajner). Tento má v zmysle Výnosu podobu XML súboru alebo ZIP súboru a medzi týmito formami je možné robiť bezstratovú konverziu. 

I. Ako identifikovať verzie samotného e-form kontajnera, resp. podľa ktorých pravidiel boli jednotlivé e-form kontajnery vytvorené?

Navrhnuté možnosti riešenia: 

a) - vytvoriť nový atribút pre verziu kontajnera,

b) - meniť verzie v deklarácii menného priestoru pre jednotlivé súčasti kontajnera (napr. "urn:manifest:X.X", kde "X.X" je označenie verzie)

Záver

Pracovná skupina schválila záver: 

Identifikácia verzie samotného e-form kontajnera bude riešená verziou v deklarácii menného priestoru pre jednotlivé súčasti formátu e-form kontajnera (napr. "urn:manifest:X.X", urn:meta:X.X, kde "X.X" je označenie verzie), pričom všetky tieto súčasti formátu musia mať rovnakú verziu. 

V prílohe č. 3. Výnosu o štandardoch pre IS VS sa aj v prípade, že by neprišlo k zmenám pravidiel pre používanie kontajnera, zmení číslo verzie aspoň na 1.1, nakoľko pri poslednej novele nebolo číslo verzie zapracované. 

Úloha: 

Pán Hájek a pán Major zašlú pánovi Turčanovi informácie o prípadoch, kedy sa líšili súbory v e-formulári získanom cez integračné rozhranie od súborov získaných cez slovensko.sk

Diskusia 

Pán Szilva vysvetlil, že je potrebné, aby sa dalo v e-form kontajneroch jednoducho odlíšiť, ktorú novelu Výnosu z roku 2014 alebo 2015 implementujú. Vo Výnose sa zatiaľ revízie e-­form kontajnera verziami neodlíšili, keďže sa predpokladalo, že len súladné formuláre budú používať predpísaný media type a e-formuláre v MEF sa zosúladia s Výnosom. 

V MEF na ÚPVS sa pre publikáciu e-form kontajnera používa verzia 1.0 a táto iba čiastkovo implementuje staršiu verziu Výnosu o štandardoch z roku 2014, t.j. neimplementuje niektoré pravidlá a ani neskoršie novely Výnosu z roku 2014 a 2015. MEF zároveň používa media type zaregistrovaný IANA a preto sa ani s jeho pomocou nedá odlíšiť, podľa akej verzie boli e-form kontajnery vytvorené. 

Pán Fordinál, ktorý sa podieľal na prvom návrhu e-form kontajnera uviedol, že práve menný priestor v jednotlivých súčastiach e-form kontajnera je určený na odlišovanie verzií. Navrhol, aby sa verzia naraz menila v mennom priestore všetkých súčastí formátu e-form kontajnera, a to aj v prípade, ak sa niečo zmení v špecifikácii iba niektorej súčasti formátu e-formulára. Z každej súčasti tak bude možné zistiť verziu e-form kontajnera. 

Pán Major upozornil, že Výnos zatiaľ pozná iba jednu verziu a to je 1.0. Pán Szilva vysvetlil, že pri poslednej novele Výnosu o štandardoch, kedy sa menili viaceré pravidlá pre e-form kontajner, sa nezapracovalo zvýšenie verzie. Navrhol, aby sa pri ďalšej novele Výnosu vykonala zmena verzie e-form kontajnera aj v prípade, ak by sa v jeho špecifikácii nič nemenilo. 

Pán Turčan upozornil, že v prípade zvýšenia verzie vzniknú problémy v systémoch, ktoré používajú XSD schému e-form kontajnera, kde sa používa v namespace verzia 1.0, pretože tieto systémy s novou verziou nebudú vedieť pracovať. V MEF sa XML súbory tvoriace formát e-form kontajnera (manifest.xml, meta.xml, attachments.xml) neuchovávajú v podobe súborov ale len v podobe údajov v systéme MEF a XML súbory sa vytvárajú (vypočítavajú sa) na základe týchto údajov pri poskytovaní e-formulára z MEF v e-form kontajneri. 

Organizácie, ktoré sú naintegrované na MEF prichádzajú do styku s e-form kontajnerom iba ak si vyžiadajú e-formulár v e-form kontajneri definovanom podľa Výnosu. Pokiaľ tieto organizácie používajú staršie služby MEF (asi integračný manuál 7 alebo 8 MEF), tak s e-form kontajnerom do styku neprichádzajú. V MEF bol používaný iný formát pre poskytovanie e-formulárov v čase, keď ešte nebol definovaný vo Výnose formát e-form kontajnera. 

Keď sa vydávajú nové verzie e-formulárov, integrovaným subjektom chodí notifikácia z MEF. A inštitúcie si na základe notifikácie e-form kontajner s novou verziou stiahnu. 

Pán Semančák sa spýtal, či sa chcú staré e-formuláre poskytovať vo formáte nového e-form kontajnera. 

Pán Turčan uviedol, že nebude možné namiesto starého e-form kontajnera poskytovať nový e-form kontajner. Bude musieť vzniknúť ďalšia služba, ktorá bude poskytovať e-form kontajner v súlade s aktuálnym Výnosom (s novou verziou v namespace). Vďaka tomu budú musieť existovať 3 služby, keďže prvá vracia nejakú historickú formu a druhá poskytuje e-form kontajner čiastočne v súlade s Výnosom o štandardoch. 

Pán Fordinál tiež upozornil, že staré formuláre, neobsahujúce všetky predpísané údaje, by sa nemali poskytovať v e-form kontajneri vyššej verzie, preetože by neboli súladné s vyššou verziou. 

Pán Frič a pán Hájek upozornili, že sa stali viaceré prípady, keď OVM pripravil e-formulár, vypublikoval ho v MEF, avšak schémy vo vypublikovanom e-formulári boli zmenené oproti podobe zaslanej na vypublikovanie. V MEF sa nejakou transformáciou zmenili XML súbory a tým aj ich digitálny odtlačok. Niektoré OVM integrovali e-formulár, ktorý sami pripravili a to sa líšilo od toho, čo im vypublikoval MEF a to spôsobilo viaceré problémy. 

Pán Turčan uviedol, že dôvodom môže byť, ak sa e-formulár prenáša v starej forme kde je schéma vložená ako base64 a stiahne sa v XML forme, ktorá nemá base64. V base64 forme sa prenáša aj XML deklarácia ktorá v inline forme nemôže byť použitá. Napríklad vo VÚC boli používané XML formy e-form kontajnera ale museli prejsť na ZIP formu, pretože boli problémy so zmenou XML. Sú rôzne možnosti ako vypublikovať e-formulár: cez staré rozhranie, kde je možné pridávať e-formuláre cez samostatné pridávanie súborov alebo použitím starého e-form balíka, kde sa používa base64. 

Pán Hájek uviedol, že sa stali prípady, že keď cez integračné rozhranie požiadal o nejaký e-formulár, MEF vrátil iný e-form kontajner, než kontajner dostupný cez formulare.slovensko.sk. Pán Turčan požiadal pána Hájeka, aby mu e-mailom zaslal konkrétny prípad, kedy sa to stalo, lebo o takom probléme nevie. 

Pán Major potvrdil, že sa stalo, že e-form kontajner dostupný cez slovensko.sk obsahoval iné súčasti než e-form kontajner zaslaný cez integračné rozhranie. 

Pán Hájek upozornil, že vo viacerých e-formulároch, ako napríklad e-formulár Doručenky, nie sú prezentačné schémy (XSLT) ani len validné podľa XML (t.j. sú aj v rozpore so špecifikáciou XSLT). Pán Turčan uviedol, že toto je problém tvorcu e-formulára. 

Pán Frič uviedol, že v istom čase budú platiť dve alebo viaceré verzie e-formulárov a k tomu bude potrebné vypublikovať metodický pokyn pre migračný plán, aby neprestali fungovať služby z dôvodu, že e-formuláre budú neaktuálne. Uviedol, že by sa malo vyriešiť, aby na ÚPVS bol validátor, ktorý bude kontrolovať, či e-formuláre majú všetko čo majú mať, keďže dnes to často nemajú. Navrhol definovať vo Výnose o štandardoch prechodné obdobie, počas ktorého bude povinnosť zosúladiť všetky e-formuláre s Výnosom o štandardoch, pretože ponechávať staré e-formuláre v súčasnom stave považuje za tlačenie problému pred sebou. 

Pán Szilva súhlasil, avšak už bolo definované prechodné obdobie pre zosúladenie a to už uplynulo. Riešením je prechod vo Výnose na vyššiu verziu e-form kontajnera ako je 1.0 - napríklad na 1.1. 

Pán Major uviedol, že je nutné, aby sa naraz menila verzia vo všetkých súčastiach. 

II. Súhlasíte so zavedením povinného pravidla, že XML súbory v e-form kontajneri nesmú na svojom začiatku obsahovať BOM (byte order mark)?

Záver

Pracovná skupina nesúhlasí so zavedením povinného pravidla, aby XML súbory v e-form kontajneri nepoužívali BOM. 

Rovnako sa nebude zavádzať pravidlo pre odstraňovanie XML deklarácie. 

Diskusia

Pán Szilva uviedol, že XML podoba e-form kontajnera a aj jeho súčastí musí byť v zmysle IANA registrácie vždy v kódovaní UTF-8, preto nie je nutné BOM používať. So spracovaním BOM sú však podľa informácií od tvorcov niektorých aplikácií problémy, pretože niektoré aplikácie chybne vkladajú až 2x BOM a niektoré majú problém BOM vôbec spracovať. W3C špecifikácia však umožňuje používanie BOM a navrhnuté riešenie by s ňou išlo do rozporu. 

Citát zo špecifikácie W3C

"Entities encoded in UTF-16 must and entities encoded in UTF-8 may begin with the Byte Order Mark described by Annex H of [ISO/IEC 10646:2000], section 16.8 of [Unicode] (the ZERO WIDTH NO-BREAK SPACE character, #xFEFF)."

Keď tvorca e-formulára vytvára XML súbory, nerobí pred ich vypublikovaním kanonikalizáciu, vkladá ich, ako ich má - napríklad s BOM a XML deklaráciou. V XML podobe e-form kontajnera však už tieto súbory neobsahujú BOM a XML deklaráciu, čím vznikajú rozdiely. Pri opakovanej konverzii medzi ZIP a XML podobou e-form kontajnera sa už konverziou nedá obnoviť pôvodný stav, v ktorom mohol byť použitý BOM a XML deklarácia. 

Možným riešením pre schémy by mohlo byť predpísať base64 zápis pre vkladané schémy alebo predpísať povinnosť odstraňovať BOM resp. robiť kanonikalizáciu pred vypublikovaním a stanoviť konkrétny algoritmus. Nie je to však riešením pre súbory meta.xml, manifest.xml a attachments.xml, ktoré sú v XML podobe e-form kontajnera vždy integrované a nemôžu používať base64. 

Pán Turčan uviedol, že v prípade XML podoby e-form kontajnera je pre XML súbory predpísaná priama integrácia a v nej sa nedá vložiť BOM a ani XML deklarácia. Riešením by bolo povolenie base64. 

Pán Hájek uviedol, že kanonikalizáciu majú potrebu používať asi len podpisovacie aplikácie, robiť kanonikalizáciu pre všetky XML preto nepovažuje za potrebné. Kanonikalizácia pri podpisovaní zabezpečuje, aby sa odstránil BOM a všetky prázdne znaky a preto po kanonikalizácii pri porovnávaní súborov musí vyjsť rovnaký digitálny odtlačok. Výnos o štandardoch nemôže riešiť to, že niekomu chýba nejaká časť impelementácie XML a má problém spracovať BOM. 

Viacerí prítomní súhlasili, že nie je vhodné ísť do rozporu s W3C špecifikáciou. Pán Fordinál uviedol, že po kanonikalizácii musí vyjsť rovnaký výsledok z XML podoby e-form kontajnera (bez ohľadu na to, či je použité base64) a aj zo ZIP podoby. 

Pán Major uviedol, že v prípade ak je XML súbor integrovaný v XML podobe e-form kontajnera, môže sa líšiť od pôvodného XML súboru. Stretli sa však aj s prípadmi, kedy ani po konanonikalizácii súbor schémy v e-form kontajneri nebol totožný medzi ZIP a XML podobou e-form kontajnera. Viacerí prítomní takú možnosť spochybnili, pán Major však uviedol, že vnikli aj situácie, ktoré kanonikalizácia neriešila. 

Z diskusie vyplynulo, že implementátori si musia byť vedomí, že súbory môžu obsahovať BOM a XML deklaráciu a musia používať kanonikalizáciu, ak chcú porovnávať digitálny odtlačok XML súborov priamo integrovaných v XML podobe e-form kontajnera so súborom v ZIP podobe kontajnera. 

III. Používanie base64 a definovanie elementu "xsd" v kontajneri pre publikovanie e-formulárov

Súhlasíte s tým, aby bolo možné XSD schému v XML verzii e-form kontajnera vkladať vo formáte base64, teda nie priamou integráciou?

Súhlasíte s tým, aby pre vkladanie XSD schémy (súbor schema.xsd) do XML verzie e-form kontajnera bol definovaný nový nadradený element „xsd“, čím sa umožní vkladanie schémy v base64 formáte?

Záver

Pracovná skupina predbežne nesúhlasila s používaním base64 formátu namiesto priamej integrácie. Navrhuje súvisiace problémy riešiť vypustením XML podoby kontajnera pre publikáciu elektronických formulárov z Výnosu o štandardoch pri ďalšej novele. 

Diskusia k téme: base64 

Pán Turčan uviedol, že v prípade ak kanonikalizácia vracia vždy rovnaký výsledok aj v prípade ak je v jednom súbore BOM a v druhom nie alebo v prípadoch ak je rozdiel len v bielych znakoch, tak nevidí dôvod na používanie base64. Navrhuje zistiť, v čom je presne problém a až potom riešiť, či používať base64. 

Pán Fordinál uviedol, že používanie base64 nepovažuje za dobré. 

Pán Hájek uviedol, že je treba hľadať systémové riešenie. Ak problém nie je v kanonikalizácii, tak base64 nič nerieši. 

Pán Semančák uviedol, že v MEF sa dnes robí neštandardný zásah do XML súborov (vyhadzuje sa BOM a XML deklarácia), aby sa XML súbory mohli publikovať v XML podobe e-form kontajnera. Keď bude použité base64, nie je potrebné nič takéto robiť. Podpisovač má riešenú kanonikalizáciu, ktorá rieši BOM a XML deklarácie. 

Pán Turčan a pán Major uviedli, že boli prípady, kedy po kanonikalizácii nebol rovnaký výsledok. 

Pán Domankuš uviedol, že v MEF sa nerobila kanonikalizácia pri publikovaní XML súborov v XML podobe e-form kontajnera. Odstraňoval sa len BOM a XML deklarácia. 

Pán Semančák uviedol, že práve toho sa desí, že sa robia nejaké neštandardné zásahy do XML súborov na to, aby sa publikovali v XML podobe e-form kontajnera. Práve preto považuje za vhodné použiť base64, aby sa nerobili takéto zásahy. 

Pán Turčan uviedol, že e-form dizajnér nedokáže vytvárať balíky podľa Výnosu o štandardoch, vytvára staré balíky, ktoré boli definované pred štandardizáciou cez Výnos o štandardoch. 

IV. Vypustenie XML podoby e-form kontajnera

Záver

Pracovná skupina predbežne súhlasila s vypustením XML podoby kontajnera pre publikáciu elektronických formulárov z Výnosu o štandardoch pri ďalšej novele a zachovaním iba ZIP podoby tohto kontajnera. 

Členovia PS6 preveria, či zrušenie XML podoby kontajnera nespôsobí v nejakých systémoch problémy. 

Téma bude predmetom ďalšieho zasadnutia PS6. 

Diskusia

Pán Fordinál navrhol vypustiť XML podobu e-form kontajnera. Pán Semančák navrhol preferovať jednu z foriem - XML podobu alebo ZIP podobu a jednu z nich označiť za "obsoletnú" a v najbližších verziách ju vyhodiť. V prípade vypustenia by sa mohla verzia e-form kontajnera zdvihnúť na 2.0. 

Pán Szilva uviedol, že dôvod, prečo sa vo Výnose definovala XML podoba e-form kontajnera bola tá, že ÚPVS v minulosti používal XML podobu a na začiatku chceli zostať na XML štruktúre. 

Pán Turčan uviedol, že XML formu už podľa jeho poznatkov asi nikto nepoužíva. 

Pán Fordinál navrhol, aby sa vypustenie XML formy zvážilo a predložilo do ďalšieho zasadnutia PS6. 

Pán Domankuš uviedol, že vo vypustení XML podoby nevidí problém. V systémoch ÚPVS sa nepracuje s XML podobou e-form kontajnera. 

Pán Turčan uviedol, že vo Výnose boli iba popísané schémy pre e-form kontajner. Referenčné schémy pre ÚPVS však vytvoril pán Turčan. V novele Výnosu o štandardoch je podľa neho potrebné doplniť realistické schémy pre všetko, pretože vypublikované vo Výnose neboli ani validné XML súbory, pravdepodobne kvôli preklepom. Jeho schémy však nepočítajú napríklad s možnosťou, že "media-destination" obsahuje viacero hodnôt oddelených čiarkou a aj preto bude potrebný update. 

Pán Szilva požiadal členov, aby preverili, či vypustenie XML podoby nespôsobí vážne dopady, aby sa téma znova neotvárala v MPK k novele Výnosu. 

V. Validácia e-formulárov 

Záver

Pracovná skupina navrhuje, aby modul elektronických formulárov automaticky kontroloval súlad elektronického formulára s Výnosom o štandardoch pre IS VS a to ešte pred jeho vypublikovaním, pričom tvorca e-formulára musí byť upozornený na konkrétne chyby. Prípustnosť chýb bude predmetom ďalších rokovaní PS6. 

Pracovná skupina navrhuje, aby validátor elektronických formulárov bol spolu s podrobnou dokumentáciou poskytovaný ako verejne dostupná služba na ÚPVS. 

Je potrebné, aby právnici preverili, či môže MEF nevypublikovať e-formulár, ktorý nie je úplne dokonale v súlade so štandardami a to aj v najmenších detailoch, ktoré nemusia ovplyvňovať funkčnosť e-formulára avšak Výnos ich vyžaduje. 

Diskusia

Pán Hájek navrhol, aby bol online dostupný validátor kontajnera pre publikáciu e-formulárov bez nutnosti vypublikovať e-formulár. 

Pán Turčan uviedol, že v MEF je validátor, ktorý bol zapnutý, avšak neskôr sa vypol. Vhodné by bolo, aby po zaregistrovaní e-formulára prišlo do schránky gestora, aké konkrétne technické chyby v e-formulári sú a že je ich potrebné opraviť. 

Pán Frič navrhol, aby validátor bol tak striktný, že nepustí nič, čo je v rozpore s Výnosom. Keď MEF poskytne e-formulár, ktorý je v technickom rozpore so štandardami a v dôsledku toho vznikne problém alebo škoda, kto za to bude zodpovedať? 

Pán Szilva uviedol, že zodpovednosť za e-formulár nesie gestor a nie MEF. 

Pán Machel a aj pán Semančák vyjadrili názor, že MEF by nemal vypublikovať e-formulár, ktorý nie je v súlade so štandardami. 

Pán Semančák uviedol, že už dnes sa na ÚPVS v niektorých prípadoch blokuje vypublikovanie e-formulárov. 

Pán Szilva uviedol, že podľa zákona gestor publikuje e-formulár prostredníctvom funkčnosti MEF. V roku 2013 bola v PS6 diskusia o tom, či zákon umožňuje nevypublikovať e-formulár, ak nespĺňa nejaké ustanovenia Výnosu. (Išlo o rokovanie konané vtedy v Globaltel a zúčastniť sa mohla PS6.) Vtedy sa aj za účasti predsedu PS6 prišlo k záveru, že to zákon neumožňuje. Je na diskusiu právnikov, či môže MEF nevypublikovať e-formulár, ktorý nie je úplne dokonale v súlade so štandardami a to aj v najmenších detailoch, ktoré nemusia ovplyvňovať funkčnosť e-formulára avšak Výnos ich vyžaduje. Funkčnosť MEF môže niečo kontrolovať, avšak je otázka, či môže nevypublikovať e-formulár. Pracovná skupina PS6 by mohla na ďalších zasadnutiach riešiť, aká je nevyhnutná miera súladu so štandardom, kedy by sa e-formulár ešte mohol stopnúť pred vypublikovaním. 

Pán Frič uviedol, že Výnos o štandardoch definuje, čo je elektronický formulár a keď niečo nevyhovuje štandardu, nemôže to MEF vypublikovať. 

Pán Szilva uviedol, že zákon o e-Governmente definuje, čo je elektronický formulár. Nie je v súlade so zákonom, že MEF si dáva 5 dní 

Pán Šimko uviedol, že z jeho predbežnej diskusie s pánom Kálavským (spolutvorcu ustanovenia ohľadom publikovania e-formulárov) vyplynulo, že v štandardoch by sa mali nastaviť požiadavky na nástroj pre publikovanie e-formulárov a teda aj miera pre ich akceptovanie z technického hľadiska. Prostredie pre tvorbu e-formulárov však musí byť podľa tejto informácie voľné. Bude však ešte mať samostatné stretnutie s pánom Kálavským pre ujasnenie témy. 

VI. Zmeny e-formulárov v MEF bez zmeny verzie 

Pán Turčan uviedol, že je významný problém, že MEF umožňuje zmeniť názov e-formulára bez zmeny verzie e-formulára. Táto funkčnosť v MEF stále nie je zakázaná. Elektronická podateľňa však neakceptuje zmenu názvu e-formulára. Ak je v podpise iný názov ako je v aktuálnom e-formulári, podateľňa ÚPVS označuje autorizáciu za neplatnú. 

Pán Szilva doplnil, že Výnos o štandardoch predpisuje, že akákoľvek zmena má za následok zmenu verzie e-formulára. 

Záver

ÚPVS sa musí zosúladiť s Výnosom o štandardoch účinným od 15. marca 2015 a neumožniť žiadnu zmenu e-formulára bez zmeny verzie, s výnimkou zmeny dátumu konca platnosti a konca účinnosti e-formulára. 

VII. Vypustenie elementov "inForceTo", "validDateTo" zo súboru meta.xml 

Súhlasíte s vypustením elementov "inForceTo", "validDateTo" zo súboru meta.xml v e-form kontajneri a s jeho presunutím do samostatného súboru obsahujúceho popisné informácie o e-formulári?

(Ide o úpravu bodu 7.6.4 Prílohy č. 3 Výnosu o štandardoch č. 55/2014 Z.z. ) 

Záver

Pracovná skupina súhlasila s vypustením elementov "inForceTo", "validDateTo" zo súboru meta.xml v e-form kontajneri pod podmienkou ich presunutia do externých zdrojov informácií, ktoré budú technicky riešené na ďalších zasadnutiach PS6. 

Zároveň bude pracovná skupina zvažovať aj presun ďalších metaúdajov z e-form kontajnera, najmä "inForceFrom" a "validDateFrom". 

V bode 7.6.4 Prílohy č. 3 Výnosu o štandardoch pre IS VS č. 55/2014 Z.z. sa vypúšťajú písmená I) a k).

Citát pôvodného znenia: 

7.6.4 Dátové prvky súboru „meta.xml“ obsahujú

a) v „dc:title“ názov elektronického formulára podľa bodu 2.2.1 písm. a),

b) v „dc:identifier“ identifikátor elektronického formulára podľa bodu 2.2.1 písm. b),

c) v „dc:description“ opis účelu elektronického formulára podľa bodu 2.2.1 písm. c),

d) v „dc:creator“ poskytovateľa elektronického formulára podľa bodu 2.2.1 písm. d),

e) v „dc:publisher“ gestora elektronickej služby podľa bodu 2.2.1 písm. e),

f) v „language“ jazyk podľa bodu 2.2.1 písm. f),

g) vo „version“ verziu podľa bodu 2.2.1 písm. g),

h) vo „validDateFrom“ dátum začiatku platnosti podľa bodu 2.2.1 písm. h),

i) vo „validDateTo“ dátum skončenia platnosti podľa bodu 2.2.1 písm. i),

j) vo „inForceFrom“ dátum začiatku účinnosti podľa bodu 2.2.1 písm. j),

k) vo „inForceTo“ dátum skončenia účinnosti podľa bodu 2.2.1 písm. k).

VIII. POSP.xml

MEF pre niektoré formy publikácie elektronických formulárov vyžaduje povinné použitie súboru POSP.xml v e-form kontajneri, pričom tento súbor neprešiel štandardizáciou a v zmysle Výnosu o štandardoch nie je povinný a preto nemôže byť vyžadovaný. 

Záver

Pracovná skupina súhlasila, že informačné systémy nemôžu vyžadovať, aby vo vypublikovaných elektronických formulároch (v e-form kontajneri) bol povinne prítomný súbor POSP.xml, nakoľko tento neprešiel štandardizáciou a v zmysle Výnosu o štandardoch pre IS VS. Pracovná skupina prijala záver, že informácie v súbore POSP.xml nemajú byť súčasťou e-form kontajnera a majú byť prednostne evidované v MetaIS, keďže popisujú najmä vlastnosť elektronickej služby. 

IX. Prezentácia identifikačných údajov

Súhlasíte s tým, aby identifikačné údaje e-formulára museli byť súčasťou prezentácie a teda napevno zapísané v prezentačnej schéme?

Záver

Všetci členovia PS6 do ďalšieho zasadnutia zanalyzujú úpravu bodu 4.7.3 a 2.2.1 prílohy č. 3 Výnosu o štandardoch a teda úpravu povinnosti, aby všetky identifikačné údaje museli byť súčasťou prezentácie e-formulára.  

X. viacjazyčné meta.xml

(V zmysle záverov PS6 z 26. júna 2015)

Súhlasíte s doplnením nasledovného pravidla do prílohy č. 3 Výnosu? 

"V prípade ak elektronický formulár poskytuje prezentačné schémy v rôznych jazykoch, uvádza sa hodnota dátových prvkov dc:title, dc:description, dc:creator, dc:publisher v štátnom jazyku a zároveň sa uvádza aj v príslušnom cudzom jazyku, pričom jazyk použitý v týchto dátových prvkoch sa v takom prípade uvádza v atribúte "xml:lang" s hodnotou podľa základného číselníka CL010076 Jazyky.

Viacnásobné použitie iných dátových prvkov nie je dovolené. Použitie atribútu "xml:lang" je nepovinné, ak sú jazykové varianty elektronického formulára poskytované samostatnými elektronickými formulármi."

Poznámka: Dublin Core priamo definuje používanie xml:lang, čiže by ho malo byť možné používať už dnes, avšak musí to byť podporované aj v implementáciách e-form kontajnera.

Návrh na úpravu Príkladu v bode 7.6.2 prílohy č. 3 Výnosu:

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

<metadata

xmlns="urn:meta:1.0"

xmlns:dc="http://purl.org/dc/elements/1.1/">

<dc:title xml:lang="sk">Názov elektronického formulára</dc:title>

<dc:title xml:lang="en">Name of the electronic form</dc:title>

<dc:identifier>http://data.gov.sk/doc/eform/ico.</dc:identifier>

<dc:description xml:lang="sk">Opis účelu elektronického formulára</dc:description>

<dc:description xml:lang="en">Description of the e-form purpose</dc:description>

<dc:creator xml:lang="sk">Poskytovateľ elektronického formulára - napr.Ministerstvo financií SR</dc:creator>

<dc:creator xml:lang="en">Creator of the electronic form - e.g. Ministry of the finance of the Slovak republic</dc:creator>

<dc:publisher xml:lang="sk">Gestor elektronického formulára</dc:publisher>

<dc:publisher xml:lang="en">Manager of the electronic form</dc:publisher>

<version>1.0</version>

<language></language>

<validDateFrom>2015-01-01</validDateFrom>

<validDateTo>2015-01-01</validDateTo>

<inForceFrom>2020-01-01</inForceFrom>

<inForceTo>2020-01-01</inForceTo>

</metadata>

 

Záver

Pracovná skupina súhlasila s predloženým návrhom. 

Súhlasila s používaním viacerých jazykov v súbore meta.xml v e-form kontajneri a to s pomocou štandardného atribútu "xml:lang". Ďalšie využívanie súboru meta.xml a jeho prípadný presun mimo e-form kontajner bude predmetom ďalších rokovaní PS6.

XI. PDF verzia tlačovej prezentácie

Súhlasíte s pridaním nového atribútu v manifest.xml v e-form kontajneri pre identifikáciu verzie PDF, ktorá sa vytvorí prezentačnou schémou pre tlač?

Súhlasíte so zavedením povinnosti, aby tlačová prezentačná schéma musela byť v súlade s PDF/A-1? 

Záver

Pracovná skupina predbežne nesúhlasila s týmto návhrom. 

Diskusia

Pán Szilva vysvetlil, že návrh vznikol v roku 2016 po diskusii s pánom Turčanom. Jeho účelom je definovať, do akej verzie a subsetu PDF má XSL-FO referenčný procesor Apache FOP skonvertovať súbor XSL-FO.

Pán Hájek a pán Semančák vyjadrili obavy, že takéto predpísanie verzie by mohlo spôsobiť problémy a kontroly validnosti voči konkrétnej verzii PDF, s čím sú už zbytočné problémy pri podpisovaných súboroch PDF/A-1a. Prípadné elektronické podpisovanie tlačovej prezentačnej schémy nepovažujú za vhodné, keďže táto nie je určená na účel podpisovania.

Pán Szilva uviedol, že v prípade, ak by bola prezentačná schéma do formátu PDF definovaná ako podpisová, mohla by sa používať na podpisovanie. Uviedol, že niektoré OVM majú v praxi tendenciu vydávať rozhodnutia ako PDF podpísané s PAdES aspoň ako doplnok k elektronickému úradnému dokumentu (ktorý je vo forme XML údajov), a to pre ich praktickejšie použitie. Navrhol na ďalších zasadnutiach diskutovať túto tému. 

XII. SynchCodeFilledData v zmysle Prílohy č. 3 bod 2.3.2, 

(dátový prvok D.6.3 Párovací kód vyplnených údajov) 

Súhlasíte so zachovaním povinnosti používania tohto dátového prvku?

Záver

Pracovná skupina súhlasila s návrhom:

Z Prílohy č. 3 sa vypúšťa bod 2.3.2 - dátový prvok "SynchCodeFilledData" 

Z Prílohy č. 2 sa vypúšťa bod D.6.3 -  dátový prvok "SynchCodeFilledData"

Diskusia

Účelom definovania dátového prvku SynchCodeFilledData bolo riešiť skutočnosť, že URI v mennom priestore XML súborov nebolo podľa postoja NASES vzhľadom na existujúce množstvo integrácií možné zmeniť hodnotu zo http://schemas.gov.sk/form/identifikator-formulara/ na tvar http://data.gov.sk/doc/eform/identifikator/verzia (dnes https://data.gov.sk/id/eform/identifikator/verzia). Z praxe však vyplynulo, že sa tento atribút vôbec nepoužíva a vhodnejším riešením bude zmeniť URI v mennom priestore.

3. Prezentácia XForms 

Pán Turčan prezentoval technológiu XForms aj jej možnosti použitia pre účely prezentácie pre vypĺňanie e-formulárov na ÚPVS. 

Navrhuje sa doplnenie možnosti používať W3C XForms pre prezentáciu pre vypĺňanie e-formulárov (v bode 2.6.5 Prílohy č. 3 Výnosu o štandardoch č. 55/2014 Z.z.). 

Téma bude predmetom rokovania ďalších zasadnutí PS6. 

 

Unknown macro: {add-label}