e-PUAP - propozycja formatu dokumentu elektronicznego

Na forum projektu e-PUAP została opublikowana pierwsza wersja dokumentu pod tytułem: Analiza i studium przypadku dla ustalenia rekomendacji dla pierwotnych wzorów dokumentów elektronicznych przekazywanych przez system e-PUAP oraz Urzędowego Potwierdzenia Odbioru Dokument ten stanowi w praktyce propozycję formatu formularzy elektronicznych.

Poniżej znajdują się moje uwagi zebrane po pobieżnym zapoznaniu się z nim, opublikowane także na forum e-PUAP.

Uwagi

1. Dlaczego blok adresów nie może być częścią bloku nagłówka? Traci się w ten sposób zgodność z Archiwami Państwowymi - moim zdaniem niepotrzebnie. Poza tym inne standardy rynkowe (choć w zupełnie innych zastosowaniach) traktują adresata i nadawcę jako część nagłówka - choćby poczta e-mail. Dlatego ciekawi mnie, dlaczego zostało to wyodrębnione.

2. Inne elementy (s. 10). Moim zdaniem te "inne" elementy też powinny być częścią nagłówka. Chodzi o to, by je jasno sprecyzować już na etapie ogólnego projektu. Lepiej, by wszystkie dokumenty zawierały ujednolicone _meta_dane wymagane np. przez Archiwa, niż żeby została tutaj dowolność (=bałagan). Podobnie sytuacja wygląda z listą autorów dokumentu - można zrobić w nagłówku element wielokrotny "Twórca". Oczywiście zawsze można wybrane części nagłówka ustawić jako opcjonalne.

Jeśli jednak istnieje konieczność dodania takich "innych" elementów, moim zdaniem należy zdefiniować je jako "coś, o czym teraz nie pomyśleliśmy, ale kiedyś sobie przypomnimy". I to moim zdaniem jest potrzebne.

3. Czy TrescWniosku nie powoduje zbędnej redundancji danych z danymi zawartymi w Adresach? Jakie powinny być kryteria umieszczenia adresu w TrescWniosku, a jakie w Adresach? Czy w sytuacji, gdy TrescWniosku zawiera te same adresy, co Adresy, należy je podawać w obu częściach, czy tylko w jednej? Dlaczego nie można ograniczyć się do umieszczania adresów w jednym miejscu?

4. Jaka jest polityka budowania części TrescWniosku? Czy można przyjąć, że ma to być dowolna zawartość?

5. E-paczka powinna być dokumentem w formacie .zip ze względu na jego łatwe otwieranie w najpopularniejszych systemach operacyjnych. Stosowanie innego formatu spowoduje praktyczny brak możliwości korzystania z dokumentu przez typowych użytkowników.

6. Moim zdaniem tworzenie dodatkowego pliku naglowek._xml_ jest niepotrzebne. Wszystkie niezbędne informacje o wykorzystaniu plików powinny być zamieszczone w dokumencie elektronicznym, jako referencje podpisane.

7. Nie rozumiem koncepcji podpisywania pliku nagłówkowego. Jeśli miałby on być podpisany, musiałby zawierać skróty (np. sha1) z poszczególnych dokumentów wchodzących w skład e-paczki - a w przykładach takich skrótów brakuje.

8. Czy UPO nie powinno być dokumentem elektronicznych, tzn. zawierać elementów wymaganych w dokumentach elektronicznych?

Sugestie

Proponowałbym rozważenie następującej ogólnej struktury dokumentów:

Dokument>
ndap:dokument>...ndap:dokument>
TrescWniosku>...TrescWniosku>

Zalaczniki>...Zalaczniki>
</Dokument>

ndap:dokument to element "dokument" z XSD stworzonego przez Archiwa (sugerowałbym zmianę nazwy na Naglowek, ale tak już jakoś zostało to w NDAPowym xsd nazwane). W specyfikacji z Archiwum można umieścić m.in. wyróżnik (jako referencję do innego dokumentu) - wstępnie wydaje mi się więc, że byłoby to wystarczajace do pełnienia roli nagłówka dokumentu (a jednocześnie spójne).

TrescWniosku - to sekcja merytoryczna, określana w zależności od konkretnego dokumentu (anyType).

Zalaczniki - ewentualne załączniki do dokumentu (zakodowane w _base_64, opcjonalnie - referencje zgodnie z _xml_dsig'owym formatem referencji) - choć tutaj rozwiązanie e-paczki wydaje się lepsze.

W przypadku UPO dokument powinien być analogiczny, tylko zamiast TrescWniosku zawierać odpowiednio zdefiniowany element np. Upo.

Konkluzja

Przedstawiona przez e-PUAP wizja dokumentu elektronicznego jest krokiem w dobrym kierunku; należałoby jednak ściślej trzymać się wcześniej zdefiniowanych formatów dokumentów. Nie chodzi nawet o istnienie formalnych wymogów, które by takiej zgodności wymagały, ale o zapewnienie ciągłości opracowywanych przez MSWiA rozwiązań i rekomendacji.

Dodaj komentarz

Markdown

  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.

Filtered HTML

  • Adresy internetowe są automatycznie zamieniane w odnośniki, które można kliknąć.
  • Dozwolone znaczniki HTML: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <small>
  • Znaki końca linii i akapitu dodawane są automatycznie.

Plain text

  • Znaczniki HTML niedozwolone.
  • Adresy internetowe są automatycznie zamieniane w odnośniki, które można kliknąć.
  • Znaki końca linii i akapitu dodawane są automatycznie.
CAPTCHA
Proszę, przepisz napis z obrazka do okienka poniżej. Sprawdzamy w ten sposób, czy nie jesteś aby robotem. Wielkość znaków ma znaczenie!
By submitting this form, you accept the Mollom privacy policy.