Centralne Repozytorium Wzorów Pism w Formie Dokumentów Elektronicznych
Kilka dni temu pisałem, że Przepisy dot. sporządzania i doręczania pism obowiązują i chodziło o to, że weszło w życie stosowne rozporządzenie. Dziś zaś spieszę donieść, iż uruchomiono Centralne Repozytorium Wzorów Pism w Formie Dokumentów Elektronicznych - co wynika z tego właśnie rozporządzenia.
Na mocy rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 27 listopada 2006 r. w sprawie sporządzania i doręczania pism w formie dokumentów elektronicznych, a konkretnie na podstawie § 3. ust. 4 tego rozporządzenia: minister właściwy do spraw informatyzacji tworzy i udostępnia organom administracji publicznej centralne repozytorium wzorów pism w formie dokumentów elektronicznych.
W takim centralnym repozytorium umieszcza się, przechowuje i udostępnia wzory pism, które:
- spełniają wymagania określone w przepisach wydanych na podstawie art. 16 ust. 3 ustawy o informatyzacji;
- spełniają wymagania określone w przepisach wydanych na podstawie art. 18 pkt 1 ustawy o informatyzacji;
- uwzględniają niezbędne elementy struktury dokumentów elektronicznych określone w przepisach wydanych na podstawie art. 5 ust. 2a ustawy z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (Dz. U. z 2006 r. Nr 97, poz. 673, Nr 104, poz. 708, Nr 170, poz. 1217 i Nr 220, poz. 1600)
Centralne Repozytorium Wzorów Pism w Formie Dokumentów Elektronicznych dostępne jest pod adresem: www.crd.mswia.gov.pl. Nie ma tam jeszcze zbyt wielu danych. Można już zastanawiać się jednak nad takimi kwestiami jak dostępność tego zasobu dla obywateli, ze szczególnym uwzględnieniem zasad accessibility i niezależnie od przeglądarki, z której ktoś akurat będzie korzystał.
W komunikacie MSWiA można znaleźć również następujący dokument: Definicja struktury danych XSD dla opisu wzorów dokumentów elektronicznych przyjmowanych w Centralnym Repozytorium Dokumentów (PDF, 23 strony). Zgodnie z tym dokumentem wzór elektroniczny jest określony trzema plikami, na które składają się:
- Opis wzoru dokumentu elektronicznego w postaci pliku XML
- Definicja struktury danych dokumentu elektronicznego w postaci pliku XSD
- Opis wizualizacji – przekształcenia dokumentu elektronicznego w postaci pliku XSL
Opublikowany dokument, o którym wyżej mowa, jest adresowany do "osób technicznych, przygotowujących wzorce elektroniczne do publikacji w Centralnym Repozytorium Dokumentów". Takie informacje również trzeba jakoś wyspecyfikować.
No tak. Coraz bardziej kod zastępuje prawo i w wielu sytuacjach to raczej nieuniknione. Zastanawiam się co się stanie, gdy legislacyjny programista przygotowując wzorce gdzieś tam zrobi błąd. Mylić się jest rzeczą ludzką - to dla mnie oczywiste, że każdy ma prawo do błędu. Zastanawiam się tylko nad tym jak zmieni się sytuacja (w sferze ogólnospołecznej) wobec relatywnie nowego zjawiska, wielokrotnie postulowanego i przez wielu pożądanego - stopniowej algorytmizacji procesy przygotowania, ogłaszania i stosowania prawa. To może być interesujące pole badań.
W podlinkowanym wyżej dokumencie znajdują się kolejnych elementów struktury XML. Opublikowano tam m.in. coś, co w świecie XML nazywa się "schemą" - XML Schema Definition (XSD). Taka "schema" opisuje strukturę dokumentu XML: jakie elementy i atrybuty mogą się w dokumencie pojawić, jaka jest zależność "pokrewieństwa" między elementami (które są podrzędne w stosunku do innego), porządek, w którym te "dzieci" powinny występować, które z elementów mogą być "puste", a które muszą zawierać dane, typ danych przypisanych do konkretnych elementów, czy są i jakie są domyślne wartości związane z elementami...
Ważna jest składnia, ważne są wielkości użytych znaków, ważny jest każdy użyty znak...
Jest tam też "Element: PodstawaPrawna". Opis zaś ograniczono do "Identyfikuje akt prawny, w którym". Tak jakby coś komuś umknęło? W opisach innych elementów jest coś po słowach "w którym" - np. "w którym prezentowany wzór może być wykorzystywany". W przypadku Podstawy prawnej dokument zawiera jedynie "w którym" i tu twórca tego opisu być może został rażony strzałą, albo zaatakował go królik-morderca z filmu "Monty Python i Święty Graal". Jest też przykład dodany do tego elementu:
< PodstawaPrawna> xsd:string </PodstawaPrawna>
Akurat w tym przypadku nic się wielkiego nie dzieje, gdy po pierwszym znaku "<" znajduje się spacja, ale na tym przykładzie chciałbym zastanowić się nad tym, co by było, gdyby gdzieś w bardziej newralgicznych miejscach pojawiła się zbędna spacja, literówka, inna niż zamierzana wielkość litery - to wszystko może mieć wpływ na poprawność udostępnionej schemy (a czy może mieć później wpływ na skuteczność złożenia wniosku o dokonanie wpisu w rejestrze przedsiębiorców? A - jako się rzekło - kod powoli zastępuje prawo. Czekają nas nowe wyzwania.
W przykładowym wzorze otworzono element PodstawaPrawna, ale nie ma zamknięcia tego elementu analogicznego do innych elementów - czy takie "zamknięcie" być musi? Swoją drogą - jeśli "algorytmizujemy prawo", to pojawia się też pole do stosowania wszelkiego rodzaju automatycznych "walidatorów" - mechanizmów sprawdzania poprawności przyjętej składni przygotowywanych wzorców czy dokumentów.
Dokument, który powyżej przywołuję zawiera definicję struktury danych XSD dla opisu wzorów dokumentów elektronicznych przyjmowanych w Centralnym Repozytorium Dokumentów. A więc stanowi podstawę dla publikowania wzorów. Jest niejako pierwszym z całej rodziny definicji struktur, bo potem poszczególne dokumenty w Centralnym Repozytorium będą miały własne definicje. Na każdym etapie można gdzieś walnąć literówkę czy inny błąd. Zastanawiam się nad konsekwencjami tego typu sytuacji dla "zwykłych użytkowników". Gdyby się pojawił - błąd można poprawić w miarę szybko, ale czy wpływa to na poprawność/skuteczność złożenia pisma do urzędu? Jak wpłynie na bieg terminów? Czy może powstać szkoda? Jak ją wykazywać i potem udawadniać? Na tym polegają nowe wyzwania dla prawników.
- Login to post comments
Piotr VaGla Waglowski
Piotr VaGla Waglowski - prawnik, publicysta i webmaster, autor serwisu VaGla.pl Prawo i Internet. Ukończył Aplikację Legislacyjną prowadzoną przez Rządowe Centrum Legislacji. Radca ministra w Departamencie Oceny Ryzyka Regulacyjnego a następnie w Departamencie Doskonalenia Regulacji Gospodarczych Ministerstwa Rozwoju. Felietonista miesięcznika "IT w Administracji" (wcześniej również felietonista miesięcznika "Gazeta Bankowa" i tygodnika "Wprost"). Uczestniczył w pracach Obywatelskiego Forum Legislacji, działającego przy Fundacji im. Stefana Batorego w ramach programu Odpowiedzialne Państwo. W 1995 założył pierwszą w internecie listę dyskusyjną na temat prawa w języku polskim, Członek Założyciel Internet Society Poland, pełnił funkcję Członka Zarządu ISOC Polska i Członka Rady Polskiej Izby Informatyki i Telekomunikacji. Był również członkiem Rady ds Cyfryzacji przy Ministrze Cyfryzacji i członkiem Rady Informatyzacji przy MSWiA, członkiem Zespołu ds. otwartych danych i zasobów przy Komitecie Rady Ministrów do spraw Cyfryzacji oraz Doradcą społecznym Prezesa Urzędu Komunikacji Elektronicznej ds. funkcjonowania rynku mediów w szczególności w zakresie neutralności sieci. W latach 2009-2014 Zastępca Przewodniczącego Rady Fundacji Nowoczesna Polska, w tym czasie był również Członkiem Rady Programowej Fundacji Panoptykon. Więcej >>
W przykładowym wzorze
Element PodstawaPrawna jest zamknięty. Dokładniej jest to element pusty ("/" na końcu) , tożsamy z
--
Bartosz Małkowski
xmpp: bmalkow@malkowscy.net
Ano właśnie
Wprowadza nas to na nowy etap oceny stanu rzeczy. Bo trzeba mieć specjalistyczną wiedzę techniczną, by - dajmy na to - znać dokładnie specyfikacje i potrafić ją ocenić. Nowe wyzwania dla prawników. Nowe wyzwania.
--
[VaGla] Vigilant Android Generated for Logical Assassination
Każda nowa technologia
Każda nowa technologia wprowadza "nowe wyzwania". Nie sam prawnik chyba będzie oceniał XSD a raczej do spółki z informatykiem ("Zapisz mi w tym dokumencie to-a-to-z-tym" "Nie da się"/"Ok" i już mamy ocenę, którą nietechniczny prawnik zrozumie).
Bartosz Małkowski
xmpp: bmalkow@malkowscy.net
Tag "Podstawa prawna" jest
Tag "Podstawa prawna" jest poprawnie zamknięty:
http://www.featureblend.com/xml-closing-tag.html
Centralne Repozytorium. Na stronie nie "gov" ???
W swojej naiwności sądziłem, że centralne repozytorium dokumentów będzie w nazwie domeny miało "gov". Owszem link linkiem, ale oznaczenie "gov" określa, że jest to witryna rządowa i jako taka jest finansowana z centralnego budżetu, a nie budżetu lokalnej administracji.
Ale wrócę do sedna sprawy.
Chyba coś nie jest tak jak chciałem.
Kliknąłem sobie na link www.crd.mswia.gov.pl zawarty w artykule.
W odpowiedzi dostałem działającą stronkę. Banner MSWiA jest, tyle tylko, że adresik jest już: http://crd.uml.lodz.pl/Strony/Default.aspx
A to jak widać stronka Urzędu Miasta Łodzi. Czyżby ktoś podlinkował się do przykładowej strony repozytorium w rozruchu? Możliwe, że ja nie umiem uruchomić właściwej strony ze wskazanego dowiązania.
Owszem strona działa. Szkoda tylko, że ta stronka bez przerwy "wali" komunikatami o błędach w skrypcie java. Błędy w kodzie na stronie chyba nie świadczą dobrze o projekcie. Ale zapewne IE się nie czepia. No cóż, ale nie wszyscy korzystają z IE. Tego faktu, zapewne ani urząd ani firma wykonująca portal nie dostrzegają. Możliwe, że działa zdanie orzekające "ja się na komputerach nie znam". Jeśli tak, to wielka szkoda.
Ciekawe jak jest u tej firmy realizującej zamówienie realizacji portalu, ze znajomością obowiązujących ustaw i rozporządzeń dotyczących informatyzacji podmiotów realizujących zadania publiczne. Konkretnie chodzi o rozporządzenie ustalające minimalne wymagania (Dz.U. 2005 Nr 212 poz. 1766)
W kodzie strony można odnaleźć zapis:
Widać jakim narzędziem była tworzona.
Ale to chyba zwykłe czepiactwo z mojej strony. Wszak urzędy siłą bezwładu decyzyjnego, sprawią aby system z Redmont był jedynym słusznym!
A każdy kto będzie usiłował promować coś innego, co nie wymaga aplikacji na MS. Będzie skazany na gospodarczy niebyt.
Ciekawe czy ogłaszający przetargi zdają sobie sprawę, że swoim podejściem do zagadnienia sprawiają, iż podatnik płaci ciężką kasę? Wszak aplikacje na MS nie są najczęściej GPL czy GNU. :)
W cenę produktu o ile wiem, wlicza się koszty na licencje i sprzęt do wytworzenia produktu.
Pozdrawiam.
zalezy
To zalezy, moze to byc Windows Sharepoint Services dolaczany do kazdego Windows Server 2003, a mimo banialukow srodowiska linuxowego to system bardzo stabilny. Rownie dobrze moze to byc Sharepoint Portal, ktory juz wiaze sie z wiekszym wydatkiem i podejrzewam, ze to pewnie portal lezy w tle. Niemniej jednak po co odkrywac ameryke od nowa skoro rozwiazanie juz jest? Jesli chodzi o wsparcie innych przegladarek niz IE, to w zakresie podstawowych funkcji (pobieranie dokumentow np) nie ma z tym problemu...
"Rozwiazanie juz jest"?
Hm... taka wypowiedz "po co odkrywac ameryke od nowa skoro rozwiazanie juz jest?" mialaby moze sens gdyby MS Sharepoint Server byl jedynym istniejacym systemem CMS. Ale przeciez tak nie jest - zastosowanie kazdego innego CMSa (np. takiego ktory jest wolnym oprogramowaniem) byloby tez skorzystaniem z "rozwiazania ktore juz jest". Wiec dlaczego akurat MS?
Ruch w dobrą stronę
Jako specjalista w dziedzinie podpisu elektronicznego uważam, że jest to ruch w dobrą stronę. W tej chwili jednym z największych wyzwań jeśli chodzi o użycie podpisu kwalifikowanego w systemach informatycznych jest brak standardów jeśli chodzi o formaty dokumentów. I nie chodzi tu o podstawowy nośnik jak na przykład XML lub XaDES, ale o konkretną formę np. faktury.
Rozwiąże to również mnóstwo problemów w systemach obiegu dokumentów
Podpis a standard dokumentu.
A nie jest tak, iż podpisywany jest plik jako całość, w takim przypadku jego zawartość dla podpisu jest drugorzędna - podpis gwarantuje, iż otrzymany przez adresata plik jest takim samym plikiem jaki wysłał nadawca? W takiej sytuacji nie ma znaczenia co jest wewnątrz.
tylko jak to zintegrować...
Teoretycznie - tak,
Tylko wyobraź sobie np. fakturę elektroniczną. Możesz ją dostać np. w PDFie, arkuszu Excella czy czymkoliwk - byle zabezpieczone przed zapisem i podpisane. To wszystko będzie plik.
A teraz powiedz mi, jak takiego pdfa podpiąć do programu księgowego? Trzeba przeklepać ręcznie / ew. kopiuj-wklej. Bo pdf nie jest formatem przechowującym _DANE_ a raczej obraz dokumentu czytelny dla człowieka, identyczny na ekranie jak i wydruku.
No to może prześlijmy dane w pliku XML... No dobra, ale jak człowiek ma go odczytać? Poza tym, czy odbiorca ma ten sam schemat?
A w ogóle jaką mamy pewność, że dostaniemy tę faktrurę w formie innej niż np. skan papierowej? To też można podpisać cyfrowo...
Poza tym podpis elektroniczny weryfikuje program będący samodzielną jednostką. Weryfikujesz plik, oglądasz, fajnie wygląda :)
Ale Twoje oprogramowanie automatycznie tego nie przetworzy...
Dopóki nie będzie standardowych dokumentów poszczególnych typów (jak faktura) oraz firmy będące w Polsce centrami uwierzytelniania nie udostępnią API do oprogramowania, by można było je zintegrować do każdego programu, dokumenty elektroniczne nie przyjmą się.
Nie przyjmą się, bo będą niczym więcej jak elektronicznymi kartkami papieru, z których można tylko rzeczy przeczytać, ale nie da się (w łatwy sposób) wprowadzić ich do istniejących systemów informatycznych przedsiębiorstw.
Standardy są koniecznością. Dobrze przemyślane standardy...
P.S. Zaznaczam, że nie jestem ekspertem w dziedzinie podpisu elektronicznego i powyższa opinia może być błędna lub niepełna.
Jestem informatykiem, ale nie miałem osobiście styczności z podpisem elektronicznym ważnym w rozumieniu prawa.
--
Pozdrawiam,
Szymon Wilkołazki
To co opisujesz to EDI, i
To co opisujesz to EDI, i nie ma on wiele wspólnego z podpisem elektronicznym.
"wzór opisu wzoru pisma"
Zostawmy specjalistom problem czy element "PodstawaPrawna" jest zamknięty czy nie. Zostawmy pytania dlaczego element ten jest inaczej zdefiniowany niż inne elementy w przykładzie...
Zostawmy dyskusję dlaczego dla jednych elementów mamy określenia wymagalności i powtarzalności a dla innych nie, np.: "MetadaneWzoru" minOccurs="1"
"DaneWzoru" minOccurs="1"
"ds:Signature" minOccurs="0" maxOccurs="unbounded"
co rozumiem jako:
- element "MetadaneWzoru" musi wystąpić co najmniej raz
- element "DaneWzoru" musi wystąpić co najmniej raz
- element "ds:Signature" może nie wystąpić wcale lub wystąpić dowolną ilość razy,
Apropo: Czy dobrze to rozumiem?
Czyli to w konsekwencji znaczy że jeśli "DaneWzoru" wystąpią dwa razy to będzie w porządku czy nie?
Zostawmy specjalistom dyskusję dlaczego elementy takie jak:
xsd:element name="JRWA" type="xsd:string"
xsd:element name="PodstawaPrawna" type="xsd:string"
nie mają w ogóle określonej wymagalności ani powtarzalności.
Czy to jednak znaczy, że można nie podać podstawy prawnej? Czy to znaczy że można tak jak w przykładzie wpisać "pusty" element "PodstawaPrawna" i czy konsekwentnie można też wpisać też spację pomiędzy znaczniki elementu "JRWA"
Czy to też będzie w porządku?
Zmierzam po prostu do konkluzji: cóż mi z tego, że XML opisujący wzór będzie poprawny technicznie jeśli będzie zawierał dane nieprzydatne, niemożliwe merytorycznie do zinterpretowania.
I kolejna konkluzja: pamiętajmy, że ogłoszony wzór to nie jest wzór pisma, tylko wzór opisu wzoru pisma. Inaczej mówiąc MSWiA potrzebuje otrzymać uporządkowaną informację o składanych do CRD wzorach i guzik go obchodzi co tam w środku w nich będzie. To nie jest ten problem.
Warto jednak zauważyć że "wzór opisu wzoru" zawiera własne oznaczenia elementów i własną strukturę określone w XSD. Zastanówmy się jak się ma taki wzór do niezbędnych elementów struktury dokumentów elektronicznych? Dlaczego o tym piszę? I co ma piernik do wiatraka? Otóż przykład o którym tu dyskutujemy znakomicie pokazuje gimnastykę jaką trzeba będzie przeprowadzić jeśli nie będzie wspólnego mianownika dla niezbędnych metadanych czyli "wzorcowych tagów" dla niezbędnych elementów struktury dokumentów elektronicznych.
(zob. na tym forum Niepokoi mnie wyróżnik)
Spróbujmy przełożyć elementy zawarte we "wzorze opisu wzoru pisma" na niezbędne elementy struktury dokumentu elektronicznego określone w rozporządzeniu MSWiA wydanym na podstawie art.5 ust.2a ustawy archiwalnej. A więc dla każdego wzoru (który jest chyba dokumentem elektronicznym?) to będzie:
Twórca = Wnioskodawca
Data = OkresWaznosci
Tytuł = OpisUzycia
Identyfikator = URIWzoru, URIXSD ,URIXSL (czyli każdy wzór ma trzy)
Dostęp = brak odpowiadającego znacznika
Typ = brak znacznika
Format = brak znacznika
Opis = Oswiadczenie
Grupowanie = JRWA
Czy teraz widać, że określenie tagów dla niezbędnych elementów struktury dokumentów elektronicznych jest już baaaaardzo pilne? A nie tylko ich wylistowanie tak jak to jest dotąd. Bo za chwilę będziemy mieli duży kłopot z interoperacyjnością. Jeśli każdy urząd przyśle własne struktury bez stosowania się do wspólnego mianownika (który ciągle nie jest znany!) to będziemy mieli kilkanaście tysięcy pęknie opisanych wzorów. I niech się one różnią od siebie. Nie ma sprawy.
Ale niech mają one pewne elementy wspólne. Bo inaczej większość będzie takich, których interoperacyjność ograniczy się tylko do systemu informatycznego "Wnioskodawcy" określonego we opisie tego wzoru. Bo jeśli urząd Miasta Głogów w swoim "Wniosku o dokonanie wpisu w rejestrze przedsiębiorców" nazwie tego przedsiębiorcę który taki wniosek skład "wnioskodawca", urząd Miasta Częstochowa "przedsiebiorca", UM Białystok "SkladajacyWniosek", jeszcze kto inny "TworcaWniosku"... itd. to jak będziemy potem (po 20 latach) takie takich dokumentów szukać? Zwłaszcza, że i "data" może się inaczej nazywać...
Poczekajmy, aż się pojawią w CRD jakieś wzory (XML+XSD+XSL) i zobaczymy w jaki sposób będzie można poszukiwać Twórców dokumentów elektronicznych stworzonych na ich podstawie (przeszukując jednocześnie dokumenty stworzone na podstawie różnych wzorów). No chyba że z góry zakładamy, że ma to być maksymalnie trudne albo nawet niemożliwe.
--
kazimierz schmidt