Databund: Typ TextFormatiert/textOffice

XBAU-185
  • K2
Geprüft
Mi., 30.11.2022 - 15:16
Fertig
So., 15.08.2021 - 17:17
Typ "TextFormatiert"
priority-icon Medium
Sonstige Änderung
Ohne eine solche Typangabe kann eine verarbeitende Anwendung die Datei sonst nicht sinnvoll an eine Fachanwendung oder an ein UI weiterleiten, ohne die Binärdatei tiefer zu analysieren und bestimmte Erkennungsheuristiken anzuwenden.

Desweiteren sollte klarer spezifiziert werden, ob die Information in den beiden Elementen text und textOffice alternativ oder ergänzend ist. Die Formulierung "den Textabschnitt zusätzlich im XML-basierten Format ODF oder OOXML abzubilden" lässt offen, dass eine Visualisierung des Elements text ausreichend ist und die zusätzliche Abbildung in textOffice vom System auch ignoriert werden kann. Vergleiche bei E-Mail-Nachrichten die Typen multipart/mixed bzw. multipart/parallel vs. multipart/alternative .
  • Infrastruktur & Technik

Elemente vom Typ "TextFormatiert" können ein optionales Element textOffice enthalten.

"Dieses Element gestattet es, den Textabschnitt zusätzlich im XML-basierten Format ODF oder OOXML abzubilden."

ODF und OOXML basieren zwar auf XML, sind aber auf Datei-Ebene rein binäre Formate. Dieses Element muss daher eine mimeType-Angabe tragen wie bei Anlagen, die aussagt, um welchen Dateityp es sich konkret handelt. Alternativ wäre dies aus der Angabe einer DateiErweiterung wie ".odt" oder ".docx" ableitbar.

Beachte, dass ODF und OOXML auch viele andere Subtypen zulassen (.xlsx, .pptx, .ods, .odp, …).

Kommentare

EG21-03 07.09.2021

Bemerkungen:  

  • Punkt 1: mime-Type soll eingeführt werden zum Element textOffice, soll differenzierter sein als im vorhandenen Dokutext zum Element
  • eine passende MimeType-Codeliste soll spezifisch für diesen Kontext definiert werden und per Typ-3-Mechanismus eingebunden werden (die vorhandene XBau-MimeType-CL im Datentyp anlagen ist ein anderes Thema)
  • Punkt 2: Textdoku sollte noch präziser benennen, dass im Element  textOffice derselbe Inhalt stehen muss, welcher lediglich anders technisch repräsentiert ist. Verwertung des Elements textOffice steht im Belieben des Empfängers.
  • Bemerkung aus Herstellersicht (Prosoz): beide Varianten (Elemente text und textOffice) werden im Fachverfahren je nach Nachrichtentyp verwendet und verarbeitet 

Bewertung:

  • Ergänzung bestehender Funktionalität
  • Meinungsbild EG: allgemein akzeptiert / es wurde angeregt zu prüfen, ob Element textOffice überhaupt benötigt wird
  • Aufwand für EG: mittel bis niedrig
  • Aufwand Umsetzung im Standard: mittel bis niedrig

Die Doku zum Element textOffice im Datentyp TextFormatiert des Kernmoduls wurde präzisiert. 

Es wurde das neue Element textOfficeMimeType erstellt (siehe Spezifikation Kernmodul, Abschnitt  III.4.2 TextFormatiert).

Der neue Typ-3-Code-Datentyp Code.TextOfficeMimeType führt zur Codeliste urn:xoev-de:xbau:codeliste:textofficemimetypes, die im XRepository veröffentlicht wird.

Die Versionshistorie wurde aktualisiert.

Status Erledigt (abgesehen von der Veröffentlichung im XRepository)


Inhalt der Codeliste sollen die Codes sein zu

  • ODF (= OASIS Open Document Format for Office Applications) und
  • OOXML (= Office Open XML, XML-based format for office documents developed bei Microsoft)

Die Werte zu ODF sind aus dem OASIS Standard hier tabellarisch zusammengefasst

Die Werte zu Microsoft OOXML sind in dieser Quelle gelistet

XLeitstelle am 28.10.2022

Die Liste der MIME-Types, die im optionalen Element "textOffice" verwendet werden wurde erstellt und im XRepository veröffentlicht.

Im Unterschied zu den Werten der oben angehänten Tabelle wurden hier lediglich die Types für Text- und Tabellendokumente von Open/Libre Office und MS Office angegeben. Die Types von Präsentations- und anderen Dokumenten sind in diesem Kontext nicht relevant. Ergänzend sind noch die MIME Types der gängigsten Bildformate angegeben, falls diese als Inline-Objekte in Texten benötigt werden.

WICHTIG!
In der Spezifikation sollte noch die Codelisten-URI um die Versionskennung ergänzt werden:

urn:xoev-de:xbau:codeliste:textofficemimetypes_1.0{}

Status -> Umsetzung

Befund "In der Spezifikation sollte noch die Codelisten-URI um die Versionskennung ergänzt werden"

Wurde nicht umgesetzt:

  • Die Codeliste sollte nach Abstimmung im Sept-EG (siehe oben "Typ-3-Mechanismus") per Typ-3 Code-Datentyp eingebunden werden (siehe Kernmodul Abschnitt III.4.3 Code.TextOfficeMimeType). Dabei wird wird die einzubindende Version (listVersionID) nicht in die Spezifikation bzw. XSD eingetragen, nur die Codelisten-URI.

Status erledigt

EG22-04 21.11.2022  

Ergebnis Diskussion

  • die Anforderungen sind durch die Lösunge abgedeckt

QS durch XLeitstelle am 24.11.2022

Die Kennung in der Spezifikation lautet:

urn:xoev-de:xbau:codeliste:textofficemimetypes

Frage: sollte hier noch die Versionsnummer _1.0 angehängt werden oder ist das egal?

Version ist "unbestimmt"

also o.k. -> Status geprüft