Anzeige aller Dateien im Verzeichnis, die nicht in der xjustiz_nachricht.xml enthalten sind
digidigital opened this issue · comments
Da die Verwaltung oftmals nur den Nachrichtenkopf und minimale (im Zweifelsfall unsinnige) Pflichtangaben übermittelt ist zu überlegen, ob im Inhaltsbaum ein eigener Eintrag mit allen nicht im XJustiz-Datensatz aufgeführten Dateien hinzugefügt werden soll.
Der Eintrag könnte z.B. "Dateien ohne Metadaten" lauten
Vorteil: Gefühl der Aktennutzung auch bei unvollständigem XJustiz-Datensatz
Nachteil: Benutzer könnten (werden?) die Darstellung mißverstehen und als Teil der übermittelten Nachricht ansehen
Das wäre klasse, insbesondere da die Verwaltung in aller Regel gar keinen oder einen "falschen" XJustiz-Datensatz "xjustiz_akte.xml" bzw "xjustiz_nachricht.xml" mitsendet. Die Strukturinformationen sind vermutlich trotzdem in der Datei "bea_message.xml" enthalten, können aber von nicht OpenXJV verarbeitet werden.
Hier ein anonymisiertes Beispiel: https://envs.sh/t49.xml
(Konnte hier leider nicht direkt hochgeladen werden, da Github keine xml-Dateien erlaubt)
Danke für dein Feedback und den Datensatz.
- Wenn ich es richtig verstehe, wird dieser durch das beA-Backend erzeugt. Somit kann er die fehlenden - nicht übermittelten - Metadaten nicht ersetzen.
- Nicht beA-Nutzern (eBo, beN, beBPo, etc.) steht der Datensatz nicht zur Verfügung
Meine größte Sorge ist es, die - zu großen Teilen papierfixierten - Anwender zu überfordern. Das Problem der nicht-integrierten Aktenübersendung (Alle Anhänge haben ein Datum und den Typ "Anlage") ist tatsächlich schwer zu vermitteln. Nicht besser wird es bei übersendeten Akten in Form von ZIP-Dateien. Teilweise kommen die Akten auch als archivierte ERV-Nachrichten inkl. Laufzettel etc.
Danke für dein Feedback und den Datensatz.
Danke für deine Arbeit!
Somit kann er die fehlenden - nicht übermittelten - Metadaten nicht ersetzen.
Das dachte ich auch erst. Aber wenn ich mich nicht irre, ist in dem Datensatz gewissermaßen eine xjustiz_akte.xml eingebettet, und zwar unter dem Element <m_nachricht_xml>. Dort sind jedenfalls alle Metadaten enthalten, die ein regulärer Metadatensatz auch enthalten würde. Die Frage wäre dann, ob es gelingen kann, diese Daten zurückzutransformieren, sodass OpenXJV diese wie einen regulären Metadatensatz auslesen könnte.
Meine größte Sorge ist es, die - zu großen Teilen papierfixierten - Anwender zu überfordern.
Eventuell könnte eine solche Funktion ja nur als ausdrückliches opt-in in den Einstellungen verwirklicht werden.
Das dürfte die ganz normale xjustiz_nachricht.xml sein, die dir auch separat vorliegen dürfte.
Manchmal liegt noch eine xjustiz_akte.xml oder akte_xjustiz_nachricht.xml etc. als Inhalt bei (die dann auch "meistens" in der xjustiz_nachricht.xml aufgeführt ist).
Die kann man problemlos über den Öffnen-Dialog laden und openXJV stellt die Akte entsprechend dar.
Da die Ämter und Behörden das gern unterschiedlich handhaben (softwarebedingt oder weil die Mitarbeiter dort nicht wissen, was sie tun), ist das in Schulungen / Anleitungen schwierig zu vermitteln.
Und wenn man den Viewer aus einer Drittanwendung durch Übergabe der XML-Datei automatisch startet, muss man die (manuelle) Abfrage, welche XML-Datei zu laden ist, vor den Aufruf setzen.
die dir auch separat vorliegen dürfte.
Leider nicht, die Behörde verschickt die Nachricht leider ohne xjustiz_nachricht.xml bzw. xjustiz_akte.xml - oder zumindest kommt die Nachricht ohne diesen Strukturdatensatz an, sondern nur mit der oben verlinkten bea_message.xml. Bei der Gewährung von Akteneinsicht durch die Gerichte enthält die jeweilige ERV-Nachricht immer zwei xml-Dateien: einmal die bea_message.xml und zum anderen die xjustiz_akte.xml. Letztere kann dann mit OpenXJV verarbeitet werden (was zuweilen aufwendig sein kann, wenn die Akte in mehreren ERV-Nachrichten versandt wird, da diese dann erst in ein gemeinsames Verzeichnis entpackt werden müssen). Die bea_message.xml allein lässt sich leider nicht mit OpenXJV verarbeiten.
Da die Ämter und Behörden das gern unterschiedlich handhaben (softwarebedingt oder weil die Mitarbeiter dort nicht wissen, was sie tun), ist das in Schulungen / Anleitungen schwierig zu vermitteln.
Ja, das ist ein großes Problem. Die Mitarbeiter verstehen in Regel nicht einmal die Problembeschreibung :(
Und wenn man den Viewer aus einer Drittanwendung durch Übergabe der XML-Datei automatisch startet, muss man die (manuelle) Abfrage, welche XML-Datei zu laden ist, vor den Aufruf setzen.
Könnte vielleicht dadurch gelöst werden, dass OpenXJV die bea_message.xml nur als letzte fallback-Option verwendet?
Ich hab mal ein wenig rumgespielt und mit xmlstarlet können xml-Dateien erzeugt werden, die mit openXJV korrekt geladen und verarbeitet werden. Offenbar ist die Akten-Strukturinformation in der bea_message.xml gekapselt unter dem Node /BeaMessage/m_nachricht_xml. Diese liegen darüber hinaus auch nur mit escape-Sequenzen vor.
Der folgende Befehl extrahiert die eingebettete Akten-Strukturinformation und wandelt die escape-Sequenzen in die entsprechenden Zeichen um:
xmlstarlet sel -t -v "/BeaMessage/m_nachricht_xml" bea_message.xml | xmlstarlet unesc > unesc.xml
Die Datei unsec.xml kann dann ganz normal mit openXJV geöffnet werden.