[...]
"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.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Es mi lesz ez a nyilt szabvany? OOXML? :)
A'rpi
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ha ez így van, akkor a törvény vicckategória.
Bár ahogy a kormányt ismerem, a látszat intézkedések nagyon bejönnek nekik.
- A hozzászóláshoz be kell jelentkezni
igen ez egy nagyobb témakört ölel fel és nem arról szól, hogy mindenki átáll odf vagy ooxml-re január 1-től...
B10
- A hozzászóláshoz be kell jelentkezni
Azért az az időpont is eljön valamikor? :-)
- A hozzászóláshoz be kell jelentkezni
FYI: Az OOXML *mar* MSZ szabvany.
- A hozzászóláshoz be kell jelentkezni
Április 1. van?
Kellemes Karácsonyi ünnepeket!
Ez jó lesz a fa alá!
- A hozzászóláshoz be kell jelentkezni
Átnéztem a kezdeményezést, és szeretnék gratulálni mind szándékhoz, mind az elért eredményhez.
- A hozzászóláshoz be kell jelentkezni
Valaki leírhatná ezt "informatikus szemszögből" is, mert én olvastam az eredeti bejegyzést és a butított, konnektoros verziót is, de konkrétumokat egyikből sem tudtam kihámozni...
--------------------
http://ricsipontaz.hogyan.org --- http://fullcircle.hu
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Aham, így már érthetőbb, köszi.
--------------------
http://ricsipontaz.hogyan.org --- http://fullcircle.hu
- A hozzászóláshoz be kell jelentkezni
+1. Én is gratulálok!
- A hozzászóláshoz be kell jelentkezni
+1 gratula és köszi!
- A hozzászóláshoz be kell jelentkezni
+1, reméljük, lesz folytatása még :)
- A hozzászóláshoz be kell jelentkezni
thumbsup!
nagyok vagytok!
-----------
"Generally, Russian technology assumes dumb machines and smart humans, not the other way around." -- The Russian Tea HOWTO
- A hozzászóláshoz be kell jelentkezni
Nagyon jó! Elismerésem! Kellett már az ilyen hír, mint a falat kenyér.
- waiter -
- A hozzászóláshoz be kell jelentkezni
WOW! Gratula nektek!
(A konnektoros hasonlat hatalmas otlet, kivaloan erthetove teszi az egeszet laikusoknak is!)
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Még a végén az MSZP-re szavazok!
(Vicc volt)
- A hozzászóláshoz be kell jelentkezni
A végén még szavazok!
(ez is csak vicc volt!)
--
Не освещать! (Ne gyújts rá!) Не курить! (Ne dohányozz!) Rauchen verboten! (Tilos a dohányzás!) A lényeg, hogy ne angolul legyen! :-{)E
- A hozzászóláshoz be kell jelentkezni
Nem nagyobb marhaság mint bárki másra ezek közül... :)
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
Köszönjük a munkát!!! Ez hatalmas eredmény.
- A hozzászóláshoz be kell jelentkezni
Gratulálok!
Ez már valami. Hihetetlen.
- A hozzászóláshoz be kell jelentkezni
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....
- A hozzászóláshoz be kell jelentkezni
Ez most azt jelenti, hogy imi, nyenyi, stb. is megoldódik?
-
"Attempting to crack SpeedLock can damage your sanity"
- A hozzászóláshoz be kell jelentkezni
valaki el tudna magyarazni ezt a kifejezest, hogy "nyilt szabvanyos", mert most talalkozok vele eloszor
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Ugy tunik nem, de azert gratulalnak hozza :)
- A hozzászóláshoz be kell jelentkezni
http://en.wikipedia.org/wiki/Open_standard
http://hu.wikipedia.org/wiki/Ny%C3%ADlt_szabv%C3%A1ny
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
Az egész megoldás katasztrofálisan szar, valami dilettáns barom belobbizta a cégét a melóra, vagy hasonló, magyar módra
gondolom jókat röhögnek a markukban hogy mít szív vele a nép
- A hozzászóláshoz be kell jelentkezni
Az APEH saját cége a "fő" kivitelező...2MDFt-ból ennyire telik, nem tudtad?
- A hozzászóláshoz be kell jelentkezni
nem ez a probléma gyökere, IMHO
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
KIB 21 - eleg erdekes. Szabadon felhasznalhato az ajanlas barki szamara, mas celra is ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Mit értesz más cél alatt? :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
Akkor ez most azt jelenti, hogy az Ügyfélkapu SAML protokollt fog beszélni vagy mi?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"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."
Es akkor talan mukodni is fog :)
- A hozzászóláshoz be kell jelentkezni
Ahm... szóval azt szeretnéd ezzel mondani, hogy a zárt forráskódtól jobb lesz? :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni