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

Dátum a čas konania: 19.06.2017, od 11:00 do 15:00

Miesto konania: UPPVII, zasadačka Londýn 2.poschodie blok B

Agenda: 

  1. Riešenie technických problémov kontajnera pre publikáciu e-formulárov – zmena vlastností elementov a atribútov (na schválenie)
    1. Podklady na schválenie a diskusiu (viď 10 bodov nižšie) 

  2. Štandardizácia prezentácie a prezentačnej schémy pre vypĺňanie e-formulárov na ÚPVS  (informácia a diskusia)
    1. Prisľúbená dokumentácia od NASES dnes používanej technológie
    2. 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.)

  3. Jednotný dizajn manuál elektronických služieb (informácia)
    1. Podklady: Zápis PS3

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

 

Podklady k bodu 1: 


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

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)

 

Zdôvodnenie: Je nutné, aby sa dali odlíšiť e-form kontajnery, či sú v súlade s Výnosom alebo nie, ktorú novelu Výnosu implementujú, atď.

Cez mimetype application/vnd.gov.sk.e-form+zip/xml sa žiaľ odlíšiť nedajú, lebo na ÚPVS začali používať zaregistrovaný mimetype napriek rozporu používaného kontajnera so špecifikáciou.

Vo Výnose sa zatiaľ revízie e-­form kontajnera verziami neodlíšili. Dajú sa odlíšiť v XML podobe e-form kontajnera cez verziu v identifikátore namespace kontajnera, v root elemente "e-form". Pri ZIP verzii namespace pre kontajner ako celok nie je.

 

2. Používanie BOM v XML súboroch 

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

Zdôvodnenie:

XML podoba kontajnera musí byť v zmysle IANA registrácie vždy v kódovaní UTF-8, preto nie je nutné BOM používať.

BOM nie je povinné používať v zmysle špecifikácií XML 1.0 a Unicode, ak sa používa UTF-8.

So spracovaním BOM vznikajú v niektorých aplikáciách pre spracovanie XML súborov problémy.

V zmysle XML špecifikácie: „XML processors must be able to use this character to differentiate between UTF-8 and UTF-16 encoded documents.“

 

3. 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. ) 

Zdôvodnenie:

V čase vypublikovania e-formulára často nie je jasné, do kedy bude platný a účinný, preto sa elementy „inForceTo“ a „validDateTo“ nepoužívajú alebo sú prázdne – vďaka čomu vzniká dojem, že sú platné natrvalo. Tieto údaje je potrebné meniť, pričom ich zmenou sa mení digitálny odtlačok e-formulára.

Navrhuje sa preto presunúť informácie o konci platnosti a konci účinnosti e-formulára mimo e-form kontajner, aby bolo možné zneplatniť takýto e-formulár a v prípade zneplatnenia zostával vypublikovaný e-formulár bez zmeny.

ÚPVS v súčasnosti umožňuje meniť v e-formulári bez zmeny verzie e-formulára iba informácie "platnosť do" a "účinnosť do" e-formulára (čiže elementy "inForceTo", "validDateTo" v meta.xml v e-form kontajneri). Keď sa tieto menia, nemení sa v ÚPVS verzia e-formulára, avšak mení sa digitálny odtlačok elektronického formulára.

Niektoré metaúdaje, ako dátum konca platnosti a účinnosti, digitálny odtlačok, by sa k e-formulárom mohli poskytovať v samostatnom súbore, popri e-form kontajneri. Tým by sa zabezpečilo, že by nebolo potrebné zasahovať do kontajnera a meniť jeho digitálny odtlačok len kvôli zmene platnosti alebo účinnosti.

Poznámka: Taktiež vzniká problém s prezentáciou identifikačných údajov, ak sa zmení účinnosť / platnosť do v prípade interpretácie pravidiel 4.7.3 a 1.4.4 prílohy č. 3 Výnosu tak, že identifikačné údaje musia byť súčasťou prezentácie a teda napevno zapísané v prezentačnej schéme. V prípade zmeny platnosti alebo účinnosti e-formulára by sa musela zmeniť aj verzia.

 

4. 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ý. 

Je preto potrebné riešiť externé ukladanie súboru POSP.xml mimo e-form kontajnera. 

POSP.XML nie je vo všeobecnosti povinný na ÚPVS, vyžaduje sa však pri niektorých spôsobom pridania súborov. Ak absentuje, používa sa defaultný POSP.XML. 

POSP.XML popisuje vlastnosť elektronickej služby. 


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

Zdôvodnenie:

Podľa prílohy č. 3 bodu 7.5.5 Výnosu o štandardoch pre IS VS. XML súbory majú byť v zmysle bodu 7.5.5 v XML verzii kontajnera vo forme priamej integrácie.

Z diskusií s tvorcami softvéru pre podpisovanie vyplynulo ako potrebné v XML verzii kontajnera vkladať schémy potrebné pre podpisovanie vo forme base64 kódovania a teda nie vo forme priamej integrácie. V praxi sa im stali problémy, kedy sa XML súboru vo forme priamej integrácie, resp. v textovej forme pri používaní v rôznych systémoch odlišoval digitálny odtlačok a nevedeli to vyriešiť inak, než base64 zápisom.

Bol nahlásený aj problém s používaním XML deklarácie na začiatku XML súborov, keďže po ich vložení do XML verzie kontajnera formou priamej integrácie nie je možné túto deklaráciu zachovať, keďže XML súbor môže obsahovať iba jednu XML deklaráciu.

Možnosti riešenia sú:

1. - Predpisat alebo odporucit, aby sa XML deklaracia nepouzivala v XML suboroch, ktore sa publikuju v e-form kontajneri.

2. - Predpisat alebo aspon odporucit kanonikalizaciu pre XML subory pred ich vypublikovanim v e-form kontajneri.

3. - Predpisat povinnost zapisovat XML subory v e-form kontajneri vo forme base64 (minimalne XSD e-formulara a podpisove XSLT prezentacne schemy e-formulara) a to namiesto ich embedovania v e-form kontajneri alebo popri embedovani v e-form kontajneri.

Moznosti ako riesit base64:

a) v XML verzii e-form kontajnera definovat novy nadriadeny element pre XSD (napr. "xsd"), kedze momentalne sa XSD integruje priamo a jeho nadriadeny element je korenovy "e-form", co znemoznuje toto XSD nahradit base64 retazcom. XSLT subory je technicky mozne vkladat ako base64 uz teraz.

b) vkladat XSD do e-form kontajnera duplicitne: integrovany v XML forme pod elementom "e-form" a v base64 forme pod elementom "content"

 

 

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

 

Zdôvodnenie:

Vznikajú rôzne výklady Výnosu. V prípade zmeny platnosti alebo účinnosti e-formulára by sa musela zmeniť aj verzia.

- Citáty z Výnosu:

4.7.3 Používateľ elektronického formulára má možnosť zobraziť si všetky identifikačné údaje elektronického formulára podľa bodu 2.2.1.

1.4.4 Prezentačná schéma je súhrnom pravidiel pre transformáciu dátového obsahu elektronického formulára do predpísanej prezentácie. Stanovuje spôsob vnímateľnej interpretácie dátovej štruktúry elektronického formulára, vrátane všetkých identifikačných údajov elektronického formulára, ktoré sú prezentované používateľovi elektronického formulára.

 

 

7. viacjazyčné meta.xml

(V zmysle záverov PS6, dnes PPS1, 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>

 

 

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

(V zmysle záverov PS6, dnes PPS1, z 26. júna 2015, na základe problému pri generovaní PDF v MEF.)

Účel atribútu:

Informácia pre tvorcu povinnej tlačovej PDF prezentácie, s ktorou verziou PDF je prezentačná schéma kompatibilná a aku najstriktnejšiu verziu PDF je z nej možné vytvoriť. Atribút je povinný pre povinnú tlačovú prezentačnú schému. Pre ostatné tlačové prezentačné schémy je nepovinný.

Návrh názvu atribútu:

xslfo-reference-procesor-pdf-version

Návrh hodnoty atribútu:

môže byť len jedna z možností: PDF/A-1a, PDF/A-1b, PDF 1.4, PDF 1.5, ... (v závislosti od rozhodnutia PS6).

Povinne sa uvádza najstriktnejšia kompatibilná verzia podľa uvedeného poradia, pričom najstriktnejšia je PDF/A-1a.

(PDF 1.3 sa neuvádza, lebo nie je referenčným XSL-FO procesorom Apache FOP podporovaná, ale môžeme ju kvôli súladu s Výnosom prípadne doplniť a v praxi by sa nahrádzala verziou 1.4.)

(Ak by novy atribut vadil kvoli spatnej kompatibilite, mozeme napriklad predpisat, ze ak nie je pouzity, bude to znamenat, ze hodnota je "PDF/A-1a".)

 

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



Unknown macro: {add-label}