No obávam sa, že v realite je toto presne naopak. Centralizacia betonuje dodávateľa form services (anext a ditec) do niečoho čo je inak len nezaujimava a tenká vrstva na frontende. Dodávateľ na strane ais je tam dávno zabetonovany cez validacne a biznis funkcie na backende. Toto mu trochu rozviaze ruky v tom, že bude robiť lepšie rýchlejšie frontende. viď to co písal @vojtob hore.
Ďalšia vec je xforms. Akokoľvek som fanúšik w3 a otvorených standardov, tak si treba priznať, že je tam aj kopec mŕtvych štandardov, ktoré nikdy neuvidia nasadenie v praxi. Prečo napríklad html5 formuláre ďaleko rýchlejšie adoptovala prax? No asi tam je pridaná hodnota. Tu sa naozaj snažím a nevidím.
ved ale ja nerozporujem to ze problem je v uzavretej technologii. pisem len tolko ze lepsie je riadit sa nejakym dohonutym standardom a pak nech si kazdy robi eformulare u seba jak chce, ale aspon bude zabezpecena vzajomna vymenitelnost a znovupouzitelnost daneho riesenia. Zabetonovany moze byt, ale to este neznamena ze tam je naveky, kazdy proprietarny beton ho betonuje viac a viac…
pisal som aj vyssie, xforms beriem ako priklad toho ze aj s tymto je to mozne, pokial niekto vie o lepsom rieseni ktore by mohlo danu problematiku riesit tak super. Mam ale z tejto celej diskusie pocit ten ze kazdy si to chce riesit po svojom.
Skúsim prirovnanie. Prečo nám nevadí, že backendy sa nerobia v nejakom štandarde? Veď to si môže hocikto robiť v jave,.net, php, c#, asp alebo nebodaj aj ruby? V čom je toto iné? Prečo toto považujeme za dobrý nápad? Podľa vašich reakcií sa bojíte nejakého licencovania, ale to nedáva zmysel. To jednoducho bude bežať na nejakom webe a koniec. Iomo keď bude chcieť mať svoje optimalizované formuláre pre úradníka tak nech si ich láskavo vyrobí (schémuy a príklady ostavaju) a nekomplikuje život celému zvyšku eGov.
Ono to tu už viackrát zaznelo - v zásade realizovať veci súvisiace s prípravou podania mimo el. formulára. Čiže formulár nemusí povinne obsahovať žiadne interaktívne prvky, žiadne pomôcky pre vkladanie údajov, žiadne napĺňancie/validačné funkcie.
Čo je jasné že zostáva, je schéma/dátová štruktúra a vizualizačné schémy.
Preberme si jednotlivé používateľské use-case s formulármi a procesy pri tvorbe/zmenách formulára vrátane nákladovosti.
Možno povedzme výjde, že vytvorenie vizualizačnej transformaćie pre tlač je zložité a zbytočné (=príliš málo použití) robiť cez XSLT->XSL-FO->PDF, a je dostatočné pribaliť k formuláru vizualizované PDF (prázdne), lebo vytlačiť sa vlastne dá aj podpisová vizualizácia do HTML. Alebo výjde, že zostavenie vizualizácie na tlač aj tak nikto nerobí lokálne, takže stačí mať na to server-side aplikáciu, a k tomu uvoľnime pravidlá pre transformáciu - napr. tvorca formulára dodá vykonateľný kód, ktorého vstupom sú údaje formulára a výstupom je PDF.
Zároveň sa treba zamyslieť či pre elektronické úradné dokumenty nezrušiť požiadavku na použitie el. formulára, alebo aspoň pre niektoré typy (rozhodnutia?). Ak áno, čím to nahradiť - povedzme el. dokument v zmysle štandardov ISVS plus metadáta?
Vratime sa teda spat k informovaniu o tom co sa deje v skupine:
3.8.2017
prezentacia o akcnom plane, v principe to bola len povinna jazda, nic velmi zaujimave z pohladu arch.
potom volna diskusia, spominany problem, ze nejake OVM maju viac schranok a nie je zrejme kam sa co ma posielat.
10.8.2017
prezentacia k RPO
najneskor ked nadobuda ucinnost musi byt v RPO
koniec augusta zoznam OVM v RPO
genericky register - 5 registrov (2 institucie) - generickym registrom sa mysli len na ucely evidencie v RPO. sluzi pre OVM ktore nemaju na vlastne IS.
komora taxikarov nemaju RC, socialka to potrebuju (problem)
historiu subjektov zasiela zdrojovy register (robia aj opravy spatne!)
do RPO - konecni uzivatelia vyhod (je to nieco ine ako ako RPVS), bude to neverejne, logovane pristupy
RPO ako open data skor ci neskor musi skoncit (nateraz - ekosystem.slovensko.digital)
problemy a vyzvy
roznorodost zakonov (napr. datum vzniku = nadobudnutie pravoplatnosti rozhodnutia, vselikde to je trosku inak)
ZR zo zakona nemaju plnu sadu udajov pre RPO
pri komunikacii (neochota, neznalost, absencia spatnej vazby)
Z celeho toho som mal pocit, ze register vznikal vlastne agilne za jazdy, kedze az teraz nejako zistuju co by chceli ti konzumenti ake problemy maju producenti dat. Klasika.
Vraj na zaintegrovane ISVS ktore idu napriamo na RPO neexistuje prechodne obdobie a teda nemusia (nikdy?) uz ist cez MUK (dnes CSRU).
K diskusii o el. formulároch: v 2. čítaní prebiehajúcej novely zákona o eGov plánuje ÚPVII umožniť aby vypĺňanie formulára mohol kto chce, implementovať lokálne. Viď. poznámky z rokovania komisie v NRSR.
zamer - prechod na eventovy system (publish/subscribe aj smerom k PO)
utorky poobede - hluche miesto - vtedy tam nikto nechodi
kvalita dat - uz len reaktivny rezim, co sa dalo bolo precistene.
identity provider (zvazuje sa)
polozil som otazku ci maju zoznam sluzieb pre PO? Vraj nejake banky uz mozu.
RA
ulice cez viacero okresov (cisla sedia ale vazba nie je), duplicity cez okresy
Ak ma niekto navrhy co by nemalo chybat v dokumente s nazvom “Referenčná architektúra Informačného systému verejnej správy v cloude” sem s nimi.
Moje postrehy k tomuto:
Statny build system / source control: Ak som to spravne pochopil, tak ide o to, aby stat mal zdrojaky u seba. Na toto robit statny source controll ala github/gitlab je zbytocne aj keby sa malo zobrat nejake opensource riesenie (trebars gitlab) - co teda silne pochybujem, ze by tak dopadlo. Ak chce stat mat zdrojaky centralizovane (nevidim zatial velky dovod), tak by malo stacit mirrorovat nejake git repo kde im dodavatel spravi pristup. Ak by stat chcel zverejnovat opensource, tak odporucam to spravit rovno na githube/gitlabe. je to zadarmo a nepisany standard (uk/aus/usa/est)
Ak ma byt build system sucastou ekosystemu na podporu vyvoja, povazujem to za zly smer. Konkurencia na tomto trhu je velka, variabilita velka (aj na zaklade funkcionality aj pouzitych jazykov/test frameworkov) a firmy pouzivaju rozne build/CI systemy a investovali do nich nemale prostriedy, aby to prisposobili svojim potrebam, v skratke: neda sa vyhoviet kazdemu jednym riesenim. Pridanu hodnotu v tom velku nevidim, skor by dopadlo tak, ze sa nieco vyberie a vacsine to vyhovovat nebude a aj tak si to budu robit po svojom. Cize za mna toto nie.
Jano, pekne ze mame NAZOV dokumentu … Ale na tvoju otazku sa da odpovedat, resp sa nad nou zamyslat ked budeme vediet ake je postavenie a pravna sila tohto dokumentu. Ako a pre koho ma byt dokuemnt zavazny a na ake obdobie. Lebo dokumentov sa da navyrabat tisicky. Toto by sa niekde v META IS malo objavit, malo mat nejaku zavaznost pre rozne role a malo mat nejaky casovy ramec platnosti.
Je nevyhnutné, aby povinné osoby aplikovali závery z uvedených dokumentov v rámci spracovania svojich koncepcií rozvoja informačných systémov a štúdií uskutočniteľnosti pre OP II.
ÚPPVII pri posudzovaní akýchkoľvek predložených zámerov, resp. štúdií (nielen pre OP II, pretože koncepcie správcov ISVS sa týkajú akéhokoľvek IT rozvoja) - vychádza práve z NKIVS a teda aj spomínaných dokumentov.
Ak treba ešte niečo doplniť, rád upresním. Ale nezabudnime sa aj vrátiť naspäť k téme:
Ak ma niekto navrhy co by nemalo chybat v dokumente s nazvom “Referenčná architektúra Informačného systému verejnej správy v cloude” sem s nimi.
OK HTML ani nie tak koli schrankam ale koli tomu, ze sa jedna o podpisany dokument urceny v prvom rade pre cloveka, podanie aj rozhodnutie nim urcite je. XML je v pripade ak hovorime o elektronickom podpisovani vhodny na strojove spracovanie dokumentov ako sa docitame aj v technickych normach tykajucich sa podpisovania. Toto je vsak taky hybrid dokumentu aj pre stroj aj pre cloveka. Z toho vzdy pre cloveka a niekedy aj pre stroj ak je napr. treba nejak zautomatizovat proces.
Ak by do spracovania nevstupoval kvalifikovany podpis, tak by na tom vobec nezalezalo
Ak by zostal iba HTML kod no tak snad to. Ale v podstate ide len o to ze to co je sa da lahko napravit. Treba prislusnu transformaciu dat do podpisovanych dat v podpisovom subor a podpisat spolu s datami. A ked niekomu pojde o zobrazenie tak si stransformuje a ked chce vymientat udaje nech si robi s xml co potrebuje.
Mas pravdu to bola blbost vsak ani standardy neumoznuju html podpisovat…
Z tej predstavy co som na to reagoval vyplyva ze ide hlavne o vymienanie si dat cez xml. A preto som napisal ze html nie je koli schranke ale koli zobrazeniu pre cloveka.
http://schemas.gov.sk/form/App.GeneralAgenda/1.9/form.xslt
takato referncia a hash je zrejme hashom podpisovej transformacie. Ale ta je bohuzial prosty text v stromovej strukture, kedze tu softver pouzil pre podpis tak si z nej mohol vypocitat hash, ale kedze pouzil tranformaciu do prosteho textu.
Ano to by bolo v poriadku keby tam bol hash na transformaciu ktoru mozeme pouzit na zobrazenie dokumentu, tak ako ho podpisujuci videl. U ostatnych xml co su podpisovane to tak aj v standardoch je, nechapem preco tomu tak nie je u formularov, kde to hra dolezitu ulohu pre ich riadne zobrazovanie v systemoch spravy registratury a kdekolvek inde po stiahnuti do priostredia mimo schranky.
Myslim ze u formularov co su robene s QSignom to aj tak je tam neni problem so zobrazenim tak ako to podpisujuci videl.
Podla mna by bolo treba podpisovat s transformacnym xml urcenym pre prehliadanie. Alebo ked uz to ozaj inak nejde pripojit hodnoty hash nielen pre textovu transformaciu, ale aj ostatne subory daneho formulara.
Urobit opatrenia na zabezpecenie centralneho uloziska formularov, napr. tym ze po prevzati do kniznice sa bude evidovat a zverejnovat aj hash hodnota kazdeho jedneho suboru v balicku. Prehliadace formularov tretich stran - nie overovaci soft - potom maju moznost pred samotnou prezentaciou overit ci nebol transformacny subor zmeneny
za jazdy, kedze az teraz nejako zistuju co by chceli ti konzumenti ake problemy maju producenti dat. Klasika.