A parlament elfogadta a nyílt szabványos törvénymódosítást

Címkék

"A parlament tegnap este 7 óra 13-kor 197 igen, 1 nem, 146 tartózkodás arányban elfogadta azt a törvényjavaslatot, amely az általunk javasolt nyílt szabványos törvénymódosítást tartalmazta."

"A magyar országgyűlés a heti ülésszakán törvényileg kötelezővé tette a nyílt szabványok alkalmazását a Magyarországi hivatalok, közműszolgáltatók, állampolgárok és önként csatlakozó magáncégek egymás közötti, a központi állami rendszeren keresztül folyó kommunikációjában." (forrás)

[...]

"a továbbiakban az állami hivatalok, a közműszolgáltatók és az állampolgárok e-kapcsolatairól törvény mondja ki, hogy nyílt szabványosnak kell lenniük

[...]

Egyeztetve a kormány képviselőjével, eredeti javaslatunkat radikalizálva(!) adtuk be

Miért radikálisabb az elfogadott változat a korábban javasolthoz képest?

Mert nem nem alternatív nyílt szabványos kapukat nyit a központi rendszeren, hanem kimondja, hogy a hivatali kapunak és az ügyfélkapunak kötelező “közhasznúnak” (= nyílt szabványosnak) lennie. Itt pedig nincs pálya a manőverezéshez: a “közhasznúság követelményeinek megfelelő” kifejezésnek a törvényi definíciója az és csak az, amit mi a nyílt szabvány definíciójaként fejlesztettünk ki még 2007-ben. Ez ellen lehet érvelni, de csak a jogrendszeren kívül. (A “nyílt szabvány” kifejezést állítólag azért nem tudtuk behozni, hogy ne kelljen változtatni a szabványtörvényt.)

Várható [update: a linkek alatt olvasható] egy olyan bejegyzés, amely a döntés hátterét (történetét) írja le, és egy olyan, amely a laikusoknak elmagyarázza a törvénymódosítás jelentőségét.

A részletek itt.

Hozzászólások

Es mi lesz ez a nyilt szabvany? OOXML? :)

A'rpi

Ha jól olvasom a "10 pontot", ennek inkább az Ügyfélkapura és más hasonló rendszerekre van hatása, nem a .doc-ra... De javítsatok ki ha tévedek.

Persze gondolom sokan örülnének egy szabványos abev interface-nek, és egy FOSS kliensnek hozzá...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Április 1. van?
Kellemes Karácsonyi ünnepeket!
Ez jó lesz a fa alá!

Átnéztem a kezdeményezést, és szeretnék gratulálni mind szándékhoz, mind az elért eredményhez.

Valami olyasmi, hogy a hivatali szolgáltatásokat nem pistike bt által tervezett, nem dokumentált, vagy nem elérhető dokumentációjú felületen/protokollon kell megszólítani, hanem mondjuk soap, xml-rpc-n, amihez vannak illesztő programok, dokumentáció, stb.

A hivatalnak meg ki kell adni: így és így ezen adatok ezen formában történő megadásával tudod a szolgáltatásunktól lekérdezni, hogy cégednek mekkora adóhátrléka van ebben az évben.

Szerintem. Mindenképpen üdvözlendő haladás.

--
Drupal alapú weblap készítés | keresőoptimalizálás

thumbsup!

nagyok vagytok!

-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO

Nagyon jó! Elismerésem! Kellett már az ilyen hír, mint a falat kenyér.

- waiter -

WOW! Gratula nektek!

(A konnektoros hasonlat hatalmas otlet, kivaloan erthetove teszi az egeszet laikusoknak is!)

mostantól a jávai ember nálunk is szolgál repülőgép konnektor? (is?) :-)

Nagy "közértésre" azonnal ne számítsunk, de ettől függetlenül nagyon jó ez a leírás, mert segít tisztázni az eddig misztifikált fogalmakat (aki most hallja először annak ez mind nút, dűzni, kuplung, spakni és egyebek)

Még a végén az MSZP-re szavazok!

(Vicc volt)

Köszönjük a munkát!!! Ez hatalmas eredmény.

Gratulálok!

Ez már valami. Hihetetlen.

Semmi hihetetlen nincs ebben, ugyanis az EU-s direktívák miatt ez már elkerülhetetlen volt. Ez pedig kimondja, hogy az interoperabilitást minden tagállamnak biztosítania kell 2010-re. Ezt minden "tűzközelben" levő szervezet tudta, és itt is sokszor volt róla szó. Egyébként, ha tehették volna akkor elhúzzák 2050-ig is....

valaki el tudna magyarazni ezt a kifejezest, hogy "nyilt szabvanyos", mert most talalkozok vele eloszor

--
NetBSD - Simplicity is prerequisite for reliability

Nem tudom, hogy külföldön, illetve többi EU tagállamban az elektronikus ügyfél-hivatal kommunikáció hogyan működik, de én azt látom, hogy nem ez a törvény oldja meg a legnagyobb problémákat.
A törvény olvasatomban azt mondja, hogy a KR-en, azaz a Központi Rendszeren (Ügyfélkapu+Hivatali Kapu) keresztül történő kommunikációnak nyílt és szabványos dokumentumokkal kell történnie. Ez gyakorlatilag a PDF szokott lenni.
Hogy megy ez a folyamat valójában?

Így:
1. Ügyfél letölti az AbevJava programot
2. Az ügyfél letölti a hivatal honlapjáról azt az űrlapot, amivel a hivatallal kommunikálni akar
3. Kitölti az űrlapot az AbevJava programmal
4. Hozzáadja az űrlaphoz a csatolt dokumentumokat (pl. PDF, dosszie állomány)
5. Összecsomagolja a cuccokat az AbevJava segítségével egy KR aktává (titkosított, tömörített)
6. A KR aktát feladja az ügyfélkapun keresztül
7. A Központi Rendszer eljuttatja a KR aktát a megfelelő hivatal hivatali postafiókjába (a címzett azonosítója benn van a KR aktában)
8. Ezzel egyidőben a KR visszaigazolja (nem digitálisan aláírt) PDF formátumban, hogy továbbította a cuccot
9. A hivatal elveszi a postafiókból a KR aktát
10. PDF formátumban visszajelez az ügyfélnek valamilyen üzenetet a feldolgozás eredményéről
11.
12.

Ez eddig is így volt, ezután is így lesz. Ezután is ilyen bonyolult lesz.

A legnagyobb probléma nyilvánvalóan a fenti leírásból is látható: Magyarország minden állampolgára, aki eletronikusan intézi ügyeit (pl. adóbevallás, e-beszámoló beküldés) kliens oldalon kell, hogy aktákat töltögessen az online services korában. Magyarország a kliensoldalon összeganyéjzott formanyomtatványok országa! Milyen király lenne, ha a hivatal a webes felületén keresztül a KIB 21 ajánlásban leírt módon integrálódva az Ügyfélkapu authentikációs moduljával tudna beszélgetni az ügyféllel. De sajnos az e-beszámoló-t sem lehet így bekérni, mert a törvény meghatározza, hogy KR aktát kell használni. A szerencsére a nem életbe lépett elekronikus közbeszerzésről szóló törvény is a KR aktás marhaságra kényszerítette volna a közbeszerzési pályázati kiírásokra történő ajánlat beküldésének, részvételi szándék jelzésének módját.

Szóval ez a nyílt szabványos mese csak a jéghegy csúcsa.

Ez eddig is így volt, ezután is így lesz. Ezután is ilyen bonyolult lesz.

Ezt így találták ki, valóban egyszerűbb lenne, ha lenne egy SSO a hivataloknak, és ha az ember belépett, akkor minden hivatali oldal beléptesse, aztán pedig ott töltögessen ki nyomtatványokat online valamilyen megoldással. Mi legyen a RIA megoldás? Egyszerű HTML? JavaScript? Flash? SilverLight? Aztán éveket lehetne vitázni a választott technológián és azon, hogy melyik hivatal miért épp azt választotta... :)

További probléma, hogy a KR-en átmenő dokumentum forgalom jó részét az APEH felé küldik, és azoknak a dokumentumoknak a jó részét könyvelőprogramok állítják elő, az eBev/ÁNYK pedig csak betölti a program által már kitöltött nyomtatványt és titkosít. Ezt hogyan oldanád meg a hivatal weboldán?
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

1. RIA megoldás. Természetesen gyártófüggetlen, W3C ajánlás által definiált és elterjedt megoldás. (Még akkor is ha én pl. a Silverlight 3-at preferálnám. :)) Tehát standard HTML 4 vagy XHTML 1.0. Opcionális Javascript.
2. Ha jól sejtem, akkor a könyvelőprogramok egy standard kimenetet állítanak elő, amit az ÁNYK megért. Egy upload művelet a kimenetre és kész.

Egy nyomtatvány frissítésekor, hibajavításakor a centralizált, webes megoldással nem úgy kellene frissíteni a nyomtatványokat, hogy kiteszed a letöltő linket, aztán vagy letölti az új verziót az ügyfél vagy nem, hanem egyszer frissítesz szerveroldalon, oszt onnantól kezdve nincs kérdés.
A kitöltőprogramról nem is beszélve.
Sorolhatnám.

Nyilvánvalóan ezek csak a felhasználói kényelmet érintő kérdések. Egy ilyen rendszer esetében más követelményeket is figyelembe kell venni, ami miatt bőben hozható ilyen architektúrális döntés. Szerencsére ez az architektúra kiterjeszthetőnek látszik, csak lassan mozdul.
Azonban a legnagyobb problémát abban látom, hogy még olyan esetekben is ezt a kliensoldali kitöltős megoldást erőltetik, amikor az adott feladatot a web-en hatákonyabban meg lehetne oldani.

Természetesen gyártófüggetlen, W3C ajánlás által definiált és elterjedt megoldás. (Még akkor is ha én pl. a Silverlight 3-at preferálnám. :)) Tehát standard HTML 4 vagy XHTML 1.0. Opcionális Javascript.

Örök vita a vékony kliens - vastag kliens. Már jókora vitára adtál alapot az ötleteddel, hogy legyen HTML+JS. :)

A HTML nem RIA. A JavaScript már hasonlít rá, de normális alkalmazást nem ír az ember HTML+JS kombinációval. Főleg egy olyan rendszer esetén, ahol a terhelés határnapokon érkezik általában...

2. Ha jól sejtem, akkor a könyvelőprogramok egy standard kimenetet állítanak elő, amit az ÁNYK megért. Egy upload művelet a kimenetre és kész.

Ez így van. Most is ez történik. :)

Egy nyomtatvány frissítésekor, hibajavításakor a centralizált, webes megoldással nem úgy kellene frissíteni a nyomtatványokat, hogy kiteszed a letöltő linket, aztán vagy letölti az új verziót az ügyfél vagy nem, hanem egyszer frissítesz szerveroldalon, oszt onnantól kezdve nincs kérdés.

Javasolni kell, és talán változni is fog. Annó hatalmas lépés volt az, hogy Java nyelvű lett a kliensprogram. Ha jól rémlik, akkor JWS alapon is lehet indítani a nyomtatványkitöltőt, és akkor mindig friss. De ebben most nem vagyok biztos.

Azonban a legnagyobb problémát abban látom, hogy még olyan esetekben is ezt a kliensoldali kitöltős megoldást erőltetik, amikor az adott feladatot a web-en hatákonyabban meg lehetne oldani.

Lehetne abba az irányba is lépni. A két véglet között nincs átmenet. Vagy vastagkliens vagy RIA.

Mint említettem volt, a beküldött adatok nagyon nagy részét programok állítják elő, nyers XML tartalmakat hoznak létre, amelyet aztán egyszerű transzformációval a másik oldalon feldolgozhatóvá lehet tenni. A vastagkliens tehát adott, egyszerűen a felhasználók többsége telepített programot használ az adatok előállítására.

Ha weben akarsz kitölteni, akkor is kell olyan interfész _is_, ahova a programok által előállított adatokat kell küldeni, és máris kétszer dolgoztál. A célcsoport - a könyvelők és a bérszámfejtők - nem fognak webes felületen feltöltögetni, mivel az általuk használt programok azonnal feltölthető adatokat generálnak és a havi bevallások miatt a gépükön úgyis telepítve van a vastagkliens.

Lehetne az egyszerű felhasználóknak webes felület, mindez csak elhatározás, igény és pénz kérdése.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Akkor ez most azt jelenti, hogy az Ügyfélkapu SAML protokollt fog beszélni vagy mi?

Jó lenne, bár a NYISSZ egyik tagjának sincs nyílt SSO megoldása - csak nyílt szabványon alapuló szoftvereik vannak, az IBM pedig inkább az inkompatibilis megoldásairól híres, mint a szabványkövetésről... egy kicsit veszélyes is így ez a lobbizás, mert a nyílt szabvány megnevezés alatt be lehet csempészni olyan support- és/vagy licencköteles zárt forrású terméket, hogy abból gond nélkül évekig megélhet egy IBM Magyarország méretű cég...

Szóval simán elképzelhető, hogy az ügyfélkapu jelenlegi nyílt forrású - de szedett-vedett-tákolt interfészű szoftverhátterét lecserélik "nyílt szabványú" interfészre - de zárt forráskódú termékekre.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Tudnál (vagy tud bárki) hivatkozásokat beszúrni, hogy
1. Mit jelent, hogy az Ügyfélkapu szoftverháttere nyílt forrású?
2. Miben érinti ez a törvény az Ügyfélkaput? Újra kell tervezni? Le kell cserélni a felhasználó-azonosítási (?, minden más?) interfészét? Kidobják az egészet?

Itt van egy cikk a témában:
http://www.hwsw.hu/hirek/43420/emagyarorszag-magyarorszag-hu-portal-koz…

Ahogy olvasható, gyakorlatilag Red Hat stack alapon fog menni nemsokára, hacsaknem a témaindító törvény alapján jön majd az IBM és mindent lecserélnek zárt forrásra de nyílt szabványra (bármit is jelentsen ez az utóbbi)... :)

Érdekelne, hogy a témához ujjongva hozzászólók megértették-e a törvény szövegezésének a hátterét, vagy csak addig olvasták, hogy "nyílt"?
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD