Ano mas pravdu, ja som to myslel tak ze kedze komunikacia je obcan<>uradnik, ze by ta transformacia formulara ako ho vidi vyplnujuci by mala byt brana ako zaklad. Tym mame poriesene zmysly ludi co sa podielaju na danej veci. A ostatne transformacie su potom vynikajuca vec, ktory moze pri automatizacii procesov napomahat - spolu s datami v xml - cize vyborna vec, ale kedze ide nie o uctovne transakcie ani vyrobne ale hlavne o komunikaciu ludi (ktoru mozno pomocou xml dat a transformacii roznymi sposobmi automatitzovat), amla by mat ta transformacia do html byt ako hlavna metoda, ktora by mohla vyhovovat aj z pohladu dlhodobejsej uschovy - samozrejme po eliminacii rizik vid. nizsie
presne tak. Mnoho veci sa da teraz doladit, ale aj vylepsit a doplnit ale nemalo by to vytvarat dalsi problem iba vyriesit stavajuci, alebo pridat neexistujucu funkcionalitu. Trochu som mal obavy - nepoznam presne o co ide ale ta transformacia ma trochu inspirovala k prispevku. V implementacii podpisu trochu zanikli kedysi dost zname uskalia, ktore su dnes iba poznamkou v technickej norme, a bolo by dobre aby sme sa im vyhli pri praci s formularmi a hned sa znizia rizika do buducnosti. Napr. poznamka k 4.2.3 podp. dokument.
http://www.etsi.org/deliver/etsi_ts/119100_119199/11910201/01.00.01_60/ts_11910201v010001p.pdf
ale aj reprezentacia miesto podpisovaneho dokumentu moze mat svoje uskalia a preto ich by bolo najlepsie preklenut podobne ako u formularov qsign tym ze sa transformacia urcena pre cloveka vlozi a podpise spolu s datami.
nemal som cas presne rozpytvat a dokumentacia hovori o referencii. Ale nech je to ako chce. Zakazdym to ma riziiko. Ak je to hash tej transformacie, ktorou som zobrazoval pri podpise, tak tym ze xsl pre formulare su bud v softveri, alebo v inom systeme-upvs, moze nastat situacia:
podpises dokument. On hash transformacneho xslt vlozi ako podpisanu polozku. Niekto medzi tym zmeni v transformacnom subore napr. nejaku len medzeru tam prida cim sa zmeni jeho hash. a problem je na svete. Overovaci softver si vo svojej kniznici drzi xslt subor bud uz ho tam ma, alebo si ho pred prvym overenim stiahnes, takze stiahnes ten zmeneny xslt, softver ti pekne overi aj zobrazi, ale das mu overit ten isty formular zo vcerajska kedy este nebol zmeny xslt a tam uz bude problem lebo podpisany hash tranf. suboru by bol iny. Ale ak je to tak ze je tam - v podpisanom objekt co ma URI ktore co priamo neukazuje na nic fyzicky konkretneho, http://schemas.gov.sk/form/App.GeneralAgenda/1.9/form.xslt tak je to odkazovanie sa pre zobrazovaciu cast kamsi do sveta a cokolvek co sa bude tvarit ako spravny xslt sa bude dat pouzit. A teoreticky sa daju obe moznosti skombinoavat. Zakazdym tam bude nejake male riziiko.
Ale toto spolu s tym ze v kniznici formularov neni napr. ani taka evidencia, ze ku kazdemu suboru je evidovany jeho hash aby si system ktory chce zobrazit mohol overit neposkodenost xslt vytvara predpoklady na to, ze ked si stiahnes formular do svojho pc cize mimo schranky a budes ho mat par rokov tak sa da podstrcit xslt, a rozne ine veci ktore by bolo dobre nejak teraz zacat obmedzovat. Napr. ani nedavat moznost v dokumentacii integrujucemu vyvojarovi aby si vyberal ci podpis chce urobit v takom alebo onakom formate. Jednoducho predpisat proceduru, hodnoty parametrov a toto bud budes pouzivat alebo ti podpis neprejde.
Nie vyplnacia ale ze nebudu prezentacne data toto: mozno som ale nepochopil co sa tymi prezenztacnymi datami rozumie. Ako som pozdejsie zistil netusim totiz co sa mysli "pre prístupové miesto zo špecializovaného portálu,“
7. K čl. I
V čl. I sa za bod 38 vkladajú nové body 39 a 40, ktoré znejú:
„39. V § 24 ods. 2 písm. a) sa na konci vkladá bodkočiarka a pripájajú sa slová „prezentačná schéma nemusí byť súčasťou elektronického formulára, ak je používateľské rozhranie pre vyplnenie elektronického formulára poskytované pre prístupové miesto zo špecializovaného portálu,“.