epl.icm.edu.pl

madyogi · Joined: 24 Jun 2005 Posts: 2 Location: Chodzież

Stoję (i dwóch współpracowników) przed problemem utworzenia e-urzędu. Jasne jest dla mnie, że z czasem w urzędzie zacznie się gromadzić mnustwo dokumentacji podpisanej cyfrowo (głównie będą to z pewnością jakieś dok'i).
1. Chciałem zapytać jak powiązać te pliki z formatem XML, tak by można było je poddać archiwizacji zgodnie z opracowywanym standardem EPL? Czy pojedyncze dokumenty (bądź całe ich archiwa) będą musiały zostać "opakowane" w tagi XML'owe i zapisane w formacie XML? (Czy nie uszkodzę w ten sposób cyfrowo podpisanego dokumentu, unieważniając go tym samym?) Czy też pliki XML'owe będą faktycznie tylko "metainforamcją" o innych plikach. Tak, że ingerencja w cyfrowo podpisane materiały nie będzie konieczna? Przykład: "archiwumrada2004.zip" (z uchwałami rady za 2004r.) bedzie sobie leżało na jakimś serwerze ftp, ktoś zainsteresowany zaprzęgnie do pracy wyszukiwarkę, której zadaniem będzie odszukanie w zbiorach XML odpowiedniej informacji, o archiwum łącznie z linkiem na serwer FTP do szukanego zbioru?
Dodam, że nie wszystkie materiały mają charakter publiczny - np sprawy obywatelskie (paszporty). Tu się kłania drugie elektroniczne archiwum, do którego nikt nie ma wejścia poza adminem (i szefem Very Happy

, no i grupą pracowników merytorycznie zajmującym się danym tematem). Czy takie archiwum też "standaryzować" domniemam, że tak. Smile

wkuk · Joined: 24 Jun 2005 Posts: 1 Location: Poznań

może jest tu miejsce na coś, co byłoby odpowiednikiem HTMLowego <BODY></BODY> ? wewnątrz tego byłoby miejsce na KOMPLETNY dokument zapisany w tagach XML, a jeśli się nie da (jeśli jest to plik typu JPG/PDF), zawartość binarna byłaby zakodowana np. w BASE64, lub zawarty byłby tam odnośnik do załącznika, wraz z danymi typu suma kontrolna, md5, typ mime....

myślę, że gdyby istniała możliwość bezpośredniego umieszczenia, czy transportu dokumentu w formie XMLowej, byłoby to z pożytkiem dla całej technologii - wymusiłoby na producentach oprogramowania, a w dalszej kolejności na ich klientach, pewne zdrowe nawyki - przeciwne do opisanych przeze mnie poniżej:

Nadzoruje pracę kilkudziesięciu Biuletynów Informacji Publicznej - dane o dokumentach umożliwiają eksport z oprogramowania BIP metadanych w formacie zbliżonym do e-PL, natomiast irytujące nieco jest to, że same dokumenty umieszczanie przez pracowników urzędów, często sprowadzają się po prostu do skanów pism papierowych, zaś w polu przeznaczonym na treść dokumentu widnieje jedynie zdanie: "Treść uchwały w załączniku". Pytani przeze mnie urzędnicy odpowiadali, że tylko skan dokumentu papierowego ma wystarczającą "powagę" (!) - a szkoda, bo ten sam dokument zapisany choćby w formie HTML, czy XML "waży" kilkadziesiąt razy mniej - i co ważne, daje się CAŁY przeszukiwać po słowach kluczowych.

Mamy więc tutaj nonsensowny łańcuch typu:
1. komputer (edytor tekstu)
2. wydruk na papier
3. pogniecenie, pobrudzenie, parafka, pieczątka
4. niewyraźny skan (czasem o zgrozo BMP 10 MB)
4a. ewentualne spakowanie rar/zip
5. umieszczenie w BIP, czy w oprogramowaniu do pseudo "obiegu dokumentów" - bez szans na późniejsze sensowne wykorzystanie (chyba że zapłaci się grube miliony firmie, która masowo skanuje i OCRuje dokumenty, żeby wrócić do punktu 1)

kroki 2,3,4,4a wydają się zbyteczne i de facto "niszczące", a jednak podejście do dokumentu jako do "załącznika" (sam widziałem na kilku konferencjach) powoduje, że zwykły urzędnik nie dostrzeże różnicy między załącznikiem .txt a załącznikiem .bmp - a jeśli już dostrzeże, będzie to w najmniej oczekiwanym momencie, gdy trzeba będzie znaleźć np. ważne pismo znając jedynie mało istotny fragment tekstu "ze środka".

jarwyp · Joined: 14 Mar 2005 Posts: 138 Location: ICM

e-PL w zamierzeniu było przeznaczone do istnienia niezależnie od fizycznego dokumentu. Przemawiało za tym kilka argumentów:
- metadane do dokumentu mogą istnieć nawet wtedy gdy dokument już nie istnieje
- metadanych w postaci zaproponowanej w e-PL nie da się umieścić w bardzo wielu formatach
- konieczność umieszczenia podpisów cyfrowych (tworzących ciągi podpisów) narzuca pewne ograniczenia
Oczywiście najlepiej by było aby metadane były zintergrowane z dokumentem, ale jest to możliwe tylko i wyłączenie w odniesieniu do niewielu formatów (MS Doc w XML'u, OpenOffice 1.0, OpenDocument). W niektórych formatach z kolei możemy dołączyć metadane jako dane opisowe (PDF, JPEG, PNG), ale tworzy to bardzo poważne problemy przy podpisie cyfrowym.
Idea z umieszczaniem treści dokumentu w XML'u metadanych ma zalety i wady:
Zalety:
1. Łatwiej to przekazywać - jest jeden plik
Wady:
1. Trudniej to odczytać - potrzebny jest dodatkowy konwerter, który umożliwi wyciągnięcie i ponowne wstawienie dokumentu do takiego konwertera.
2. Trudniej przechowywać - Duże dane binarne są zbyt ciężkie na plik metadanych i wydaje mi się, że łatwiej określić lokalizację dokumentu jako URL do ftp'a niż umieszczać dokument w metadanych.

Oczywiście to tylko moje zdanie. Nic nie stoi na przeszkodzie aby każdy mógł sobie e-PL rozszerzyć o element dane, w którym umieści całość dokumentu. Musi jedynie uważać na następujące sprawy:
1. przy przekazywaniu metadanych na zewnątrz urzędu powinny one zostać skonwertowane do czystego e-PL.
2. przy podpisach cyfrowych należy uwzględniać tylko elementy standardu.

Co do ograniczenia dostępu, to element Dostęp w standardzie umożliwia określenie, że dany dokument nie jest dostępny publicznie, bądź jest dostępny z pewnymi ograniczeniami. Reszta to kwestia technologii zaprzęgniętej do przetwarzania danych.

Co do dobrych nawyków: nie wydaje mi się, aby wymuszenie dodawania do metadanych całego dokumentu wpłynęło na poprawę jakości tworzonych dokumentów. Po prostu zamiast metadanych i 10MB pliku BMP zostanie przekazany plik XML gdzie znajduje się 14MB zakodowanego w base64 BMP (40% narzutu). Lepszym rozwiązaniem jest określenie dopuszczalnych formatów zapisu : OpenOffice, OpenDocument, MS Word XML, HTML, TXT, TIFF, JPEG, PNG,... - mam niejasne obawy, że tego typu ogranieczenia powinny pojawić się w instrukcjach kancelaryjnych i właśnie nad tym (m. in.) będzie deliberował zespół w archiwach.

jarwyp · Joined: 14 Mar 2005 Posts: 138 Location: ICM

Wydaje mi się, że problem rzeczywiście został przez twórców ePL zignorowany. Nie jest nigdzie opisane jak - z technicznego punktu widzenia mogłaby wyglądać taka integracja, a w szczególności, że taka integracja to nie jest li tylko zadanie dla dużych dostawców oprogramowania (którzy sami sobie to wymyślą). Mogę się podjąć wyprodukować taki sugerowany przepis na podstawy technologiczne tworzenia systemów obsługujących e-PL, ale wolę poczekać na choćby wstępne ustalenia odnośnie zasad postępowania. Są w trakcie tworzenia i jak tylko będzie coś więcej wiadomo i NDAP dostarczy przykładową instrukcję kancelaryjną dla dokumentów elektronicznych. Póki co stworzę odpowiedni temat w forum e-PL 0.2 i tam można będzie dyskutować o technicznych aspektach e-PL'a. Zapraszam.