Open mmuzikSeyfor opened 1 year ago
Dobrý den, bohužel z historických důvodů a z důvodů zpětné kompatibility nejsou schémata zcela ideální a konzistentní, jednotlivé přílohy byly vytvářeny různými pracovními skupinami, byť se texty příloh v mnoha ohledech obsahově překrývají. Cílem posledních změn v přílohách bylo především reagovat na změny textu vyhlášky a standardu, nikoliv vyřešit tento historický daný fakt. V budoucnosti by mělo dojít ke sjednocení struktur XML a terminologie používaných v přílohách s terminologií národního standardu, vyhlášky a dalšími „mezinárodními“ standardy jako METS a SIP. Sjednocení struktur XML ale vyžaduje nemalé úpravy archivního zákona a vyhlášky, spíše však vydání nových podob obou předpisů, což představuje záležitost na několik let. Rozsáhlé změny v přílohách také budou znamenat nutnost kompletního přepracování a změn ve stávajících eSSL, Archivním portálu a validátorech SIP balíčků.
Dorbý den, z jakého důvodu nejsou v příloze 3 (struktura popisných metadat pro automatizované zpracování dokumentu) sjednoceny např. elementy pro adresy nebo el. komunikaci s přílohou 1?
V klasickém rozhraní https://www.mvcr.cz/nsesss/v4info/doc/1-api-async/ermsIFASyn.html je pro typy adres definovaná struktura tAdresa, kde je možné detailněji mapovat email, DS, doručovací adresu, apod.
V příloze 3 je pro toto jen element ElektronickyKontakt = string. Identicky pak v příloze 3 PostovniAdresa = string. Žádné další upřesnění.
Jelikož podle této přílohy máme povinnost provádět ztotožnění se jmenným rejstříkem osob, tak mi přijde, že to trochu postrádá smysl, aby spisové služby musely mít složité rozeznávání o jaký typ kontaktu vůbec jde.
Děkuji za odpověď.