A hatóság hiánypótlási felhívásában azt állítja, hogy a benyújtott dokumentum nem PDF/A formátumú? És csak ennyit? Ön szerint megfelelt a szabvány előírásainak és most tanácstalan? Nyugodjon meg, a helyzet sokkal rosszabb annál, mint amire számít!

A témát már korábban tárgyaltam készítési vonatkozásban és a nazca.hu már a szabványos megfelelőséget is tárgyalta. A probléma mindaddig elméleti, míg a hatóság nem ragaszkodik a jogszabályi előíráshoz.A jogszabály ugyanis előírja a PDF/A formátumot, mely egy szabványnak való megfelelőséget takar. A PDF/A szabványnak alszabványai léteznek (PDF/A-1a, PDF/A-2a, PDF/A-3a, PDF/A-1b, PDF/A-2u, PDF/A-3u, PDF/A-2b, PDF/A-3b), de a jogszabály bármelyik alszabvány szerinti megfelelőséget megengedi.

De mitől, megfelelő egy fájl? Miként lehet ezt leellenőrizni? Egy hatóság miként tudja minden kétséget kizáróan azt állítani, hogy egy dokumentum nem PDF/A? Úgy, hogy ezt később a bíróság előtt a szakértő is alátámassza?

A gyakorlatban két említendő ellenőrzési pont alakult ki: az ÉTDR feltöltéskor ellenőrzi a fájlt, valamint az ügyintéző is ellenőrzi saját eszközével. A probléma - a bevezetőben említett esetben - ott van, hogy az ügyfél által feltöltött dokumentumot a hatóság nem megfelelőnek ítéli. Azaz, az építésügyi hatóság ügyintézőjének vizsgálati követelménye szigorúbb, mint az ÉTDR-é. Hoppá. Ezek szerint vagy az ÉTDR nem vizsgálja azt, hogy a feltöltött dokumentum megfelelő, vagy a hatóság téved. Vagy mindkettő. De ki dönti el a vitát?

A gyakorlatban a hatóság a PDF megtekintő szoftverével vizsgál: ha az Acrobat Reader egyezőséget jelez, akkor elfogadja, ha nem jelez, akkor nem fogadja el. Azaz a hatóság elfogadja bizonyítási eszközként a szoftvert. A kérdés: szabad? A szoftver valóban kalibrált és tanúsított tanúsító?

Mi más vizsgálati módszer létezik még? Számos megoldás közül egy online validátort citálnék ide, a PDF Tools AG-tól. Ez már cizelláltabb eredményt ad. Igen szigorú a vizsgálata, sokkal szigorúbb, mint a PDF olvasóké. És tételesen felsorolja a vizsgálati eredményeket. Számos fájlal való vizsgálódás után el is bizonytalanodhat az egyszeri felhasználó. Sőt, ha kipróbálja az ÉTDR sablonjával a hatóság által készített kiadmányt, akkor is olvashatja a bűvös sort:

"The document does not conform to the requested standard."

Tehát a kérdés egyre inkább izgathatja az embert: hogyan és mivel készítse azt a dokumentumot, hogy a fájlt elfogadja a hatóság.

Jelen sorok írója korábban szorgalmazta, hogy az LLTK (az ÉTDR üzemeltetéséért és fejlesztésért felelős állami cég) készítsen vagy vásároljon egy PDF/A készítő alkalmazást, vagy legalább egy validátort üzemeltessen. Ez a javaslat elvetésre került, helyette csak a GYIK-ba került egy felsorolás 8.1.5. Támogatott PDF/A készítő szoftverek címmel.

Ismert tény, hogy az informatikai szabványok értelmezése a fejlesztők körében elég rugalmas. A PDF/A esetében is ez a helyzet. Egyes tulajdonságok vagy kritériumok teljesítését egyes termékek tekintetében nem veszik olyan szigorúan a fejlesztők. Az Acrobat Reader vizsgálata sem teljes, csupán a fejlesztő saját termékei esetében fontosnak tartott kritériumokat kezeli. (Update: hozzáértő informatikusi forrás állítása szerint még a saját specifikációját sem minden esetben fogadja el.)

Azt is lehet tudni, hogy igazán nem az a lényeg, hogy a fájl szerkezetében valamiféle utalás legyen a megfelelőségre, hanem az, hogy pl. a betűtípus legyen beágyazva a dokumentumba (ez könnyen ellenőrizhető a fájl tulajdonságaiban), ne tartalmazzon űrlapmezőt vagy dinamikusan változó adatot. És még pár kritériumot meg lehetne fogalmazni. A hozzáértő dokumentumspecialisták biztosan képesek lennének egy műszaki specifikációt rittyenteni arról, hogy mi az elvárás. Az ÉTDR nyilván ismeri ezeket, hiszen ő is vizsgál valamit. (A vizsgálatra azért van szükség, hogy ne záradékoláskor derüljön ki, hogy nem lehet aláírni a fájlt.)

De miért nem lehet akkor ezt egyértelműen a hatóságok és az ügyfelek tudomására hozni? Ennek hiányában csak a vita megy a hatóság és az ügyfél között. A hatóság persze nem rendelkezik olyan mély informatikai ismeretekkel, hogy le tudná írni a nem megfelelőség mibenlétét (azaz a szabvány egyes pontjainak való nem megfelelőségét képtelen megnevezni), így felsőbb fokon könnyen bukta lehet belőle. De tényleg olyan hatósági rendszert szeretnénk, ahol nem az épületekről, az épített környezetről beszélünk, hanem informatikai szabványokról?

Ja, és még valami. Egyes, a nem az építészeti-műszaki dokumentáció részét képező dokumentumok formátumára az elektronikus ügyintézés részletes szabályairól szóló 85/2012. (IV. 21.) Korm. rendelet 30. § (1) bekezdése mérvadó. És a 29. § szerint a hatósági értelmezését, mint irányadó különös szabályt az elektronikus tájékoztatás szabályai szerint elektronikus úton közzé kéne tenni. Ez lehetne vitaalap. Ki találkozott már ilyennel?

Nehéz helyzetben van a hatóság. Ellenőriznie kell valamit, amihez nem ért. Jó lenne segítséget adni neki. Egy olyan szép világot vizionálok, ahol a hatóság és az ügyfél - az ügyintézési határidőt jelentős mértékben növelve - nem folytat vitát azon, hogy az irat adathordozó anyaga megfelelő-e. Ahol a hatóság is képes olyan dokumentumot készíteni, amit az ügyfélen számon kér. Álmodom?