Zdielanie definícii eFormulárov a realizácia transformácii


#1

Z emailových návrhov preklápam sem.

Problém:
Každé podanie/rozhodnutie by od 1.2.2018 malo byť vo formáte XML (vyplnený elektronický formulár). Väčšina orgánov to zatiaľ ignoruje, ale aj tak…
Do schránky eDesk príde len XML, v ktorom je info o použitom eFormuláre. Pre zobrazenie v prehliadači je potrebné vykonať transformáciu do HTML, pre vytlačenie transformáciu do PDF. Neviem, či takéto niečo už robíte v GovBox-e. e-Desk schránka na ÚPVS to v nejakej miere dokáže.
Aby si mohol urobiť transformáciu, potrebuješ ju získať z definície formulára, ktorý je publikovaný na ÚPVS.
Momentálne je ten systém vymyslený „prudko nezmyselne” tak, že keď niekto publikuje nový formulár, ÚPVS o tom notifikuje všetkých príjemcov a tí sú povinní si stiahnuť formulár k sebe, hoci ho možno nikdy nepoužijú. Výsledkom je, že každý informačný systém pripojený na ÚPVS obsahuje niekoľko kópií všetkých (3000?) formulárov. Ak ale notifikácia niekde „uviazne” - častý jav, tak niektorý systém ten formulár nemá a následne pri pokuse zobraziť podanie zhavaruje.

Riešenie:
Vyrobiť v ekosystéme úložisko všetkých formulárov, ktoré by poskytovalo webservisu, ktorá na základe identifikátora formulára vráti jeho definíciu. K tomu by sa mohli zverejniť opensource knižnice, ktoré ztransformujú XML do HTML a PDF cez transformáciu v definícii formulára.


ÚPVII Pracovná skupina K9.5 Lepšie služby
#2

V GovBoxe sme práve to API chceli použiť, dokonca myslím existuje na UPVS služba, ktorá vyrába PDF z XML. Avšak vraj teda to nechcú kvôli kapacitným problémom, aby sme to volali masovo.

Nakoniec sme sa na to však vykašlali, lebo:

  • HTML transformácie vyzerajú hrozne (česť výnimkám), PDF ešte horšie.
  • eDesk API vracia pre každú správu aj HTML transformáciu, čiže XML na HTML transformovať treba len v extrémne zdriedkavých prípadoch (divne zabalené XML v nejakom kontaineri)
  • Väčšina správ bola aj tak vo formáte “posielame vam vyjadrenie v prilohe” a prílohy (pdf, rtf…)
  • V GovBoxe teda preposielame ako prílohu originálne HTML a ak sa dá do mailu našu “peknú” vizualizáciu.

#3

Ak spravne citam tuto poziadavku, tak by to bolo vlastne nejake public API na formulare, kde by bola OS kniznica, ktorá by toto API vyuzivala na vyrobenie transformacie XML->HTML a XML->PDF je tak?

S tym, ze by vznikla silna zavislost na dostupnosti nasho API (co by som ako problem nevidel), ale bol to asi dovod preco UPVS islo smerom lokalnych kopii a notifikovania o zmenach.


#4

toto je vlastne prudko v nesúlade s platnou legislatívou, takže dúfajme že to čoskoro vymizne :wink:


#5

Kde niet žalobcu, niet ani sudcu. A tam sa nič diať nebude.


#6

Toto by pri veľkom počte dotazov mohlo naozaj neprimerane zaťažovať “centrálu”.
Skôr by som to videl na webservisu, ktorá na základe ID formulára vráti jeho celú definíciu alebo len xslt konkrétnej transformácie.
Samotnú transformáciu by si robil lokálny systém (jeho server). Konkrétne postupy a zdrojáky, ako robiť transformáciu by sa publikovali ako súčasť riešenia.
V podstate “centrála” by len uchovávala všetky formuláre a poskytovala by ich - v princípe to je len suplovanie “nefunkčnosti” ÚPVS.


#7

Tak ja v súčasnej situácii skôr ako riešenie vidím, že PDF bude pre niektoré veci normálne povolené. (Ozaj, @ius sa dávno neozval.)

Toto je základ čo musí byť spravený na ÚPVS. A dokonca je jasné aj ako to má byť: každý e-form (aj sám o sebe, aj verzia) má ref. id. - viď. meta.xml->metadata->identifier, podľa neho má byť dostupná definícia (keď už sa hráme na dereferenciáciu, preferujem priamo takto).

Ak chceme robiť nejaké naše úložisko, tak ozaj “ľahké” - btw. vieme tú deref. spraviť my? - To by sme boli iba proxy.


#8

Ináč vyzerá to, že na ÚPVS vlastne nejako pokútne mechanický prístup k definíciám eForm funguje.

Ak identifier je vo forme http://data.gov.sk/doc/eform/{meno}/{major_ver}.{minor_ver}
Tak príslušné URL na ÚPVS s “detailami formulára” je
https://formulare.slovensko.sk/_layouts/eFLCM/DetailVzoruEFormulara.aspx?vid={meno}&vh={major_ver}&vl={minor_ver}

čiže napr. pre http://data.gov.sk/doc/eform/00308307.A0000224.000000034.PriznanieDzN_PO/1.4 je to
https://formulare.slovensko.sk/_layouts/eFLCM/DetailVzoruEFormulara.aspx?vid=00308307.A0000224.000000034.PriznanieDzN_PO&vh=1&vl=4

Zip so všetkými súčasťami formulára je
https://formulare.slovensko.sk/_layouts/eFLCM/GetEFormArtefact.aspx?ac=4&vid={meno}&vh={major_ver}&vl={minor_ver}

Aj jednotlivé súčasti majú generovateľné URL, mení sa iba parameter ac.

…nejako si matne spomínam, že toto sa aj riešilo na PS pre štandardy o el. form - @stefan.szilva toto aj je garantovaný štandard?


#9

Tak ono by bolo najlepšie, keby ÚPVS robilo niečo užitočné :wink:
Ale hlavne v konečnom čase :slight_smile:
Koľko mesiacov-rokov sľubujú rôznu funkcionalitu?
Existuje nejaký mechanizmus, ktorý by ich prinútil k vyššej aktivite? (teda okrem oranžovej revolúcie…)


#10

Možno je to len jednoduchá XSLT transformácia cez Apache FOP, ktorá berie definíciu z eFormu a XMLko a vracia PDF. Nemalo by to byť moc komplikované.


#11

Podla mojich informacii sa ma formularova cast vyrazne znormalizovat (pribudnu validacie pri uploade formularov!) a zaroven zosuladit s vynosom a standardom na PS1. V skratke :

  • pribudne velke kvantum vyzadovanych automatickych validacii co vyrazne zvysi kvalitu a uniformnost formularov
  • bude validovany a vyzadovany jednotny referencovatelny identifikator pre nove formulare alebo pre updatnute tj. tym padom sa zacne konzistentne riesit aj verzionovanie (rata sa s prechodnymi obdobiami)
  • namespaces vo formularoch a XSD schemach budu prepojene na id formulara a XSD bude realne pristupne na danej linke
  • bude existovat directory list sluzba tj. jednotlive sucasti formularu ako aj cely zip bude jednoducho stiahnutelny priamo cez jednotny referencovatelny identifikator

Posielam linky na to ako to bude v relativne kratkom case zapracovane priamo do MEF:
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=19661413
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=19661404
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=20023176


#12

Celkový zoznam (schválený na PS1) je publikovaný aj na MetaIS v časti štandardy ISVS
https://metais.finance.gov.sk/publicspace?pageId=24510898
(tu prenášam schválené pracovné materiály na ich zamknutie, napr. znenie štandardu URI formátu tam ešte prenesené nie je).

Tj. správne URI schéma pre Elektronický formulár je
https://[domain]/id/egov/eform/[id]/[version]

tj. v tom príklade by to bolo
http://data.gov.sk/id/egov/eform/00308307.A0000224.000000034.PriznanieDzN_PO/1.4

Od januára “vrcholí” ukončovanie novej verzie, s viacerými zmenami (zjednodušovanie) a najmä lepšiou dokumentáciou: všetky ontológie aj príklady budú dostupné nielen v RDF/XML, ale aj UML, HTML a PDF. Nechcem predbiehať, ide o mnohé vylepšenia. Pôjde to aj na PS1 a postnem to aj na platformu.

PS: Predpokladám, že doplnenie stránky s aktuálnymi štandardmi a postnutie novej verzie bude cca. na konci ďaľšieho týždňa.


#13

toto by bolo fajn,
… keby to nekomplikovali tieto 2 veci:

  1. ked pride do systemu len obsah podania (formulara), tak IDENTIFIER nemam k dispozicii. Mam k dispozicii len datove XML a z neho jeho NamespaceURI
    teda napriklad
    http://schemas.gov.sk/form/00308307.A0000224.000000034.PriznanieDzN_PO/1.4

nepoznam postup, ktorym zarucene a 100% pre vsetky zaregistrovane formulare z NAMPESACU vycarujem IDENTIFIER

  1. z tejto linky https://formulare.slovensko.sk/_layouts/eFLCM/GetEFormArtefact.aspx?ac=4&vid={meno}&vh={major_ver}&vl={minor_ver}
    nevyskladam taku, ktora mi urcite vrati konkretnu sucast formulara, napr. tranfsormaciu do PDF

to je ta, ktora je v manifest.xml zapisana ako media-destination=“print”
… toto sa samozrejme da riesit, ze to potiahnem na 2 razy, najprv cely balik/manifest a z neho potom ziskam
https://formulare.slovensko.sk/_layouts/eFLCM/GetEFormArtefact.aspx?ac=02&vid=00308307.A0000224.000000034.PriznanieDzN_PO&sid=form.238.fo.xsl&vh=1&vl=4


#14

Ahojte,

uz dlhsie pracujem na sluzbe, ktora by mala ukoncit trapenie ludom a firmam pri vytvarani elektronickych dokumentov. Technicky je to HTML to PDF generator ku ktoremu som pristaval automaticky generator formularov a API podla HTML predlohy. Vo vysledku staci nadizajnovat predlohu v online editore a optimalizovany web formular ako aj REST API sa vygeneruje automaticky.

k XML to zatial velmi nesedi, ale keby bol zaujem, nemam problem to dorobit. povodny navrh bol, aby ten generator vedel spracovavat rozne vstupy aj vystupy, no zatial som to zredukoval na JSON, HTML a PDF z logickych aj casovych dovodov.

sluzbu si mozte vyskusat, samozrejme zadarmo na https://eledo.sk/
je stale vo vyvoji, tak prosim ospravedlnte jej nedostatky :slight_smile:

do buducnosti mam rozpracovane aj digitalne podpisovanie PDF (ale take to nativne, nie podivny ZEP), ktore dokazem podpisat aj obcianskym preukazom, no zistil som ze na komercne ucely sa to nesmie pouzivat, tak to zatial dozrieva v sufliku.

ja vidim velmi siroke vyuzitie mojej sluzby a to je hlavny kamen urazu, preco ju zatial okrem mna nikto nevyuziva. Vo verejnej sprave by sa to dalo velmi pekne vyuzit, rovnako ako aj vsade inde kde sa dnes robi copy&paste word dokumentov a prepisuju sa mena, priezviska, datumy… :smiley:

Lubos Husivarga


#15

Som rád, že prichádza na moje slová - trvalo to dva roky :slight_smile:

PDF je priemyselný štandard, ktorému sa štátna správa nevyhne.


#16

myslis digitalne podpisovanie vlastnym certifikatom, ci certifikatom pouzivatela? Ak pouzivatela, tak mozes (teda urcite budes) mat problem ku pristupu k jeho privatnemu klucu (teda pokial nebudes mat apku na strane klienta, ale takych uz je dost).


#17

uvazoval som nad oboma moznostami, ale zatial je pre mna jednoduchsie a pre zakaznika bezpecnejsie pouzivat certifikat pouzivatela na strane klienta - cize nejaka jednoducha opensource desktop aplikacia. Viem, ze takych aplikacii uz je dost ale k mojej sluzbe je to len doplnkova funkcionalita.

neviem na akom zaklade stoji docusign z pravneho hladiska, a ci by malo vyznam implementovat obdobny sposob podpisovania tu v Europe. Technicky to nieje problem.


#18

pokial viem (mozno sa to zmenilo), tak DocuSign pouziva(l) iba stampy (peciatky, obycajna anotacia) ako podpis, teda ziadny digitalny podpis. Mozno digitalny podpis uz pridali Kvoli tomu prehral aj nejaky sud v USA. V Europe napr. existuje signrequest.com (alternativa pre docuSign), pre ktory sme nedavno robili novy backend na digitalne podpisovanie pdfiek.


#19

mam tu jeden dokument podpisany DocuSign-nom z 2013 a je podpisany certifikatom vydanym pre DocuSign Entrustom, cize podpisovali jednym certifikatom vsetky dokumenty a dokonca algoritmom SHA1 RSA, lenivci. Necudo, ze prehrali sud :smiley: Tie “peciatky, obycajna anotacia” su sice len anotacia v strukture PDF dokumentu (sucast tzv. visual digital signature), no odkazuju na realny digitalny podpis.

ako je to s DocuSign teraz netusim, ale myslim ze uz trosku odbocujeme od topicu. popripade sa mozme o podpisoch bavit v inom threade.

moja predstava o bezpecnom podpisovani je stale taka, ze vo firme je pocitac s desktop appkou a certifikatom na karte ku ktoremu ma pristup sef, pripadne poverena skupina ludi/automat a dokumenty sa podpisuju vizualnou kontrolou a odklepnutim. Pri fakturach je automatizacia v pohode, ale podpisovat kontrakty automaticky mi pride zcestne.


#20

Prosim co su to ti prijemcovia ? Chcel by som byt notifikovany o formularoch napriklad Zarucenych konverzii… Mam sa k tym notifikaciam niekde prihlasit ?