Es muss nicht immer XML sein

In Beispielen für Datenübertragungen findet sich häufig eine Serialisierung der Daten in eine XML Applikation. Dieser Eintrag soll zeigen, dass XML nicht immer die erste Wahl sein muss. Es soll das Bewusstsein erweitern nicht immer das Erstbeste zu verwenden, was einem in den Sinn kommt.

Für das Sportics Realtime Telemetry API wurde bewusst auf XML verzichtet. Der Grund: Realtime Telemetry Clients arbeiten auf reduzierter Hardware wie z.B. Mobiltelefonen und haben eine instabile Funkanbindung des Netzwerkes (z.B. Sportics J2ME Applikation). In solchen Umgebungen ist XML nicht die erste Wahl. Die Daten werden nicht kompakt genug repräsentiert.

Ein Realtime Telemetry Datensatz besteht aus einer Menge von Messwerten zu einem bestimmten Zeitpunkt. Ein Messwert hat immer auch eine beschreibende Kennung. Mehrere solcher Datensätze werden zu einem Snap zusammengeführt. Ein Realtime Telemetry Client schickt einen solchen Snap z.B. alle 2 Minuten an den Realtime Telemetry Server.

In XML kann ein solcher Datensatz wie folgt dargestellt werden:

  <data>
      <measurements>
          <measurement type='longitude'>12.5675256</measurement>
          <measurement type='time'>123456789</measurement>
          <measurement type='heartrate'>78</measurement>
      </measurements>
      <measurements>
          <measurement type='longitude'>12.5675456</measurement>
          <measurement type='time'>123457813</measurement>
          <measurement type='heartrate'>79</measurement>
      </measurements>
      ...
  </data>

Es fällt auf, dass ein solches Format sehr viel redundanten Overhead produziert. Dieser kann durch kürzere Namen reduziert werden. Dabei geht allerdings die sprachliche Wiedererkennung verloren.

  <data>
      <ms>
          <m t='lon'>12.5675256</m>
          <m t='tme'>123456789</m>
          <m t='hrt'>78</m>
      </ms>
      <ms>
          <m t='lon'>12.5675456</m>
          <m t='tme'>123457813</m>
          <m t='hrt'>79</m>
      </ms>
      ...
  </data>

Kompakter, aber auch schwieriger zu lesen. Es ist im Übrigen ein Irrglaube, dass das JSON Format kompakter ist. In der obigen Notation ist es grösser.

Eine weitere Möglichkeit der Reduktion ist auf allgemeine Namen für XML Elemente zu verzichten. An deren Stelle wird der Wert des t-Attributes verwendet:

  <data>
      <ms>
          <lon>12.5675256</lon>
          <tme>123456789</tme>
          <hrt>78</hrt>
      </ms>
      ...
  </data>

Ein ungewöhnliche Schreibweise, aber durchaus machbar. Bei diesem Aufbau wird ein entsprechendes JSON Dokument im Übrigen kleiner als sein XML Pendant. Hierzu folgt weiter unten eine Grafik aus realen Messwerten.

Es geht noch kompakter. Bei Sportics haben wir uns bei dem Realtime Telemetry API gegen SOAP Webservices entscheiden. Der Grund ist einfach: nicht alle Zielgeräte verfügen über SOAP Webservices Support. SOAP Webservices von Hand nachzuprogrammieren ist keine Kleinigkeit. Stattdessen haben wir uns für ein REST API entschieden. Dies vereinfachte die Kommunikationsschnittstelle und auch den Aufwand für die Implementierung auf Clientseite. Zwar wird auch in der REST Literatur viel mit JSON und XML gearbeitet, aber dies muss nicht sein.

Bei den Messwerten setzen wir statt dessen auf das CSV-Format nach RFC 4180. Im CSV-Format wird der oben beschriebene Datensatz wie folgt notiert:

    tme,lon,hrt
    123456789,12.5675256,78
    123457813,12.5675456,79

Noch kompakter ist kaum möglich. Das API schreibt noch einige Dinge vor, beispielsweise muss ein Header vorhanden sein und jede Zeile nach der Headerzeile muss so viele Spalten haben wie die Headerzeile. Ansonsten verwirft der Server die Daten und liefert eine Fehlermeldung.

Die abschliessende Frage lautet: Um wieviel kleiner ist die CSV-Notation?

Aus den realen Daten von einigen tausend Datensätzen lässt sich folgendes Bild genenüber der CSV Notation ermitteln:

  • die XML Notation ist um ca. den Faktor 2 grösser
  • die JSON Notation ist um den Faktor 1,5 grösser

In absoluten Zahlen:

CSV XML JSON
2.791.662 5.831.791 4.361.462

Ein Bild beschreibt mehr als 500 Worte:

2 Antworten zu “Es muss nicht immer XML sein”

  1. Faktor 1,5 oder gar zwei in nicht komprimierter Form finde ich schon beachtlich. Besonders relevant wird das auch wenn es um die Kosten für’s mobile Internet geht und wenn es darum geht, in kürzeren Zeitabständen Leistungsdaten zu übermitteln. Gerade letzteres ist bei Wettkämpfen interessant.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Log Out / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Log Out / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Log Out / Ändern )

Verbinde mit %s

Follow

Bekomme jeden neuen Artikel in deinen Posteingang.