![epl.icm.edu.pl Forum Index](templates/subSilver/images/logo_phpBB.gif) |
epl.icm.edu.pl Forum dyskusyjne o tematach związanych z e-Administracją i digitalizacją
|
View previous topic :: View next topic |
Author |
Message |
kravietz
Joined: 07 Apr 2006 Posts: 9 Location: Kraków
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
lklimek
Joined: 07 May 2006 Posts: 4
|
Posted: Thu May 25, 2006 2:18 pm Post subject: |
|
|
Witam,
chcieliśmy kiedyś wykorzystać ten produkt w naszych zastosowaniach. Po analizie doszliśmy jednak do wniosku, że jego konstrukcja nie tylko jest niepraktyczna, ale także - moim zdaniem - przeczy samej idei XMLa, a przynajmniej jest zaprojektowana niezgodnie z "zasadami sztuki" ;].
Zauważmy, że mamy tutaj do czynienia z jednym formularzem zawierającym jednocześnie dane (czyli to, co w XML jest najważniejsze) oraz informacje o wizualizacji formularza (co powinno być zrealizowane na poziomie XSLT). W konsekwencji formularz o VAT-7 zajmije niemal 200kB. Efekt jest taki, że urząd dysponujący łączem 1Mbit/s jest w stanie odebrać około pół formularza na sekundę. Jak dla mnie to jest to przerost formy nad treścią.
Dochodzi do tego oczywiście problem przechowywania danych. 100 000 osób składających jeden formularz rocznie daje ok. 2 GB na same formularze. Wiem, że na razie nie jest to żaden problem, jednak projektując tego typu system należy wziąć pod uwagę takie czynniki.
Problematyczny może okazać się też sposób podpisywania formularzy. Nie wiem, czy dobrze pamiętam, ale każdy formularz miał być chyba podpisany przez Urząd, do którego wysyłamy dokument lub przez producenta formularzy. Może to powodować problemy z generowaniem formularzy np. z programów księgowych.
Obecnie pracujemy nad rozwiązaniem, w którym formularze zapisywane są w formie "czystego" XMLa. Wypełniony XML zajmuje poniżej 10 kB. Za wizualizację odpowiada XSLT. Ponadto opracowaliśmy sposób weryfikowania formularza wysyłanego do Urzędu w sposób ułatwiający jego wygenerowanie przez inne aplikacje. Ewentualne szczegóły mogę podać na priv. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pemi
Joined: 18 Jan 2006 Posts: 12
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kravietz
Joined: 07 Apr 2006 Posts: 9 Location: Kraków
|
Posted: Sat Jun 03, 2006 2:22 am Post subject: kilka uwag odnośnie formatów |
|
|
Kilka uwag do dyskusji, wynikających z dość szerokiego wglądu w ten rynek jaki miałem w ostatnim czasie. Zapewne część uwag wyda się Panom oczywista, ale lepiej te kwestie poruszyć niż pominąć. Proszę nie odnosić tych personalnie do projektów nad którymi pracujecie, chciałbym raczej skorzystać z faktu że zgromadziło się tutaj dość elitarnego w skali kraju grono i zwrócić uwagę na parę spraw. Deklaracja to tylko jedna z instancji dokumentu elektronicznego i trzeba na tę kwestię spojrzeć nieco szerzej.
1) Nie wydaje mi się, żeby w przypadku faktury elektronicznej (sic!) dodanie prezentacji do dokumentu było błędem. W ten sposób uzyskuje się dokument self-contained, który można sparsować i wyświetlić bez dostępu do zewnętrznych zasobów np. sieci. Wada - oczywiście wielkość, ale...
2) Ze względu na redundancję XML, styli i innych elementów prezentacji narzucającym się rozwiązaniem jest kompresja całości. Dokładnie takie rozwiązanie zastosowano przecież w OpenOffice, który wykorzystuje format OASIS OpenDocument (w wersji 2.0 z XMLsig nota bene) spakowany zwykłym ZIPem. Np. tekst na 18 tys znaków zapisany w ODT ma 24KB, po rozpakowaniu z ZIPa - około 50KB.
3) O ile mi wiadomo analogiczne rozwiązanie wprowadzili do ebForm jego autorzy. Cytowana redukcja wielkości wyniosła tutaj 200KB do 10KB, co w przypadku formatu tak redundantnego jak faktura jest w pełni możliwe.
4) Zgadzam się, że w przypadku e-deklaracji sprawa wygląda trochę inaczej bo a) jeden odbiorca jest zasypywany dokumentami przez wielu petentów (w przypadku faktur odwrotnie), b) deklaracja zwykle wędruje od petenta do urzędu raz i na tym jej życie w sieci się kończy, a prezentacja jest robiona raz petentowi, a dwa urzędnikowi.
5) Trzeba równocześnie pamiętać, że e-dokumenty to nie tylko e-deklaracje i projektowane formaty powinny być perspektywiczne. Np. nie bardzo wyobrażam sobie publikację podpisanych dokumentów urzędowych (interpretacje, akty prawne) w formacie innym niż self-contained. Faktura, którą można otworzyć tylko z dostępem do zewnętrznych arkuszy też trochę traci sens.
6) Jako dygresja, ciekawe rozwiązanie z Austrii, które widziałem w ubiegłym roku na konferencji RSA. Format dokumentu elektronicznego z podpisem, który po wydrukowaniu zachowuje własności "elektroniczne" - po zeskanowaniu można ponownie zweryfikować podpis dzięki wydrukowanemu jako xmlowe źródło nagłówkowi z podpisem i sumami kontrolnymi do skanowania. Przeznaczenie - np. do publikacji ustaw.
7) Jeden z rozmówców na Enigmie zwrócił mi uwagę na poważny problem jakim jest pomijanie kwestii opakowywania w XML dużych bloków binarnych. Nie wiem jak ta kwestia jest rozwiązana w opracowywanych przez Panów formatach, ale warto zwrócić na to uwagę bo ta kwestia już wynikła w praktyce i pewnie będzie wynikać coraz częściej. Ja osobiście zetknąłem się tylko z MTOM, ale technik jest zapewne więcej.
8) Mamy obecnie sytuację, w której kilka zespołów kraju rozwiązuje prawie dokładnie te same problemy. Wiem o conajmniej pięciu, część z nich ma już wdrożone produkty swojego własnego autorstwa (EBF, Winkhaus). Trochę przypomina mi to sytuację, którą mieliśmy po 2001 roku kiedy na rynek wchodziły cztery "komponenty programowe bezpiecznego urządzenia" czterech centrów, co skończyło się czterema niekompatybilnymi formatami.
9) Znowu wracając do "bezpiecznych urządzeń", nasze centra certyfikacji poszły w kierunku - proszę wybaczyć - całkowicie nieużywalnych aplikacji pod Windows. Wydaje mi się, że niedoceniane są możliwości jakie oferują web-services w zakresie odbioru, prezentacji i weryfikacji podpisanych dokumentów. Proszę zobaczyć jak robiona jest weryfikacja dokumentów w Estonii - każdy kto ma przeglądarkę może to zrobić na portalu, ale autorzy systemów F-K mogą korzystać z SOAP API.
Dobrze byłoby nie powtórzyć tych błędów w przypadku e-dokumentów.
Z czysto biznesowego punktu widzenia brak kompatybilności jest zabójczy dla rynku i to bardziej dla otrzymujących (i weryfikujących) faktury niż je wystawiających. Proszę też pamiętać, że w przyszłości zapewne chcielibyśmy wymieniać się fakturami elektronicznymi z krajami Unii. W jakich formatach będziemy to robić? Przy odrobinie dobrej woli ze strony wszystkich zainteresowanych i odrobinie komunikacji można tego uniknąć. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
lklimek
Joined: 07 May 2006 Posts: 4
|
Posted: Sat Jun 03, 2006 11:17 am Post subject: Re: kilka uwag odnośnie formatów |
|
|
kravietz wrote: | 1) Nie wydaje mi się, żeby w przypadku faktury elektronicznej (sic!) dodanie prezentacji do dokumentu było błędem. |
Wszystko zależy od przyjętej definicji "dokumentu". Dla mnie "dokument" to pewien zbiór danych i jako taki nie jest powiązany z żadnym sposobem prezentacji. Daje to nam dodatkowe możliwości - konwersja faktury na format pdf, txt czy nawet wewnętrzny format jakiejś aplikacji księgowej staje się bardzo prosta (XSLT). Co więcej, znam aplikacje które już w tej chwili umożliwiają wczytanie prostych dokumentów XML (nazwy tagów definiowane w konfiguracji). Dodanie do nich dodatkowych atrybutów wizualizujących powoduje, że operacja taka staje się dla użytkownika (nie mylić z "autorem") dużo bardziej skomplikowana.
Ponadto nie widzę powodu (pomijając kwestie organizacyjne), dla którego oba formaty - zarówno bez prezentacji, jak i te z prezentacją - miały nie być ze sobą kompatybilne. Technicznie wystarczyłoby przyjęcie ogólnej struktury dokumentu, nazw tagów itd, i pozostawienie wizualizacji pewnym dodatkowym (opcjonalnym) atrybutom.
Niestety, ze względów organizacyjno-politycznych takie porozumienie nie jest chyba możliwe. Z tego co wiem, były kiedyś prowadzone rozmowy na temat dostosowania kilku formatów do siebie, zakończyły się one jednak niepowodzeniem; zresztą nie było to traktowane jako priorytet.
Moim zdaniem jedynym sposobem na wprowadzenie wspólnego formatu jest narzucenie go przez nasze władze w (jak najbardziej precyzyjnym) rozporządzeniu. Z tym, że jakoś w to nie wierzę.
Ewentualnie można by to przerzucić na barki jakiejś organizacji społecznej; musiałaby ona jednak mieć wsparcie rządowe.
kravietz wrote: | 5) Trzeba równocześnie pamiętać, że e-dokumenty to nie tylko e-deklaracje i projektowane formaty powinny być perspektywiczne. Np. nie bardzo wyobrażam sobie publikację podpisanych dokumentów urzędowych (interpretacje, akty prawne) w formacie innym niż self-contained. Faktura, którą można otworzyć tylko z dostępem do zewnętrznych arkuszy też trochę traci sens. |
Dlatego format powinien pozwalać na dodanie informacji wizualizujących, lecz nie powinny być one wymagane. Moim zdaniem jest to podejście bardzo elastyczne. Z drugiej strony dodawanie informacji wizualizujących powoduje, że (bardzo wygodny do przetwarzania) XML "ewoluuje" pod względem swej struktury w kierunku HTML 4.0, co niezbyt mi się podoba.
Inna kwestia to fakt, że format nie powinien wymagać do wizualizacji żadnego dodatkowego oprogramowania (dokładniej: powinien być zgodny z powszechnie stosowanymi standardami).
kravietz wrote: | 7) Jeden z rozmówców na Enigmie zwrócił mi uwagę na poważny problem jakim jest pomijanie kwestii opakowywania w XML dużych bloków binarnych. |
Zależy co znaczy "dużych". Najprostszą metodą jest umieszczenie zakodowanego np. BASE64 pliku jako wartości jakiegoś tagu. Rozwiązanie niestety niezbyt eleganckie i przy naprawdę "dużych" plikach może powodować problemy (znaczna objętość, znaczne obciążenie parsera).
kravietz wrote: | Mamy obecnie sytuację, w której kilka zespołów kraju rozwiązuje prawie dokładnie te same problemy. Wiem o conajmniej pięciu, część z nich ma już wdrożone produkty swojego własnego autorstwa (EBF, Winkhaus). |
Jak już wspomniałem - moim zdaniem wypracowanie wspólnego formatu jest w praktyce niemożliwe bez ingerencji ze strony władz. Osobiście byłbym jednak zadowolony, gdyby udało się w prosty sposób stworzyć konwertery umożliwiające łatwe przejście z jednego formatu na inny.
Niestety, z tego co wiem, np. we wspomnianym formacie EBF umieszczone są jakieś "dziwne" (z mojego punktu widzenia) podpisy stanowiące "licencję" danego formularza itd. Ta funkcjonalność wzbudza mój niepokój zarówno ze względów - nazwijmy to - polityczno-światopoglądowych, jak i implementacyjnych. Przyznam jednak, że nie badałem dokładniej tej kwestii.
kravietz wrote: | Z czysto biznesowego punktu widzenia brak kompatybilności jest zabójczy dla rynku i to bardziej dla otrzymujących (i weryfikujących) faktury niż je wystawiających. Proszę też pamiętać, że w przyszłości zapewne chcielibyśmy wymieniać się fakturami elektronicznymi z krajami Unii. W jakich formatach będziemy to robić? Przy odrobinie dobrej woli ze strony wszystkich zainteresowanych i odrobinie komunikacji można tego uniknąć. |
Ujmę to tak: "dajcie mi sensowny standard, a się do niego dostosuję". Ze swojej strony staram się tworzyć systemy informatyczne tak, by mógł współpracować z różnymi formatami dokumentów (warunek to XML i możliwość łatwego odnalezienia najistotniejszych informacji). Problem w tym, że terminy gonią niemiłosiernie , a polskie urzędy znów się "obudziły" na ostatnią chwilę... |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kravietz
Joined: 07 Apr 2006 Posts: 9 Location: Kraków
|
Posted: Sun Jun 04, 2006 12:28 pm Post subject: Re: kilka uwag odnośnie formatów |
|
|
lklimek wrote: | Dodanie do nich dodatkowych atrybutów wizualizujących powoduje, że operacja taka staje się dla użytkownika (nie mylić z "autorem") dużo bardziej skomplikowana. |
Mi się wydaje, że jest dokładnie odwrotnie w sytuacji, kiedy user dla sparsowania dokumentu musi zawsze ładować zewnętrzne style lub korzystać tylko z aplikacji webowej.
Quote: | Ponadto nie widzę powodu (pomijając kwestie organizacyjne), dla którego oba formaty - zarówno bez prezentacji, jak i te z prezentacją - miały nie być ze sobą kompatybilne. Technicznie wystarczyłoby przyjęcie ogólnej struktury dokumentu, nazw tagów itd, i pozostawienie wizualizacji pewnym dodatkowym (opcjonalnym) atrybutom. |
Dokładnie o to mi chodzi. Przyglądając się dokładniej EBF widzę, że jest tam sporo rozwiązań, które są dobrze przemyślane i przydatne.
Przede wszystkim EBF może być aktywny (przeliczanie i kopiowanie pól) co jest z czysto użytkowego punktu widzenia bardzo cenne, bo do jego wypełnienia nie trzeba specjalnej aplikacji tylko uogólniony parser (tu akurat napisany w Javie i działający pod Win/Lin/Mac/itd).
Równocześnie EBF może być formularzem całkowicie statycznym, wygenerowanym i wypełnionym przez system. Tak więc ta elastyczność jest.
Quote: | Moim zdaniem jedynym sposobem na wprowadzenie wspólnego formatu jest narzucenie go przez nasze władze w (jak najbardziej precyzyjnym) rozporządzeniu. Z tym, że jakoś w to nie wierzę. Ewentualnie można by to przerzucić na barki jakiejś organizacji społecznej; musiałaby ona jednak mieć wsparcie rządowe. |
Myślę że na warstwie merytorycznej nie będzie problemu żeby uzasadnić konieczność inteoperacyjności i kompatybilności. Najprostszy przykład:
* w formacie PEMI jest drzewko tagów Tytul-idTytulu,Opis
* w propozycji elementów struktury publikowanej na EPL jest Tutul, Opis i inne
Dokładnie to samo, ale minimalnie inne nazwy i struktura. Po co tak komplikować? Brzytwa Ockhama się kłania.
Ta dyskusja jest dla mnie bardzo wartościowa bo poznaję dzięki niej stanowisko strony technicznej. Mamy środki nacisku na stronę biznesową w postaci ISOC-PL i opinii publicznej. A strona biznesowa pierwsze co zrobi to spyta strony technicznej "da się i ile będzie kosztować".
Zresztą słowo "nacisk" jest tutaj trochę nie na miejscu, należałoby raczej mówić o pokazaniu menedżmentowi problemów, które wynikają z braku kompatybilności. Trudno o lepszy argument niż sytuacja na rynku podpisu elektronicznego przez ostatnie 4 lata...
Quote: | Inna kwestia to fakt, że format nie powinien wymagać do wizualizacji żadnego dodatkowego oprogramowania (dokładniej: powinien być zgodny z powszechnie stosowanymi standardami). |
Ale format XML zawsze będzie wymagał jakiegoś oprogramowania do wizualizacji. Pozostają kwestie:
1) czy parser jest wieloplatformowy i darmowy
2) czy format jest otwarty i można napisać własny parser i dokument
3) czy warstwa prezentacji zawsze jest zaszyta w dokumencie (rozmiar), czy może być zaszyta (self-embedded) i czy może być zewnętrzna (optymalizacja rozmiaru).
lklimek wrote: |
kravietz wrote: | 7) Jeden z rozmówców na Enigmie zwrócił mi uwagę na poważny problem jakim jest pomijanie kwestii opakowywania w XML dużych bloków binarnych. |
Zależy co znaczy "dużych". Najprostszą metodą jest umieszczenie zakodowanego np. BASE64 pliku jako wartości jakiegoś tagu. Rozwiązanie niestety niezbyt eleganckie i przy naprawdę "dużych" plikach może powodować problemy (znaczna objętość, znaczne obciążenie parsera).
|
Właśnie o to chodzi, BASE64 daje od ręki przyrost objętości rzędu 25% i obciążenie parsera na dekodowanie. W zastosowaniu o którym rozmawiałem na konferencji narzut ten nie był akceptowalny i był traktowany jako poważny problem.
MTOM XML jest jednym z wariantów osadzania w XMLu danych binarnych - technicznie jest to oczywiście trywialne, ale pod warunkiem że format i parser o tym wiedzą. Dlatego trzeba to uwzględniać podczas projektowania formatów.
Quote: | Niestety, z tego co wiem, np. we wspomnianym formacie EBF umieszczone są jakieś "dziwne" (z mojego punktu widzenia) podpisy stanowiące "licencję" danego formularza itd. Ta funkcjonalność wzbudza mój niepokój zarówno ze względów - nazwijmy to - polityczno-światopoglądowych, jak i implementacyjnych. Przyznam jednak, że nie badałem dokładniej tej kwestii. |
One nie są tak do końca dziwne. Firma zarabia na pisaniu aktywnych formularzy i to jest jej model licencjonowania. Jak dla mnie uczciwy, bo klient płaci za wygodę, ładną prezentację, możliwość integracji z F-K itd.
W przypadku e-deklaracji formularze powinny być dla wysyłającego darmowe - niezależnie od tego czy państwo je napisze i rozda czy kupi i rozda, ale cały czas podkreślam że formularze i dokumenty elektroniczne to nie tylko e-deklaracje.
Ale jeśli chcę wystawiać ładne faktury tradycyjne i elektroniczne z automatycznym wypełnianiem pól to dla mnie jako MŚP wydatek 100 zł za taki EBF to jest tanio i dobrze.
Oczywiście, można z Excela ale Excel kosztuje mnie 20x więcej, a zarówno z darmowego OpenOffice2 jak i Excela nie mogę wystawiać faktur elektronicznych bo nie mają deklaracji zgodności.
Quote: |
Ujmę to tak: "dajcie mi sensowny standard, a się do niego dostosuję". Ze swojej strony staram się tworzyć systemy informatyczne tak, by mógł współpracować z różnymi formatami dokumentów (warunek to XML i możliwość łatwego odnalezienia najistotniejszych informacji).
|
To chciałem usłyszeć :)
Quote: | Problem w tym, że terminy gonią niemiłosiernie :(, a polskie urzędy znów się "obudziły" na ostatnią chwilę... |
Jednostki lokalne są tu najmniej winne. Prowadzę szkolenia z podpisu dla ludzi z jednostek administracji od ponad roku i sam fakt, że na nie przyjeżdżają świadczy o tym że problemem się interesują. Większość wie że trzeba coś zrobić, chcą to zrobić, ale nie wiedzą co i jak. Dla większości urzędów wydanie 32 tys. zł na HSM nie jest czynnością robioną z taką lekkością jak sugeruje to kwietniowa wypowiedź MSWiA.
Bałagan w przepisach jest taki, że bez odgórnych wytycznych urzędy nie są w stanie nic zrobić. I nie powinny, bo będzie to wyrzucenie pieniędzy w błoto. Weźmy choćby kwestię tych nieszczęsnych HSM czy rozporządzenia z art. 58 ust. 3 Ustawy o podpisie, którego nie udało się MG i MSWiA wydać przez 4 lata. Albo pilot e-Deklaracji w MinFin, który w wyniku towarzysko-biznesowych przepychanek opóźnił się "bez powodu" o ponad pół roku. I tak dalej.
A ministerstwa najwyraźniej uważają, że wszystko jest OK skoro 2 miesiące przed wejściem Tego Terminu nikt nie potrafi powiedzieć konkretnie co należy robić - czy będzie nowelizacja, czy termin będzie przeniesiony itd. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kravietz
Joined: 07 Apr 2006 Posts: 9 Location: Kraków
|
Posted: Sun Jun 04, 2006 12:39 pm Post subject: Re: kilka uwag odnośnie formatów |
|
|
lklimek wrote: | kravietz wrote: | 1) Nie wydaje mi się, żeby w przypadku faktury elektronicznej (sic!) dodanie prezentacji do dokumentu było błędem. |
Wszystko zależy od przyjętej definicji "dokumentu". Dla mnie "dokument" to pewien zbiór danych i jako taki nie jest powiązany z żadnym sposobem prezentacji. |
To jest definicja prawdziwa i słuszna tylko wewnątrz jednego systemu informatycznego. W momencie kiedy dokument (faktura, ustawa, interpretacja, odpowiedź urzędu) opuszcza system informatyczny musi stać się mniej lub bardziej self-embedded bo inaczej stanie się zbiorem linków.
A z linkami różnie bywa. Proszę spróbować przesłać mailem stronę WWW i zobaczyć co wyjdzie po drugiej stronie.
Z tego powodu dominującym formatem publikacji dokumentów jest PDF, że jest w 100% self-embedded włącznie z fontami. Proszę sobie przypomnieć co się działo jeszcze parę lat temu z drukowaniem dokumentów Worda jeśli czcionki systemowe różniły się między autorem a odbiorcą.
To dobry przykład pokazujący, że dokument zawierający tylko strukturę wcale nie jest ideałem do którego należy dążyć.
Zresztą dość podobna kłótnia toczy się obecnie pomiędzy zwolennikami formatu OpenOffice (OASIS OpenDocument) a Microsoftowego OpenXML, chociaż mniej chodzi o technikalia a bardziej o to, że OpenXML wcale nie jest taki Open jak się wydaje. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kravietz
Joined: 07 Apr 2006 Posts: 9 Location: Kraków
|
Posted: Tue Jun 06, 2006 4:29 pm Post subject: Re: kilka uwag odnośnie formatów |
|
|
[quote="kravietz"]A ministerstwa najwyraźniej uważają, że wszystko jest OK skoro 2 miesiące przed wejściem Tego Terminu nikt nie potrafi powiedzieć [b]konkretnie[/b] co należy robić - czy będzie nowelizacja, czy termin będzie przeniesiony itd.[/quote]
Z dużą satysfakcją stwierdzam, że się myliłem:
[url]http://security.computerworld.pl/news/94255.html[/url] |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
pemi
Joined: 18 Jan 2006 Posts: 12
|
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
kschmidt Site Admin
Joined: 20 Mar 2005 Posts: 153 Location: NDAP
|
Posted: Tue Jul 25, 2006 10:26 am Post subject: Re: kilka uwag odnośnie formatów |
|
|
kravietz wrote: | W momencie kiedy dokument (faktura, ustawa, interpretacja, odpowiedź urzędu) opuszcza system informatyczny musi stać się mniej lub bardziej self-embedded bo inaczej stanie się zbiorem linków.
A z linkami różnie bywa. Proszę spróbować przesłać mailem stronę WWW i zobaczyć co wyjdzie po drugiej stronie.
|
Choć jestem ostatnio troche mniej aktywny na forum (na ukończeniu są rozporządzenia dotyczące podstaw dla dokumentów elektronicznych) to przyglądam się z zaciekawienim tej dyskusji.
Wg mnie wypowiedź kravietza należało podkreślić węzykiem wytłuścić i pokolorować.
Dodałbym jeszcze do tego że ów zbiór "self-embedded" powinien zawierać także pozostające "na zewnątrz" samej treści dokumentu metadane pokazujące kontekst wytworzenia dokumentu - i to także metadane pełne a nie "wskazanie na metadane" jak wielu uważa. O te metadane i sposób ich zapisania właśnie toczy się ostra walka w uzgodnieniach do rozporządzenia o niezbędnych elementach struktury dokumentów elektronicznych. Przy okazji : to co wisi w BIPie MSWiA i na naszym forum jest nieaktualne. Ale nie wiem czy mogę stan aktualny powiesić na tym forum. Zwłaszcza z uwagami zebranymi w wyniku konsultacji - także i tymi które wiszą na stronie PIIT. To byłaby bardzo pouczająca lektura. Zwłaszcza zestawiając uwagi różnych podmiotów obok siebie.
Ale wracając do cytatu z krawietza: Przyznam się, że nie ufam linkom. I nie będę ufał dopóty dopóki nie dorobimy się pewności że pozostaną niezmienne (nie tylko linki ale i tresci do których się odnoszą). Tak jak odniesienia do wydawnictw drukowanych są niezmienne i czuwa nad tym Biblioteka NArodowa (i sam charakter słowa drukowanego), tak jak odniesienia do papierowych teczek archiwalnych też i czywają nad tym archiwa tradycyjne - tak odniesienia do dokumentów elektronicznych są niezwykle nietrwałe! Wobec tego, że niektóre z nich będziemy musieli przechować przez 50 i więcej lat - jestem sceptykiem.
Np. w projekcie rozporządzenia "w sprawie wymagań technicznych dokumentów elektronicznych zawierających akty normatywne i inne akty prawne, elektronicznej formy dzienników urzędowych oraz środków komunikacji elektronicznej i informatycznych nośników danych" napotkano na podobny problem: czy odwołania do dokumentów zewnętrznych w aktach prawnych mają być wzgędne czy bezwzględne.
Jest w projekcie tekże propozycja przepisu w brzmieniu: "Zapis znaczników nowelizacyjnych, oprócz podania nowego brzmienia treści, wymaga dokładnego określenia miejsca zmiany w postaci identyfikatora zmienianego dokumentu oraz ścieżki adresu zmienianego fragmentu."
Jesli dobrze rozumiem tę ideę stworzymy bowiem dokument - potwora, który będzie się składał praktycznie z samych odwołań i sam w sobie bedzie zawierał wszelkie poprzednie wersje. Może to i wygodne jednak jeśli odwołania te będą zewnętrzne to dziesięć razy zastanowię się czy mam coś takiego zatwierdzić, akceptować, podpisać... Nie wyobrażam sobie żebym podpisał coś czego fragmenty może mi potem zmienić potem ktoś inny... i wcale nie będzie to ingerowało w mój podpis. Dokument będzie nienaruszony, tylko że inaczej będzie wyglądał.
Obawiam się, że pomysły idące w kierunku trzymania zewnętrznej definicji dokumentu, a nawet jeszcze dalej idące pomysły trzymania na zewnątrz dokumentu wszelkich jego nowelizacji zapisywanych jako fragmenty a nie jako CAŁY NOWY dokument, to będzie woda na młyn zwolenników pozostawienia papieru. Argumenty o redundacji danych liczonej w gigabajtach do mnie nie przemawiają. Uważam, że dokument elektroniczny nie tylko powinien być jak najbardziej niezależny od czynników zewnętrznych (a niestety i tak zawsze będzie), to jeszcze jego kolejne wersje powinny być zapamiętywane jako całość, a nie jako zmieniane fragmenty. Dzisiaj, w przypadku przygotowywania ważnego dokumentu (np rozporządzenia), opasłe teczki aktowe zawierają po kilka-naście wersji drukowanych. I to w każdym urzędzie, który się tym zajmował. I nikt się nie martwi redundancją danych liczoną potem w kilometrach półek. Kserografy i drukarki aż dymią i nic nie wskazuje na to że przestaną.... Ale to już inny temat.
Wobec rozmiarów plików wideo zapamiętanie nawet 200 razy pliku tekstowego jest niczym... I tu jak mi się wydaje potrzebny jest po prostu zdrowy rozsądek. Naprawdę nie musimy zapamiętywać wszystkiego - czyli każdej roboczej zmiany w dokumencie. Zanim naciśnie się "zapisz" powinno się sprawdzić czy aby na pewno ta wersja jest OK. Tak samo jest dziś z papierem. Roboczych wersji się przecież nie przechowuje (no chyba że to są poprawki mające istotne znaczenie) a tylko te oficjalne.
Naprawdę mi nie przeszkadza ,że ktoś zapisze dokument w PDF-ie, DOC-u, XML-u czy ODT. Aby go prawidłowo odczytać muszę mieć oprogramowanie, które mi "zwizualizuje" to na ekranie lub papierze. W przypadku potrzeby przechowanie takich dokumentów przez długi czas ilość oprogramowania potrzebna do tego będzie skończona i lista ta będzie dość krótka. W przypadku potrzeby konwersji do nowego formatu ilośc operacji - także. Jeśli jednak do tego aby odczytać dokument będę potrzebował nie tylko oprogramowania ale i odpowiedniego wzorca pozostającego na zewnątrz to po pownym czasie okaże się, że tych wzorców których potrzebuję będzie dziesiątki a nawet setki tysięcy. Oczywiście kwestie dopasowania wzorca do dokumentu będzie załatwiał tzw. "wyróżnik" (zob. m.in. na tym forum http://epl.icm.edu.pl/forum/viewtopic.php?t=85). Można zaplanować, że Centralne Repozytorium Wzorów Dokumentów (jest w Planie Informatyzacji Państwa) będzie działało wieczyście i że nie nastąpi tamże jakieś spektakularne włamanie które zmieni wzorzec o określonym wyróżniku a co za tym idzie setki tysięcy dokumentów zależnych... i to za jednym zamachem.
Na koniec przykład wbrew pozorom związany z tym tematem:
Gdyby nie redundancja dokumentów znajdujących się w IPN można byłoby usuwając pojedynczą teczkę całkowicie usunąć wszelkie informacje o tym co w teczce było. Ale tak nie jest bo powiązane z tą teczką inne teczki pozwalają odtworzyć w części to co zostało usunięte. I ten kto usunął cał teczkę i tak nie ma pewności czy spowodował usunięcie wszelkich powiązanych dokumentów. Nie rozpatruję tego w kategoriach moralnych ale czysto praktycznych. Gdyby było możlwie przez usunięcie jednego wzrocowego zapisu (np w publicznym rejestrze referencyjnym czy w innych wzorze) i to miałoby spowodować zmiany w tysiącach dokumentów zależnych to nie tylko dokonalibyśmy zmiany treści tych dokumentów - byśmy je po prostu sfałszowali. Pokusa zarządzania takim zasobem od którego wszystko zależy byłaby coraz większa. Chętnie więc widziałbym korzystanie i z rejestrów refencyjnych i z wzorów dokumentów ale pod warunkiem że będę stamtąd aktualne metadane brał i wpisywał do mojego dokumentu a nie tylko wskazywał na nie. W ten sposób zabezpieczymy się przez fałszerstwami i nadużyciami najlepiej jak można. Przez powielenie danych w takim zakresie, że fizycznie nikomu nie uda się tego zmienić bo będzie to po prostu nieopłacalne. Wreszcie najważniejsze: jeżeli podpisałem jakiś dokument mieszkając w Bombaju (i podałem adres bombajski) a po pewnym czasie przeprowadziłem się do Warszawy i w kolejnych dokumentach podałem adres warszawski to w tych "starych" adres bombajski musi pozostać! Ponadto mogę wobec innego urzędu podawać adres do korespondencji inny nić jest w rejestrze referencyjnym i co mi kto zrobi? A urząd MUSI dane adresowe zanotować tak jak przyszło a nie tak jak "powinno być"...
A to że będzie tego na jeden dokument parę kilobajtów więcej jest wobec zwiększenia bezpieczenstwa z jednej strony i kilometrów akt papierowych z drugiej strony - niczym. _________________ --
Kazimierz Schmidt |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|