DataX File/Stream Datenstruktur und Datenaustausch

Version

2014-11-01

Entwicklungsverlauf

2014-11-01 Identifikator auf universelle Eindeutigkeit erweitert

2014-10-31 Cosmos CmXtoken, CmXlink ergänzt, an neue Rechtschreibung angepasst

2005-04-16 Entwerten von Sonderzeichen auf Backslash geändert

2005-03-20 Datentyp für Wertedarstellung ergänzt

2005-03-16 Framework-Funktionalität ergänzt

2005-03-09 Zeitdatentyp ergänzt

2005-03-06 Datentypen, Kapselung, Arrays und schnelle Binärsignalkodierung ergänzt

2005-03-03 Zahlendarstellung im Binärformat ergänzt

2005-02-26 Beispiele für Metadaten und Mehrkanalempfänger ergänzt

2005-02-20 Detaillierte Festlegungen zu Zahlenformaten

2005-02-17 Hexadezimalzahlen als Format ergänzt, Punkt im Identifikator

2004-03-10 Einführung mit allgemeinem Überblick zum Zweck ergänzt

2004-01-29 Versionsverwaltung ergänzt

2004-01-22 Request/Response durch Datenflusselemente ergänzt

2004-01-21 Request/Response-Fähigkeiten ergänzt

2004-01-20 DataX Speicherorganisation ergänzt

2004-01-19 Unterstützung für Datenintegrität ergänzt

2004-01-18 Erklärung für ‘DataX-Collection’ ergänzt und Adressverwendung erweitert

2004-01-12 Erste Version basierend auf Diskussionen in der ERAC-VLBI-Gruppe

Mitarbeit

Folgende Personen haben an der Diskussion über den Inhalt dieses Dokumentes teilgenommen und viele Ideen eingebracht, welche im Dokument eingearbeitet sind:

Marko Cebokli marko.cebokli@mors.si

Jim Sky radiosky@radiosky.com http://www.radiosky.com

Disclaimer

//////////////////////////////////////////////////////////////////////////////

//

// DataX.pdf: Dokumentation der DataX File/Stream-Datenstruktur

//

//////////////////////////////////////////////////////////////////////////////

//

// Autor: Eckhard Kantz

// eMail: software@wegalink.eu

// Diskussion: http://groups.yahoo.com/group/erac-vlbi

// Motivation: European Radio Astronomy Club (ERAC),

// Projekt ALLBIN (http://erac-web.com/workshop/allbin.htm)

//

////////////////////////////////////////////////////////////////////////////////

Dies ist FREIE Software

Hiermit wird eine gebührenfreie Erlaubnis für alle Personen erteilt, welche eine Kopie dieser Software einschließlich zugehöriger Dokumentation (der „Software“) erhalten, mit der Software ohne Einschränkungen zu verfahren, einschließlich des Rechts zur Nutzung, zum Kopieren, Modifizieren, Zusammenführen, Veröffentlichen, Vertreiben, weiter Lizenzieren, und/oder dem Verkauf von Kopien der Software,

und Personen, welche die Software hierdurch erhalten zu gestatten, dies ebenso

zu tun, unter Vorbehalt der folgenden Bedingungen:

Für die Nutzung der Software werden keinerlei Bedingungen auferlegt.

DIE SOFTWARE WIRD GELIEFERT „WIE SIE IST“, OHNE IRGENDEINE GARANTIE, EXPLIZIT

ODER IMPLIZIT, EINSCHLIESSLICH JEDOCH NICHT BEGRENZT AUF DIE NICHTGEWÄHRLEISTUNG

EINER EIGNUNG ZUM VERKAUF ODER EINER EIGNUNG UND VERTRÄGLICHKEIT FÜR EINEN BESTIMMTEN ZWECK. IN KEINEM FALL DARF DER AUTOR ODER EINER DER COPYRIGHT-INHABER VERANTWORTLICH GEMACHT WERDEN FÜR ANSPRÜCHE BELIEBIGER ART, FÜR BESCHÄDIGUNGEN ODER ANDERE SCHULDZUWEISUNGEN, EGAL OB SIE DURCH EINEN VERTRAG ODER SCHADENS-ERSATZANSPRUCH ENTSTEHEN, WELCHE IM ZUSAMMENHANG MIT DER SOFTWARE, DEREN NUTZUNG ODER ANDERER KOMMERZIELLER HANDLUNGEN MIT DER SOFTWARE STEHEN.

This is FREE software

Permission is hereby granted, free of charge, to any person obtaining a copy

of this software and associated documentation files (the "Software"), to deal

in the Software without restriction, including without limitation the rights

to use, copy, modify, merge, publish, distribute, sublicense, and/or sell

copies of the Software, and to permit persons to whom the Software

is furnished to do so, subject to the following conditions:

There are no conditions imposed on the use of this software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER

LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,

OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

SOFTWARE.

Inhaltsverzeichnis

DataX File/Stream Datenstruktur und Datenaustausch 1

Version 1

Entwicklungsverlauf 1

Mitarbeit 1

Disclaimer 2

Zielstellung 5

Einführung 5

Fallstudien 6

A – Datenreihe 6

B – Datensatz mit Zeitstempel 6

C – Strukturierte Information 6

Bildung von strukturierten Informationen 7

Abbildung strukturierter Informationen in einem File/Stream 8

Entwurfsziele 8

File/Stream-Struktur 8

Zeilen innerhalb eines Files/Streams 8

Informationselemente innerhalb einer Zeile 8

Duplizierte Informationselemente in aufeinanderfolgenden Zeilen 9

9

Vergrößerung einer Informationsmenge durch eine Folgezeile 9

Verwalten eines aktuellen Pfades 10

Verwalten einer übergeordneten (Parent-)Informationsmenge 10

Parallele Schreiboperationen 10

Excel-Import 11

Vergleich von DataX-Strukturen mit Verzeichnissen, Registraturen und Datenbanken 12

Verzeichnisse in Dateisystemen 12

Registraturen 12

Datenbanken 13

Datentypen 14

Sonderzeichen 14

Textdatentyp 14

Datentyp für Zahlendarstellung 15

Binärer Datentyp (BinX) 15

Zahlendarstellung im Binärformat (NumX) 16

Repräsentieren von Datentypen im Binärformat (TypeX) 17

Identifikatoren für Datentypen 17

Typsteuerfelder (ControlX) 18

DataXopen-Datentyp 18

DataXwrap-Datentyp 18

BinMCL-Datentyp 18

BinXbinary-Datentyp 19

BinXstring-Datentyp 20

BinXvalue-Datentyp 20

BinXtime-Datentyp 20

CmXtoken-Datentyp 21

CmXlink-Datentyp 21

Der Identifikator-Datentyp 21

Adressdatentyp 22

Adressdarstellung 22

Umgang mit Änderungen 23

Framework- Funktionalität 25

Optionale Werte 25

Kommentare 25

Standardvorgaben 25

Mehrfachspezifikationen 25

Interpretation 26

Datenintegrität 26

Prüfsummenberechnung 26

Wiederherstellung defekter Daten 28

DataX -Archiv 29

Versionsverfolgung 31

Mehrere Versionen im Archiv 31

Anfrage/Antwort-Verfahren 33

Speichern von Anfrage/Antwort-Streams 33

Anfragestruktur 35

Allgemeine Anfrageelemente 35

Anforderung von Identifikatoren 36

Zeiteinschränkungen 36

Appendix A 37

A.1 Beispiel für das Speichern von mehrstufigen Metadaten vor einem Interferometrie-Datenblock 37

A.2 Beispiel für einen Mehrkanalempfänger mit wahlfreier Kanalselektion 37

A.3 Beispiel für einen Mehrkanalempfänger mit regelmäßiger Kanalselektion 37

38

Zielstellung

Die DataX File/Stream-Datenstruktur wurde mit dem Ziel entworfen, die Sammlung und den Austausch großer Datenmengen zu unterstützen sowie den Zugriff auf einzelne Bestandteile bis hinunter zu den kleinsten Detailinformationen zu ermöglichen.

Ein spezieller Bedarf für den Umgang mit großen Datenvolumen besteht im Bereich Radioastronomie, insbesondere wenn die Datenströme von verteilten Antennenstandorten zusammengeführt werden sollen, um alle Anlagen zu einem integrierten Antennenkomplex zu verbinden, so wie dies für das Generieren von Himmelsansichten mit Interferometer-Netzwerken der Fall ist.

Obwohl diese Spezifikation auf die besonderen Anforderungen von Interferometer-Netzwerken ausgelegt ist, so ist sie darüber hinaus auch für andere Zusammenschaltungen von Computern anwendbar, um diese in integrierter Weise zusammenarbeiten zu lassen.

Einführung

In der gegenwärtigen Computermethodologie ist das Schichtenmodell weit verbreitet, um Computersysteme miteinander zu verbinden. Schichtenmodell bedeutet das Umhüllen von zu transportierenden Informationspaketen mit Zusatzinformationen, zum Beispiel wo die Information herkommt, wo sie hingeht, welchen Kategorien sie angehört und anderen. Das so entstehende Datenpaket ist möglicherweise in ein übergeordnetes Datenpaket eingebettet, welches den gleichen Zweck verfolgt, lediglich auf einer höheren Ebene. Das entstehende Datenpaket kann wiederum von einem nächsten Datenpaket umhüllt sein, und so weiter.

In der Regel werden notwendige Steuerinformationen im Vorspann (Header) eines Datenpaketes abgelegt, während die zu transportierende Information im Hauptteil des Datenpaketes (body) eingefügt wird. Weiterhin können in einem Nachsatz (Trailer) weitere Informationen enthalten sein, welche zum Beispiel zur Sicherstellung der Datenintegrität von Bedeutung sind. Die Struktur des endgültigen Datenpaketes, welches effektiv über den Verbindungskanal übertragen wird, kann somit sehr komplex werden und der Overhead kann dementsprechend groß sein:

Vorspann1 Vorspann2 ... Vorspann N (effektive Information) Nachsatz N ... Nachsatz2 Nachsatz1

Ein Vorteil des Schichtenmodells ist offensichtlich, dass die einzelnen Schichten unabhängig voneinander sind und dass sie separat implementiert werden können. Weiterhin können geeignete Kombinationen von Transportschichten benutzt werden, um Informationen zwischen beliebigen heterogenen Systemen auszutauschen.

Andererseits erhöht jede Transportschicht den Umfang der zu übertragenden Information und die Forderung nach unabhängigen Schichten macht es nahezu unmöglich, Transportoptimierungen über mehrere Schichten hinweg durchzuführen. In einem extremen Fall ergab die Analyse eines Datenstromes, welcher Tabellen-artige Daten mit mehreren tausend Einträgen transportierte, dass der resultierende Overhead bei Anwendung des SOAP-Protokolls 95% betrug und nur 5% Nutzdaten im Vergleich zur binären Repräsentation der gleichen Daten übertragen wurden.

Es sei erwähnt, dass sich das SOAP-Protokoll sehr gut für die Übertragung beliebig strukturierter Daten eignet, was bei anderen Protokollen oft nicht der Fall ist. Unter existierenden Protokollen musste daher in der Regel für einen konkreten Einsatzfall nach einem Kompromiss zwischen Effektivität der Übertragung und Möglichkeiten strukturierter Datenrepräsentation gesucht werden.

Die DataX-Spezifikation verfolgt das Ziel, das Beste aus beiden Welten miteinander zu verbinden, also zum einen bei der Speicherung und Übertragung hoch effektiv zu sein und andererseits beliebig strukturierte Daten abbilden zu können. Hinzu kommen weitere Eigenschaften im Zusammenhang mit der Notwendigkeit des Umgangs mit beliebig großen Datenvolumen.

Ein weiteres Ziel besteht in der Unabhängigkeit von jeglichen Transportschichten, welche den Informationsfluss zwischen Computern steuern. Für einen erfolgreichen Datenaustausch sollte es genügen, eine Verbindung auf der Basis von IP-Services zu haben, welche das Spezifizieren des Empfängers der Information ermöglichen. Alternativ ist es möglich, auch jede andere Kopplung, wie zum Beispiel serielle Verbindungen für einen DataX-basierten Informationsaustausch zu verwenden. Die Implementierung dieser Zielstellung wird eine breite Anwendung in heterogenen Umgebungen ermöglichen und gleichzeitig stellt dies eine gute Basis für sorgfältige und tiefgehende Transportoptimierungen dar.

Spezielle Aufmerksamkeit muss der Gesamtsignallaufzeit gewidmet werden die entsteht, wenn ein System ein Datenpaket an ein zweites System sendet und wenn dieses eine Antwort an das erste System zurücksendet. Je mehr Signalläufe für das reguläre Übertragen von kurzen Informationen erforderlich sind, desto mehr Bedeutung kommt dieser Frage zu. Im Falle von extremen Signallaufzeiten, wie sie zum Beispiel bei der Kommunikation von Weltraumsonden mit Bodenstationen auftreten, steht maximal ein kompletter Signallauf für das Übertragen von Informationen zur Verfügung. Alle Datenprotokolle, welche mehrere Signalläufe benötigen, sind in diesem Fall nutzlos und scheiden für die Anwendung aus.

Fallstudien

A – Datenreihe

Eine der einfachsten Datenstrukturen wird durch eine einzelne Messwertspalte dargestellt:

2602

2595

2594

..

Der wesentliche Nachteil einer einzelnen Messwertspalte ist das Fehlen jeglicher Informationen über Herkunft und Bedeutung der Daten sowie die fehlende Maßeinheit für die Zahlen.

B – Datensatz mit Zeitstempel

Ein Vorspann (Header) sowie Zeitstempel liefern bereits mehr Informationen über die Messwerte:

Zeit Flux Temperatur

[Sekunden seit 1.1.1970] [Jy] [°C]

1073217600.370 2602 -2.4

1073217600.390 2595 -2.4

1073217600.410 2594 -2.3

Mit Header-Informationen und Zeitstempeln wird die Bedeutung der Messwerte bereits deutlicher. Jedoch fehlen auch in diesem Fall Informationen über die beobachtete Radioquelle sowie Informationen zur verwendeten Messausrüstung.

C – Strukturierte Information

Eine Informationsdarstellung in strukturierter Weise klärt alle Eigenschaften der Messwertdaten bis hin zu den kleinsten Details:

EKD@JO64qc.RSpectro,1073217600:DataX,2004-01-12

,Antenne,Parabolspiegel 90cm

,Azimut:Grad,0

,Elevation:Grad,15

,Frequenz:GHz,10.600

,Bandbreite:kHz,250

,Daten

Zeit,Flux,Temperatur

[Sekunden seit 1.1.1970],[Jy],[°C],@

1073217600.370,2602,-2.4

1073217600.390,2595,-2.4

1073217600.410,2594,-2.3

Der obenstehende strukturierte Informationsblock erweitert die vorherige Messwertdarstellung mit Zeitstempeln um beschreibende Zusatzinformationen (Metainformationen), welche zum Beispiel Auskunft über den Entstehungszeitpunkt des Datensatzes sowie die benutzte Spezifikation geben. Weiterhin werden der Operator, der Messort sowie die verwendete Messausrüstung mittels eines Schlüssels (EKD@JO64qc.RSpectro) angegeben und ebenso werden die Beobachtungsdetails wie Antenne, Azimut, Elevation, Frequenz und Bandbreite spezifiziert.

Bildung von strukturierten Informationen

Ein gebräuchlicher Weg für das Erzeugen von Strukturen bei einzelnen Informationen ist das Bilden von geordneten Informationsmengen, wodurch jeder einzelnen Information im Prinzip eine Reihenfolgenummer zugewiesen wird:

[0:1073217600, 1:Antenne, 2:Azimut, 3:Elevation, 4:Frequenz, 5:Bandbreite, 6:Daten]

Anschließend können alle Einzelinformationen sowohl durch ihre Reihenfolgenummer als auch durch den von ihnen repräsentierten Wert referenziert werden, zum Beispiel Nummer “1:” ist gleichbedeutend mit “Antenne.

Grundsätzlich gibt es für die soeben beschriebenen Informationsmengen zwei Möglichkeiten zu deren Erweiterung, zum einen in der Größe und zum anderen in der Tiefe. Eine Erweiterung der Größe bedeutet, dass der Informationsmenge weitere Elemente hinzugefügt werden. Eine Erweiterung der Strukturtiefe hingegen bedeutet, dass neue Informationsmengen gebildet und diese einem Element der bestehenden Menge zugeordnet werden.

Beispiel: [0: 1073217600, .. 4:Frequenz, ..]
|
|_____ [0:GHz, 1:10.600]

Die Erweiterung von Größe und Tiefe geordneter Informationsmengen führt zu hierarchischen Datenstrukturen. Das Adressieren eines Elementes innerhalb der hierarchischen Datenstruktur erfordert das Aufzählen aller übergeordneten Bestandteile dieser Struktur, welche somit den Pfad von einem obersten Element bis zum adressierten Element darstellen. Dabei können die übergeordneten Elemente sowohl mittels ihrer Werte als auch mit ihren Ordnungsnummern, welche ihnen in den jeweiligen geordneten Datenmengen zugeteilt wurden, referenziert werden.

Untenstehend ist ein Vergleich aufgelistet, welcher den Pfad aller Elemente der zuvor aufgeführten Beispieldatenstruktur einmal als Folge von Ordnungsnummern auf der linken Seite und zum anderen die Werte aller Elemente auf der rechten Seite zeigt:

0 EKD@JO64qc.RSpectro

0-0 1073217600

0-0-0 DataX

0-0-1 2004-01-12

0-1 Antenne

0-1-0 Parabolspiegel 90cm

0-2 Azimut

0-2-0 Grad

0-2-1 0

0-3 Elevation

0-3-0 Grad

0-3-1 15

0-4 Frequenz

0-4-0 GHz

0-4-1 10.600

0-5 Bandbreite

0-5-0 KHz

0-5-1 250

0-6 Daten

0-6-0 Zeit

0-6-0-0 [Sekunden seit 1.1.1970]

0-6-0-0-0 1073217600.370

0-6-0-0-1 1073217600.390

0-6-0-0-2 1073217600.410

0-6-1 Flux

0-6-1-0 [Jy]

0-6-1-0-0 2602

0-6-1-0-1 2595

0-6-1-0-2 2594

0-6-2 Temperatur

0-6-2-0 [°C]

0-6-2-0-0 -2.4

0-6-2-0-1 -2.4

0-6-2-0-2 -2.3

Abbildung strukturierter Informationen in einem File/Stream

Entwurfsziele

Unter verschiedenen Möglichkeiten zur Abbildung von strukturierten Informationen in einem File/Stream hat eine solche Lösung den Vorrang, welche bei vorgegebener Informationsmenge das geringste Datenvolumen für das File/ den Stream ergibt. Daher werden explizite Strukturelemente wie zum Beispiel Tags in XML-Dateien durch implizite Regeln ersetzt werden, welche in der überwiegenden Mehrzahl der Fälle ohne explizite Strukturelemente auskommen. In den verbleibenden Fällen wird die Strukturinformation in der zuvor dargestellten kurzen Form als Folge von Reihenfolgenummern hinzugefügt.

Zusätzlich zu den bereits aufgeführten Anforderungen besteht ein weiteres Entwurfsziel darin, dass die resultierenden DataX-Files/Streams lesbar dargestellt und einzelne Informationselemente mittels Texteditor angepasst werden können.

File/Stream-Struktur

Ein File/Stream wird aus 8-Bit-Werten (Bytes) erzeugt, welche den Wertevorrat von 0 bis 255 darstellen. Einige ASCII-Zeichen, wie zum Beispiel 13 (CR-Wagenrücklauf) und 10 (LF-Zeilenschaltung) werden zum Strukturieren der Dokumente verwendet, während die Mehrzahl der Zeichen für die Darstellung von Informationen verwendet wird.

Zeilen innerhalb eines Files/Streams

Die oberste Strukturebene einer File/Stream-Struktur (Zeile) wird durch eine Zeilenschaltung (CR+LF) erzeugt. Innerhalb einer Zeile sorgen spezielle Trennnzeichen für die Einteilung in einzelne Informationselemente.

Informationselemente innerhalb einer Zeile

Für die Einteilung einer Zeile in Informationselemente finden vier verschiedene Trennzeichen Verwendung:

44 (Komma) - Erweiterung von Pfad oder Informationsmenge, nächstes
Informationselement ist Text oder numerisch

59 (Semikolon) - Erweiterung von Pfad oder Informationsmenge, nächstes
Informationselement ist binär oder speziell

58 (Doppelpunkt) - Neubeginn einer Informationsmenge, nächstes
Informationselement ist Text oder numerisch

61 (Gleichheitszeichen) - Neubeginn einer Informationsmenge, nächstes
Informationselement ist binär oder speziell

Beispiel:

Frequenz:GHz,10.600

entspricht folgender Struktur:

0 Frequenz

0-0 GHz

0-1 10.600

Duplizierte Informationselemente in aufeinanderfolgenden Zeilen

Sobald ein Informationselement an gleicher Stelle in einer nachfolgenden Zeile auftritt so wird dieses einfach weggelassen:

Beispiel:

EKD@JO64qc.RSpectro,1073217600:DataX,2004-01-12

EKD@JO64qc.RSpectro,Antenne,Parabolspiegel,90cm

Ist gleichbedeutend mit:

EKD@JO64qc.RSpectro,1073217600:DataX,2004-01-12

,Antenne,Parabolspiegel 90cm

und entspricht in beiden Fällen der folgenden Datenstruktur:

0 EKD@JO64qc.RSpectro

0-0 1073217600

0-0-0 DataX

0-0-1 2004-01-12

0-1 Antenne

0-1-0 Parabolspiegel 90cm

Vergrößerung einer Informationsmenge durch eine Folgezeile

Das erste unterschiedliche Pfadelement in einer Folgezeile erweitert die Informationsmenge auf der entsprechenden Ebene:

Beispiel:

EKD@JO64qc.RSpectro,1073217600:DataX,2004-01-12

,Antenne,Parabolspiegel 90cm

Die erste Zeile gibt folgenden Pfad vor:

0 EKD@JO64qc.RSpectro

0-0 1073217600

0-0-0 DataX

0-0-1 2004-01-12

während die zweite Zeile die Informationsmenge mit dem Element “1073217600” um ein neues Element “Antenne” erweitert:

0-1 Antenne

0-1-0 Parabolspiegel 90cm

Verwalten eines aktuellen Pfades

Wenn eine Zeile einen Pfad spezifiziert so wird dieser zum aktuellen Pfad. Falls nachfolgende Zeilen mit Text oder einem binären oder numerischen Element beginnen dann bleibt der vorherige Pfad erhalten und kommt als aktueller Pfad zur Anwendung.

Beispiel:

EKD@JO64qc.RSpectro,Daten:Zeit,Flux,Temperatur

Ist gleichbedeutend mit:

EKD@JO64qc.RSpectro,Daten

Zeit,Flux,Temperatur

Und entspricht in beiden Fällen der folgenden Datenstruktur:

0 EKD@JO64qc.RSpectro

0-0 Daten

0-0-0 Zeit

0-0-1 Flux

0-0-2 Temperatur

Das “EKD@JO64qc.RSpectro”-Element wird als Pfadursprung (Root) erkannt da es ein ‚@’-Zeichen enthält, so wie es bei „Datentypen“ definiert wird.

Verwalten einer übergeordneten (Parent-)Informationsmenge

Jede auf einem Pfad neu erzeugte Informationsmenge wird zur übergeordneten (Parent-) Informationsmenge für nachfolgende parallele Schreiboperationen.

Beispiel:

EKD@JO64qc.RSpectro,Daten

Zeit,Flux,Temperatur

Die neu erzeugte Informationsmenge [Zeit,Flux,Temperatur] wird zur übergeordneten Informationsmenge.

Parallele Schreiboperationen

Sehr oft bestehen Datensammlungen aus mehreren Spalten. Das parallele Schreiben unterstützt das Hinzufügen eines weiteren Datensatzes in solch einer Datensammlung mittels einer Zeile. Die Elemente dieser Zeile erweitern die entsprechenden Informationsmengen, welche den Elementen der übergeordneten (Parent-)Informationsmenge als untergeordnete (Child-)Informationsmengen zugeordnet sind.

In der Regel erfolgen mehrere parallele Schreiboperationen ohne Wechsel der übergeordneten (Parent-) Informationsmenge. Falls die Elemente einer parallelen Schreiboperation zur neuen übergeordneten (Parent-) Informationsmenge werden sollen, dann wird der Zeile, welche die neuen Elemente enthält, ein einzelnes ‚@’-Zeichen als letztes Element der Zeile nachgestellt.

Beispiel:

EKD@JO64qc.RSpectro,Daten

Zeit,Flux,Temperatur

[Sekunden seit 1.1.1970],[Jy],[°C],@


Die Elemente der dritten Zeile werden den Informationsmengen zugeordnet, welche mit den Elementen der zweiten Zeile verknüpft sind während sie gleichzeitig die Rolle der übergeordneten (Parent-) Informationsmenge neu übernehmen. Sie repräsentieren eine virtuelle Informationsmenge welche ausschließlich dem Zweck dient, eine übergeordnete (Parent-) Informationsmenge für nachfolgende parallele Schreiboperationen zu sein, welche andererseits jedoch keine reale Repräsentation in den strukturierten Daten hat. Die Datenstruktur sieht daher folgendermaßen aus:

0 EKD@JO64qc.RSpectro

0-0 Daten

0-0-0 Zeit

0-0-0-0 [Sekunden seit 1.1.1970]

0-0-1 Flux

0-0-1-0 [Jy]

0-0-2 Temperatur

0-0-2-0 [°C]

Das Hinzufügen von Datensätzen zum vorherigen Beispiel füllt die Tabelle mit Daten:

Beispiel:

EKD@JO64qc.RSpectro,Daten

Zeit,Flux,Temperatur

[Sekunden seit 1.1.1970],[Jy],[°C],@

1073217600.370,2602,-2.4

1073217600.390,2595,-2.4

1073217600.410,2594,-2.3

Insgesamt führt dies zur folgenden Datenstruktur:

0 EKD@JO64qc.RSpectro

0-0 Daten

0-0-0 Zeit

0-0-0-0 [Sekunden seit 1.1.1970]

0-0-0-0-0 1073217600.370

0-0-0-0-1 1073217600.390

0-0-0-0-2 1073217600.410

0-0-1 Flux

0-0-1-0 [Jy]

0-0-1-0-0 2602

0-0-1-0-1 2595

0-0-1-0-2 2594

0-0-2 Temperatur

0-0-2-0 [°C]

0-0-2-0-0 -2.4

0-0-2-0-1 -2.4

0-0-2-0-2 -2.3

Excel-Import

Die strukturierten Daten aus dem vorherigen Beispiel können in MS Excel importiert werden und führen zur nachfolgenden Ansicht. Somit kann festgestellt werden, dass das Entwurfsziel zur Anzeige von strukturierten Daten eines Files/Streams in lesbarer Form erfüllt wurde. Weiterhin sind alle Daten somit auch einer direkten Weiterverarbeitung zugänglich gemacht worden:

EKD@JO64qc.RSpectro

Daten

Zeit

Flux

Temperatur

[Sekunden seit 1.1.1970]

[Jy]

[°C]

@

1073217600.370

2602

-2.4

1073217600.390

2595

-2.4

1073217600.410

2594

-2.3

Vergleich von DataX-Strukturen mit Verzeichnissen, Registraturen und Datenbanken

Nach der Einführung von Informationsmengen kann die Frage auftauchen, welchen Unterschied es zwischen DataX-Informationsmengen und den damit zusammenhängenden hierarchischen Strukturen einerseits und den gut bekannten Informationsstrukturen wie Verzeichnissen in Dateisystemen, Registraturen und Datenbanken andererseits gibt. Eine kurze Antwort wäre, dass mit der DataX-Spezifikation künstliche Beschränkungen beseitigt werden, welche den anderen genannten Datenstrukturen vorwiegend aus Performance-Gründen und zum Zweck eines effektiven Ressourcen-Management auferlegt wurden.

Die DataX-Spezifikation ist ebenfalls auf Performance und effektives Ressourcen-Management ausgerichtet. Jedoch wird mit höchster Priorität eine konzeptionelle Grenzenlosigkeit angestrebt. Beschränkungen werden erst dann sichtbar, wenn eine DataX-Datei in ein Dateisystem geschrieben wird oder wenn ein DataX-Stream zwischen Computern übertragen wird. Die in solchen praktischen Anwendungen auftretenden Beschränkungen resultieren aus der endlichen Größe des zur Verfügung stehenden Speicherplatzes beziehungsweise aus der begrenzten Bandbreite des Übertragungskanals zwischen Computern, der den DataX-Stream überträgt.

Im folgenden werden einige Fallbeispiele betrachtet, wie die DataX-Spezifikation Schranken überwindet:

Verzeichnisse in Dateisystemen

Gewöhnlich werden von jedem Dateisystem Beschränkungen bezüglich der Größe von Pfadkomponenten sowie bezüglich der Zeichen gemacht, welche in Pfadkomponenten vorkommen dürfen. Zusätzlich unterliegt oftmals die Gesamtlänge eines Pfades einer Beschränkung durch das Dateisystem oder durch das Betriebssystem, welches das Dateisystem anwendet. Eine übliche Beschränkung für die Gesamtlänge eines Pfades ist zum Beispiel 1024 Byte, wobei solche Zeichen wie Slash ‚/’ oder Backslash ‚\’ nicht innerhalb von Pfadkomponenten vorkommen dürfen.

Die genannten Beschränkungen werden in der DataX-Spezifikation überwunden. Die Komponenten eines Pfades wie auch die Gesamtlänge eines Pfades sind konzeptionell unbeschränkt. Weiterhin sind gleich zwei Datentypen verfügbar (Text und Binär), welche das Erzeugen von Pfadkomponenten aus beliebigen 1-Byte-Zeichen 0..255 sowie auch aus beliebigen Bit-Feldern als Bestandteil eines Pfades ermöglichen.

Registraturen

Grundsätzlich gibt es keine großen konzeptionellen Unterschiede zwischen einem Eintrag in einer Registratur (z.B. Windows Registry) und einer Datei in einem Dateisystem außer zusätzlicher Beschränkungen bezüglich der Größe von Einträgen in einer Registratur. Eine gemeinsame Beschränkung beider Strukturen besteht darin, dass auf einem gegebenen Pfad jeder Datei beziehungsweise jedem Namen einer Registratur immer nur ein Inhalt zugewiesen werden kann. Sobald mehrere Werte zugewiesen werden sollen muss die Struktur immer erst um eine neue Ebene ergänzt werden.

In einer Registratur würde die zusätzliche Ebene aus mehreren Einträgen bestehen, wobei jeder Eintrag einen eigenen eindeutigen Namen aufweisen muss. Anschließend können die Werte den Namen zugeordnet werden. Eine äquivalente Vorgehensweise in einem Dateisystem wäre das Anlegen von Dateien mit unterschiedlichen Dateierweiterungen (Extensions), zum Beispiel .exe für ausführbare Dateien und .ini für die Initialisierungsinformation während die Dateinamen vor der Extension gleich wären. Dies wäre jedoch nur eine Umgehungslösung für die genannte Beschränkung.

Die DataX-Spezifikation überwindet die Einschränkung, dass einem Namen in einer Registratur oder einem Dateinamen nur ein einziger Wert zugewiesen werden kann durch den Ansatz, dass jedem Pfad eine konzeptionell unbegrenzte Menge von Informationselementen zugewiesen werden kann. Das ermöglicht zum Beispiel das Verwalten aller Messwertdaten unter dem Namen der Datenquelle, welche diese Werte generiert hat. Der Vorteil gegenüber dem Abspeichern aller Messwertdaten in einer Datei besteht darin, dass jeder einzelne Messwert ein eigenständiges Informationselement unter dem Dach einer gemeinsamen Spezifikation darstellt und dass somit keine zusätzlichen Regeln für das Schreiben/Lesen solcher Werte in/aus Dateien erforderlich sind.

Man kann die DataX-Spezifikation somit als Vereinheitlichung der traditionellen Konzepte von Pfad, Verzeichnis und Dateien mit den unterschiedlichsten Dateiformaten in einem gemeinsamen Konzept ansehen, wo Informationsmengen mit anderen Informationsmengen verknüpft werden mit der Absicht, unbeschränkte hierarchische Informationsstrukturen zu schaffen.

Datenbanken

Relationale Datenbanken sind in der Regel hoch-effektiv beim Verwalten von Tabellen-artigen Daten, welche durch einen Satz von Regeln zwischen den Tabellen beschrieben werden können. Dagegen sind sie für das Verwalten von hierarchisch organisierten Daten oftmals weniger gut geeignet.

Die DataX-Spezifikation erweitert das Konzept hierarchischer Datenstrukturen durch die Fähigkeit, Tabellen-artige Daten in synchronisierten geordneten Informationsmengen zu verwalten, zum Beispiel im Falle von Messwertserien mit einem Zeitstempel als Schlüssel von Messwertsätzen.

Datentypen

Die folgenden Datentypen erlauben es, die Informationselemente in der jeweils zutreffendsten Art darzustellen. Die Definition erfolgte so, dass ein Parser bei der Verarbeitung eines DataX-Streams die einzelnen Elemente eindeutig identifizieren kann:

Sonderzeichen

Die folgenden Zeichen haben eine spezielle Bedeutung innerhalb von DataX Files/Streams und müssen daher in allen Datentypen, wo Verwechselungen möglich sind vermieden werden bzw. ihre Sonderbedeutung muss mittels vorangestelltem Backslash entwertet werden.

Textdatentyp

Der Textdatentyp kann alle Einzelbyte-Zeichen von 0..255 darstellen. Für die Vermeidung von Konflikten mit den Sonderzeichen müssen diese wie zuvor beschrieben in ihrer Sonderbedeutung entwertet werden, was durch Voranstellen eines Backslash ‘\’ bewirkt wird. Beim Verarbeiten eines Textes muss das Backslash-Zeichen vor Sonderzeichen wieder entfernt werden.

Die Möglichkeit der Darstellung sämtlicher Einzelbyte-Zeichen ermöglicht es grundsätzlich, mit dem Textdatentyp beliebige Daten einschließlich Binärdaten darzustellen. Jedoch sollte man sich bewusst sein, dass Dateien mit dieser Darstellung möglicherweise nicht mit normalen Texteditoren geöffnet werden können, weil sie unter anderem auch die Steuerzeichen (0..31) enthalten können.

Weiterhin kann bei angenommener Gleichverteilung aller Zeichen im Text durch das Hinzufügen eines Backslash zu den Sonderzeichen insgesamt mit einer Effektivität der Kodierung von etwa 96% gerechnet werden. Aus diesem Grunde sollte dem Binärdatentyp der Vorrang gegeben werden, welcher eine Effektivität der Kodierung von 97% erreicht. Weiterhin werden mit dem Binärdatentyp alle Sonderzeichen (0..31) bereits vom Design her vermieden..

Beispiele:

Dies ist ein Beispiel für den Textdatentyp\: “mail\@server.com”.

Datentyp für Zahlendarstellung

Sobald ein als Text/Zahl deklariertes Feld ausschließlich die Zeichen “0123456789 - + . E e X x A a B b C c D d F f” enthält wird es weiter analysiert, ob es einer gültigen Zahlendarstellung entspricht. Falls dies der Fall ist, dann wird das Feld in eine Zahl konvertiert. Die Länge einer Zahl unterliegt keinerlei Beschränkungen.

Die folgenden Zahlendarstellungen werden akzeptiert:

Binärer Datentyp (BinX)

Das Kodieren von Binärdaten basiert auf einem Satz von Symbolen, welche die Werte von 0..215 repräsentieren. Diese Symbole (0..215) werden in DataX Files/Streams in solcher Weise den verfügbaren Zeichen (0..255) zugeordnet, dass kein Steuerzeichen (0..31) und keines der festgelegten Sonderzeichen für die Darstellung eines Symbols benötigt wird.

Die Wandlung von Symbolen in erweiterte ASCII-Zeichen geschieht in folgender Weise:

Symbol = 12 à Zeichen = 248 (vermeiden von 44 - Komma)
Symbol = 13 à Zeichen = 249 (vermeiden von 45 - Minuszeichen)
Symbol = 26 à Zeichen = 250 (vermeiden von 58 - Doppelpunkt)
Symbol = 27 à Zeichen = 251 (vermeiden von 59 - Semikolon)
Symbol = 29 à Zeichen = 252 (vermeiden von 61 - Gleichheitszeichen)
Symbol = 32 à Zeichen = 253 (vermeiden von 64 - @ Zeichen)
Symbol = 64 à Zeichen = 254 (vermeiden von 96 - Back Apostroph)
Symbol = 95 à Zeichen = 255 (vermeiden von 127 - Löschen)
alle anderen à Zeichen = Symbol + 32

In der Gegenrichtung von einem Zeichen zum Symbol geschieht die Konvertierung wie folgt:

Zeichen 32..247 à Symbol = Zeichen – 32
Zeichen 248 à Symbol = 12
Zeichen 249 à Symbol = 13
Zeichen 250 à Symbol = 26
Zeichen 251 à Symbol = 27
Zeichen 252 à Symbol = 29
Zeichen 253 à Symbol = 32
Zeichen 254 à Symbol = 64
Zeichen 255 à Symbol = 95

Vier aufeinanderfolgende Symbole aus einem Binärdatenfeld werden mit einem Radix von 216 zu einem 31-Bit-Feld kombiniert. Falls mehr als 31 Bits im Binärdatenfeld enthalten sind dann wird ein Vielfaches von 4 Zeichen für die Kodierung verwendet, bzw. es werden ein, zwei oder drei Zeichen angefügt, solange bis die Länge des Bit-Feldes erreicht ist. In dieser Weise können Binärdaten beliebiger Länge wie z.B. auch Grafiken, Sound- und Videodateien kodiert werden.

Beispiel:

Das Binärdatenfeld ‘ABCD’ wird in folgende Symbole übersetzt:

A à 65-32=33 B à 66-32=34 C à 67-32=35 D à 68-32=36

Daraus ergibt sich für den Wert des Bit-Feldes:

(((33 * 216 + 34) * 216) + 35) * 216 + 36 = 334157868

was äquivalent zum folgenden Bit-Feld ist: 0010011111010101101100000101100

Das gewählte Kodierschema repräsentiert ein 31-Bit-Feld durch vier Zeichen des erweiterten ASCII-Zeichensatzes. Dies entspricht einer 31/32-Effizienz oder etwa 97% im Vergleich zum reinen Binärformat.

Der verfügbare Wertebereich für eine Gruppe von vier Symbolen entspricht

216^4 - 1 = 2,176,782,335.

Im Vergleich zum, mit diesen Symbolen dargestellten, Maximalwert eines 31-Bit-Feldes von 2,147,483,647 existieren somit insgesamt 29,298,688 ungenutzte Kombinationen.

Offene Aufgabe:

Die Überschusskombinationen bieten eine gute Gelegenheit für erweiterte Funktionen, wie z.B. Möglichkeit für beliebige Bit-Zahlen, Kompression von zusammenhängenden Null-Bit oder Eins-Bit-Feldern sowie Kompression von sich wiederholenden komplexen Strukturen.

Zahlendarstellung im Binärformat (NumX)

Beim Umgang mit Zahlen haben sich zweckmäßige, lesbare Formen in Abhängigkeit vom Anwendungsfall herausgebildet, z.B. Integer-Zahlen für Zählvorgänge oder die Exponentialschreibweise im wissenschaftlichen Bereich mit einem Bedarf an effektiver Darstellung auch von sehr großen oder sehr kleinen Zahlen. Diesen Anforderungen soll in DataX durch eine Definition von gängigen Zahlenformaten entsprochen werden.

Das Repräsentieren von Zahlen erfordert die folgenden Elemente:

Zunächst wird der Basistyp des Binärformats (BinX) für das Kodieren beliebig großer Integer-Zahlen verwendet. Das Back-Apostroph (96) wird anschließend zur Strukturierung eines Binärdatenfeldes in mehrere Komponenten entsprechend der Topologie nach folgendem Muster verwendet:

BinX - Integer-Zahl, z.B. 123

`BinX - -BinX, negative Zahl (hier: Integer-Zahl), z.B. -123

BinX` - 1 / BinX, Bruch, z.B. 1/123

BinX1`BinX2 - BinX1 * BinX2, Produkt von Integer-Zahlen, z.B. 123*10=1230

BinX1`BinX2` - BinX1 / BinX2, Bruch von Integer-Zahlen, z.B. 123/10=12.3

BinX1`BinX2`BinX3 - BinX1 * BinX2 exp BinX3, wissenschaftlich, z.B. 123E+4

BinX1`BinX2``BinX3 - BinX1 * BinX2 exp -BinX3, wissenschaftlich, z.B. 123E-4

BinX1`BinX2`BinX3`BinX4 - BinX1 / BinX2 * BinX3 exp BinX4, wissenschaftlich, 1.3E+4

BinX1`BinX2`BinX3``BinX4 - BinX1 / BinX2 * BinX3 exp –BinX4, wissenschaftlich, 1.3E-4

Repräsentieren von Datentypen im Binärformat (TypeX)

Anforderungen

Es ist üblich, dass jede Softwareanwendung ein spezifisches Datenformat verwendet, sobald Daten persistent auf ein Speichermedium geschrieben werden bzw. wenn Daten von einer Instanz der Anwendung zu einer zweiten Instanz der Anwendung übertragen werden. Diese Datenformate werden von Entwicklern einer Software basierend auf den gestellten Anforderungen in der Regel derart festgelegt, dass die Daten in möglichst effizienter Weise übertragen und gespeichert werden können.

Oftmals treffen diese einmal erfolgten Festlegungen zu einem späteren Zeitpunkt auf Hindernisse, wenn die auf den ursprünglichen Anforderungen basierenden Formate für das Einführen neuer Eigenschaften nicht mehr ausreichen und daher die Festlegungen erweitert oder eventuell auch geändert werden müssen. Vom Benutzerstandpunkt aus geht die Software dabei während ihres Lebenszyklus durch verschiedene Versionen, wobei die Verträglichkeit der Datenformate von aufeinanderfolgenden Softwareversionen eine der größten Herausforderungen für die Entwickler darstellt. In der Vergangenheit gab es dabei oftmals keine Möglichkeit für eine Rückwärts-Kompatibilität, wodurch der einzige Ausweg im Festlegen eines neuen Datenformates bestand und wo Forderungen nach Verarbeitbarkeit älterer Formate durch geeignete Konverter gelöst wurden.

Konzept

Obwohl die DataX-Spezifikation ihrerseits als offener Container für das Speichern und Übertragen beliebiger Datenstrukturen in effizienter Weise entwickelt wurde, so kann es dennoch sinnvoll sein, vorhandene Dateien durch einen DataX-Container zu umschließen, z.B. um von der flexiblen Metadaten-Darstellung in DataX zu profitieren. Gleichzeitig können die mit aufeinanderfolgenden Versionen in Zusammenhang stehenden Probleme transparent gelöst werden, indem die entsprechenden DataX-Elemente wie eindeutige Identifikatoren und interne Referenzen in Verbindung mit dem Update-Mechanismus zum Einsatz kommen. Weiterhin kann auch die Einführung unterschiedlicher Binärformate empfehlenswert sein, wenn dadurch spezifische Anforderungen wie z.B. zur Verarbeitungsgeschwindigkeit oder zur Datenkompression besser gelöst werden, als wie dies mit der standardmäßigen DataX-Repräsenation von Binärdaten der Fall ist . Die folgenden Datenelemente gestatten es daher, andere Datenformate (extern zu DataX) zu kapseln wie auch die eingebauten Formateigenschaften in transparenter Weise zu erweitern.

Identifikatoren für Datentypen

Die ersten vier BinX-Symbole in einem binären Datenfeld dienen als Typidentifikator. Sobald ein Datentyp in einem binären Datenfeld erkannte wurde wird dieser auch auf alle untergeordneten Binärdatenfelder übertragen.

Ein Typidentifikator benutzt solche Kombinationen von DataX-Symbolen, welche nicht bereits zur Darstellung von 31-Bit-Feldern durch vier Zahlen mit einem Radix von 216 Verwendung finden. Falls stattdessen die ersten vier Symbole bereits ein gültiges 31-Bit-Datenfeld darstellen, dann handelt es sich um ein herkömmliches binäres BinX-Datenfeld ohne Typinformation.

Die folgenden TypeX-Identifikatoren sind basierend auf dem Maximalwert von

BinXmax = 216^4 – 1 = 2,176,782,335 absteigend definiert:

DataXopen = BinXmax - 0 = 2,176,782,335 - Offenes Format mit DataX-Symbolen

DataXwrap = BinXmax - 1 = 2,176,782,334 - Beliebiges Format mit BinX gekapselt

BinMCL = BinXmax - 2 = 2,176,782,333 - BinMCL-kodiertes Bitfeld-Array

BinXbinary = BinXmax - 3 = 2,176,782,332 - BinX-kodiertes Bitfeld-Array

BinXstring = BinXmax - 4 = 2,176,782,331 - BinX-kodiertes String-Array

BinXvalue = BinXmax - 5 = 2,176,782,330 - BinX-kodierter Wert

BinXtime = BinXmax - 6 = 2,176,782,329 - BinX-kodierte Zeit

CmXtoken = BinXmax - 7 = 2,176,782,328 - Token für Cosmos-Kommunikation

CmXlink = BinXmax - 8 = 2,176,782,327 - Link auf lokal erreichbares Modul

Typsteuerfelder (ControlX)

Ein TypeX-Identifikator kann von Typsteuerfeldern gefolgt sein. Die Bedeutung der Typsteuerfelder ist spezifisch und wird für jeden Typ separat beschrieben. Ein Steuerfeld ist eine unbegrenzte Zeichenfolge, welche nach BinX-Regeln kodiert ist. Die Steuerfelder sind durch Back-Apostroph (96) voneinander getrennt:

TypeX`BinX(n)`ControlX1`…`ControlXn-1`DataX(Binärdaten)

Das erste Steuerfeld enthält jeweils die Gesamtanzahl aller Steuerfelder. Daher wurde es mit BinX(n) = ControlX0 benannt.

Falls das Zeichen nach dem TypeX-Identifikator kein Back-Apostroph ist dann stellt der darauf folgende Binärdatenblock ein homogenes Bit-Feld ohne weitere Strukturinformationen dar, zumindest keine, die dem DataX-Container bekannt wären. In diesem Fall wird weiterhin eine BinX-Kodierung für die sich anschließenden Binärdaten vorausgesetzt.

DataXopen-Datentyp

Der DataXopen-Datentyp stellt eine Einladung zur Entwicklung weiterer hochspezifischer Datenformate dar, welche auf der Basis des Radix-216-Schemas und unter ausschließlicher Verwendung von zulässigen DataX-Zeichen arbeiten. Es wird empfohlen, dass eine Beschreibung des jeweiligen Datenformats im Internet erfolgt und dass eine URL zu dieser Beschreibung in ControlX1 = URL gegeben wird:

DataXopen`BinX(n)`BinX(URL)`ControlX2`…`ControlXn-1`DataX(Binärdaten)

Die Anzahl der Steuerfelder, welche auf die URL folgen ist spezifisch für das jeweilige Datenformat.

DataXwrap-Datentyp

Der DataXwrap-Datentyp dient zum Kapseln von Datenformaten, die bereits außerhalb von DataX bestehen sowie zum Kapseln kompletter DataX-Archive. Es wird empfohlen in ControlX1 = URL einen Link zu einer Website von einem Programm zu geben, welches das gekapselte Datenformat verarbeiten kann oder alternativ den Namen eines Programms, falls ein Link nicht verfügbar ist.

DataXwrap`BinX(n)`BinX(URL/Programm)`ControlX2`…`ControlXn-1`BinX(Binärdaten)

Die Anzahl der Steuerfelder ist spezifisch für das jeweilige Format. Falls nach dem DataXwrap-Datentyp keine Steuerfelder folgen (kein Back-Apostroph nach dem Typidentifikator) dann wird von einem kompletten DataX-Archiv ausgegangen..

BinMCL-Datentyp

Der dem BinMCL-Datentyp von den Eigenschaften her ähnliche BinX-Datentyp erfordert für das Berechnen der aufeinanderfolgenden BinX-Zeichen mehrere arithmetische Operationen. Abhängig vom Prozessor kann dies zu einem beträchtlichen Zeitbedarf für das Erzeugen des BinX-Datenstromes führen. Daher ist es für extreme Laufzeitanforderungen ratsam eine solche Kodierung zu verwenden, welche ausschließlich durch das Verschieben von Bits und unter Verwendung von Lookup-Tabellen auskommt, ohne dabei aufwendige arithmetische Operationen durchführen zu müssen. Dieses Format kann zum Beispiel auf Computern mit einer geringen Taktrate zur Anwendung kommen, wo dennoch ein hoher Durchsatz erzielt werden soll. Es eignet sich jedoch ebenso für schnelle Rechner, wenn extreme Anforderungen bezüglich der zu erreichenden Datenrate erfüllt werden sollen.

Eine solche Kodierung, welche die beschriebenen Anforderungen erfüllt, wurde von Marko Cebokli als ein 15/16-Format entwickelt. Es arbeitet auf der Basis von 30-Byte-Feldern oder besser 15 Feldern mit jeweils 16 Bit. Zunächst wird das höchstwertige Bit (MSB) eines jeden Datenwortes schrittweise in ein 16-Bit-Register eingeschoben. Anschließend erfolgt das Nachschlagen in einer vorausberechneten Tabelle basierend auf dem jeweiligen 16-Bit-Wert ohne das höchstwertige Bit als 15-Bit-Indexwert. Diese Tabelle wurde zuvor mit den zugeordneten DataX-Zeichen für die insgesamt 32768 15-Bit-Werte gefüllt. Im letzten Schritt wird das Register, welches alle MSB derart aufgenommen hat, dass das MSB des letzten 16-Bit-Wertes an der niederwertigsten Position (LSB) ist, ebenfalls als 15-Bit-Wert in der vorausberechneten Tabelle nachgeschlagen.

Die Implementierung eines 15/16-Algorithmus ergibt eine Effizienz der Kodierung von 93.8% im Vergleich zu den 96.9% eines 31/32-Algorithmus wie BinX. Der Vorteil eines 15/16-Algorithmus bei Implementierung mit einer Lookup-Tabelle besteht jedoch in einem Bedarf von nur 42 Prozessortakten pro Byte auf einem Pentium 4 Prozessor während ein 31/32-Algorithmus beim gleichen Prozessor 135 Takte pro Byte benötigt, wodurch der 15/16-Algorithmus auf dem genannten Prozessor dreimal so schnell als wie der 31/32-Algorithmus abläuft. Diese Relationen werden sich jedoch mit fortschreitender Prozessortechnik ändern und müssen dann neu bewertet werden, um das effektivste Verfahren für einen Anwendungsfall auszuwählen.

Das Layout von BinMCL ist ähnlich dem vom BinXbinary-Datentyp:

BinMCL`BinX(n)`BinX(Dimension_1)`…` BinX(Dimension_n-1)`BinX(Binärdaten)

Als Beispiel wird ein Array mit zwei Kanälen eines Ein-Bit-Interferometers, welches Daten von zwei gleichartigen Geräten enthält folgendermaßen aussehen:

BinMCL`BinX(4)`BinX(1)`BinX(2)`BinX(2)`BinMCL(Binärdaten)

Ein Messpunkt besteht aus insgesamt vier Bit, wobei zwei Bit das I- und Q-Signal des ersten Gerätes und zwei weitere Bit das I- und Q-Signal des zweiten Gerätes darstellen.

Es wird offensichtlich, dass in diesem Fall sogar jedes einzelne Bit seine eigene Adresse bekommen hat und unter dieser dann auch eindeutig angesprochen werden kann. Dies kann in den Fällen von Bedeutung sein, wenn Datenströme von verteilten Beobachtungsstationen an einem gemeinsamen Ort von einem Korrelator kombiniert werden sollen.

BinXbinary-Datentyp

Der BinXbinary-Datentyp entspricht dem BinX-Format soweit keine Steuerfelder vorhanden sind. Bei Vorhandensein von mehr als einem Steuerfeld stellen diese die Dimensionen eines Arrays von Bit-Feldern dar. Das erste Steuerfeld gibt die Anzahl der Dimensionen des Arrays an:

BinXbinary`BinX(n)`BinX(Dimension_1)`…` BinX(Dimension_n-1)`BinX(Binärdaten)

Als Beispiel wird ein Array mit 12-Bit-Meßwerten von einem 100-Kanal-Spektrometer folgendermaßen aussehen:

BinXbinary`BinX(3)`BinX(12)` BinX(100)`BinX(Binärdaten)

Das vorliegende Binärfeld wird als dreidimensionales Bit-Feld interpretiert, wobei die ersten beiden Dimensionen auf 12 Bit für jeden einzelnen Messwert sowie auf 100 Werte pro Messwertzeile gesetzt werden. Die Größe der dritten Dimension, welche die Anzahl der Messwertzeilen bzw. die Anzahl von Frequenzdurchläufen darstellt, folgt aus der Größe des Binärfeldes.

BinXstring-Datentyp

Der BinXstring-Datentyp gestattet das Speichern von n-dimensionalen Arrays von null-terminierten W-Bit Zeichenketten, z.B. 16-Bit Unicode-Strings.

BinXstring`BinX(n)`BinX(W)`BinX(Dimension_1)`…` BinX(Dimension_n-1)`BinX(Sequenz von Zeichenketten)

Zum Beispiel wird ein Array von Übersetzungen von einer ersten Sprache in eine zweite und eine dritte Sprache mit 8-Bit Zeichenrepräsentation folgendermaßen gespeichert werden:

BinXstring`BinX(3)`BinX(8)`BinX(3)`BinX(Term11 Term12 Term13 … TermN1 TermN2 TermN3)

Jedem Term wird ein Null-Zeichen (ASCII-Wert 0x00, Unicode-Wert 0x0000) hinzugefügt, welches das Ende einer null-terminierten Zeichenkette anzeigt. Jeder Term in einem Tripel von Zeichenketten hat dabei die gleiche Bedeutung, jedoch in unterschiedlichen Sprachen.

BinXvalue-Datentyp

Der BinXvalue-Datentyp ermöglicht die Darstellung eines Bruchteils oder eines Vielfachen einer Einheitsgröße sowie auch beliebige Verhältnisse von beiden, z.B. als Basiswert für Messwertdaten.

BinXvalue`BinX(2)`BinX(Faktor)`BinX(Wert)

BinXvalue`BinX(3)`BinX(Faktor)``BinX(Negativwert)

BinXvalue`BinX(3)`BinX(Faktor)`BinX(Teiler)`BinX(Wert)

BinXvalue`BinX(4)`BinX(Faktor)`BinX(Teiler)``BinX(Negativwert)

BinXvalue`BinX(4)`BinX(Faktor)`BinX(Teiler)`BinX(Exponent)`BinX(Wert)

BinXvalue`BinX(5)`BinX(Faktor)`BinX(Teiler)`BinX(Exponent)``BinX(Negativwert)

BinXvalue`BinX(5)`BinX(Faktor)`BinX(Teiler)``BinX(Negativexponent)`BinX(Wert)

BinXvalue`BinX(6)`BinX(Faktor)`BinX(Teiler)``BinX(Negativexponent)``BinX(Negativwert)

BinXvalue`BinX(5)`BinX(Faktor)`BinX(Teiler)`BinX(Basis)`BinX(Exponent)`BinX(Wert)

BinXvalue`BinX(6)`BinX(Faktor)`BinX(Teiler)`BinX(Basis)`BinX(Exponent)``BinX(Negativwert)

BinXvalue`BinX(6)`BinX(Faktor)`BinX(Teiler)`BinX(Basis)``BinX(Negativexponent)`BinX(Wert)

BinXvalue`BinX(7)`BinX(Faktor)`BinX(Teiler)`BinX(Basis)``BinX(Negativexponent)``BinX(Negativwert)

Ein relativer Messwert, ausgedrückt als Integer-Zahl, wird mit einem Faktor, einem Teiler, einer Basis und einem Exponenten ergänzt um den endgültigen Messwert darzustellen. Zum Beispiel wird ein relativer Messwert von 1, der einen Wert von 1E-26 darstellt wie folgt kodiert:

BinXvalue`BinX(5)`BinX(1)`BinX(1)``BinX(26)`BinX(Wert)

BinXtime-Datentyp

Der BinXtime-Datentyp erlaubt einen Bruchteil oder ein Vielfaches einer Sekunde und auch jede Kombination von beiden als Zeitbasis festzulegen.

BinXtime`BinX(2)`BinX(Faktor)`BinX(Zeit)

BinXtime`BinX(3)`BinX(Faktor)`BinX(Teiler)`BinX(Zeit)

BinXtime`BinX(4)`BinX(Faktor)`BinX(Teiler)`BinX(Exponent)`BinX(Zeit)

BinXtime`BinX(5)`BinX(Faktor)`BinX(Teiler)``BinX(Negativexponent)`BinX(Zeit)

BinXtime`BinX(5)`BinX(Faktor)`BinX(Teiler)`BinX(Basis)`BinX(Exponent)`BinX(Zeit)

BinXtime`BinX(6)`BinX(Faktor)`BinX(Teiler)`BinX(Basis)``BinX(Negativexponent)`BinX(Zeit)

Alle Zeitangaben beziehen sich auf den 1.Januar 1970. Der Zeitschritt, welcher benötigt wird um von dieser Bezugszeit zu einem beliebigen Zeitpunkt zu gelangen wird entsprechend den zuvor für die Zahlendarstellung festgelegten Regeln angegeben. Zum Beispiel wird ein Millisekunden-Zeitschritt wie folgt kodiert:

BinXtime`BinX(3)`BinX(1)`BinX(1000)`BinX(Zeit)

CmXtoken-Datentyp

Der CmXtoken-Datentyp überträgt ein Kommando für den Aufbau, den Abbau und die Verwaltung von „CmServiceConnection“ im Cosmos-Programmsystem. Es kommen keine Typsteuerfelder zur Anwendungen. Stattdessen wird der Definitionswert eines Kommandos als BinX-Wert direkt im Anschluss an den CmXtoken-Datentyp übertragen:

CmXtokenBinX(Kommando)

CmXlink-Datentyp

Mit dem CmXlink-Datentyp werden Adressen (Funktionszeiger) von lokal erreichbaren Modulen übertragen. Es kommen keine Typsteuerfelder zur Anwendung. Stattdessen wird die Adresse direkt nach dem CmXlink-Datentyp als BinX-Datenfeld übertragen:

CmXlinkBinX(Adresse)

Der Identifikator-Datentyp

Ein Identifikator wird als Zeichenkette definiert, welche ein @-Zeichen enthält. Bei der Evaluierung eines Identifikators wird dieser jedoch als BinX-Feld behandelt und nach den für diesen Datentyp festgelegten Regeln in ein Bit-Feld konvertiert.

Sobald ein Identifikator als erstes Element einer Zeile in einem DataX File/Stream erscheint so wird er zur Root (oberstes Verzeichnis) für alle nachfolgenden Informationen. Ein Identifikator stellt somit die höchste Ebene in allen Informationshierarchien dar.

Die Aufgabe eines Identifikators ist es, alle Informationen „in universeller Weise“ eindeutig zu machen. “In universeller Weise” bedeutet hierbei, dass die Existenz eines doppelten Schlüssels sehr unwahrscheinlich ist und dass dies für alle Daten zutrifft, welche auf der Erde, auf anderen Planeten unseres Sonnensystems, in anderen Sonnensystemen oder in anderen Galaxien unseres Universums ihren Entstehungsort haben.

Diese Spezifikation kann nur einen Vorschlag machen, wie das Problem eines universell eindeutigen Schlüssels gelöst werden kann. Sie ist daher als Empfehlung zu sehen, wie eindeutige Schlüssel z.B. für das erdgebundene Sammeln von radioastronomischen Daten gebildet werden können. Der folgende Merksatz soll dabei als Wegweiser für die Schlüsselgenerierung dienen:

“Eine Person A geboren in B sammelt Daten in C mit der Ausrüstung D

Die vorgeschlagene Generatorregel benutzt zum Beispiel die Anfangsbuchstaben der Komponenten A und B in Großbuchstaben. Die Komponente C enthält eine für das globale Gradnetz geltende Locator-Bezeichnung wie sie bei Funkamateuren üblich ist im Anschluss an eine universelle Kennung und erweitert durch eine lokale Ortsbezeichnung. Eine geeignete Kurzform für die eingesetzte Gerätetechnik bildet die Komponente D. Die einzelnen Elemente werden anschließend nach folgendem Schema zusammengefügt:

AB@C.D

Beispiel:

Der Identifikator

“EKD@MilAlcSunEarth_JO63rx_Dambeck.RSpectro”

besteht aus folgenden Komponenten:

Die Kombination von Galaxie, Zentralsonne, Sonnensystem und Planet zielt dabei auf eine universelle Eindeutigkeit. Falls diese Kombination fehlt, dann wird „MilAlcSunEarth“ als Wert angenommen. Für die Planeten unseres Sonnensystems werden folgende Bezeichner festgelegt:

MilAlcSunMer - Merkur

MilAlcSunVen - Venus

MilAlcSunEar - Erde

MilAlcSunMar - Mars

MilAlcSunPax - Pax (kreist derzeit in Bruchstücken im Asteroidengürtel)

MilAlcSunJup - Jupiter

MilAlcSunSat - Saturn

MilAlcSunUra - Uranus

MilAlcSunNep - Neptun

MilAlcSunPlu - Pluto

Weiterhin können auch digitale Signaturen zum Bestandteil eines Identifikators werden, z.B. als eine andere Variante der Komponenten A und B. Jedoch müssen dabei die Sonderzeichen beachtet werden. Jedes Sonderzeichen als Bestandteil eines Identifikators muss durch ein vorangestelltes Backslash-Zeichen entwertet werden. Dies trifft jedoch nicht für das @-Zeichen zu, welches als Kennzeichen für den Identifikator selbst stets alleine stehen muss.

Adressdatentyp

Die Aufgabe einer Adressangabe ist es, das Duplizieren von Informationen innerhalb eines DataX Files/Streams durch das Referenzieren von bereits vorhandenen Informationen zu vermeiden. Der Wirkungsbereich einer Adressangabe ist dabei auf den DataX File/Stream begrenzt, wo sie selber darin enthalten ist.

Theoretisch wäre es möglich auch Elemente in anderen DataX Files/Streams zu referenzieren, weil die Informationen durch die verwendeten Identifikatoren auf der obersten Ebene eindeutig gemacht wurden. Trotz dieser Möglichkeit sollte kein Gebrauch davon gemacht werden, weil man sich dann auf eine fest verdrahtete Informationsstruktur verlassen würde.

Wenn man die Historie einer bereits jahrzehntelangen Repräsentation von Informationen in Datenstrukturen betrachtet so wird deutlich, dass jede Datenstruktur nach einiger Zeit veraltet und für die sich ändernden Anforderungen angepasst, erweitert oder auch vollständig neu definiert werden muss. Daher führt eine Fortsetzung von fest verdrahteten Datendefinitionen zu relativ kurzlebigen Datenstrukturen .

Im Gegensatz dazu besteht das Ziel der DataX-Spezifikation in langlebigen Datenstrukturen, welche mit Leichtigkeit angepasst, erweitert oder sogar teilweise neu definiert werden können, ohne dabei die Verbindung zu vorher definierten Datenstrukturen abreißen zu lassen.Jedoch verlangt diese Zielstellung das Verwenden von vollständigen Pfadinformationen anstelle von internen Adressen beim Referenzieren von externen Daten.

Adressdarstellung

Eine Adresse wird durch Integer-Zahlen dargestellt, die durch ein “-“ (Minuszeichen) miteinander verbunden sind, wobei die Folge der Integer-Zahlen die Position des entsprechenden Elementes in der Informationshierarchie innerhalb eines Files/Stream angibt. Adressen repräsentieren somit Links zu anderen Elementen, zu denen sie jeweils zeigen.

Beispiel:

0-0-1-0

Eine Adresse kann zum Beispiel als erstes Element in einer Zeile verwendet werden, falls dieses auf ein übergeordnetes Element verweisen soll, welches durch keine implizite DataX-Regel erreicht werden kann.

Beispiel:

EKD@JO64qc.RSpectro,1073217600:,DataX,2004-01-12

,Antenne,Parabolspiegel 90cm

ist gleichbedeutend mit

EKD@JO64qc.RSpectro,1073217600

,Antenne,Parabolspiegel 90cm

0-0:,DataX,2004-01-12

und bezieht sich in beiden Fällen auf die folgende Struktur:

0 EKD@JO64qc.RSpectro

0-0 1073217600

0-0-0 DataX

0-0-1 2004-01-12

0-1 Antenne

0-1-0 Parabolspiegel 90cm

Umgang mit Änderungen

Adressen können von besonderem Vorteil sein, wenn vorhandene Strukturen geändert werden müssen ohne dass Programme, welche sich auf die alten Strukturen verlassen in Mitleidenschaft gezogen werden sollen, wie z.B.:

Altes Format:

Frequenz:GHz,10.600

Neues Format:

Frequenz:GHz,10.600,Start,Schritt,Ende,Standard
0-2,10.500
0-3,0.00025
0-4,12.750
0-5,0-1

Die Struktur des neuen Formates würde folgendermaßen aussehen:

0 Frequenz

0-0 GHz

0-1 10.600

0-2 Start

0-2-0 10.500

0-3 Schritt

0-3-0 0.00025

0-4 Ende

0-4-0 12.750

0-5 Standard

0-5-0 10.600

Der letzte Wert (0-5-0) wäre der gleiche Wert wie (0-1) weil ein Link darauf verweist. Dies gestattet es mit der alten Struktur kompatibel zu bleiben, welche die Frequenz auf der Position (0-1) hatte. Alle Anwendungen, welche die Frequenz auf dieser Position erwarten, werden mit der neuen Datenstruktur auch weiterhin funktionsfähig bleiben. Zusätzlich können neue Anwendungen vorteilhaft die erweiterten Daten verwenden, welche neben der Frequenz auch eine Anfangsfrequenz, einen Frequenzschritt sowie eine Endfrequenz bereitstellen.

Somit zeigt das vorherige Beispiel eine zweite Methode für das Erzielen von Kompatibilität zwischen den Datenstrukturen, wobei die Definition der neuen Datenstruktur dafür sorgt, dass die Verbindung zu existierenden Anwendungen nicht unterbrochen wird. Zusammen mit der zuvor beschriebenen Verwendung von kompletten Pfadnamen für das Referenzieren von externen Daten, wo immer dies möglich ist, ergibt dies eine praktische Lösung für das Ändern von Datenstrukturen. Diese können nun über sehr lange Zeiträume und über mehrere Generationen von Anwendungsprogrammen angepasst, erweitert oder teilweise neu definiert werden, wann immer neue Anforderungen dies notwendig machen.

Die Möglichkeit zum Anpassen, Erweitern und teilweise neu Definieren von Datenstrukturen wird in der Radioastronomie wegen der sehr langen Zeiträume wo Daten aufgezeichnet werden für extrem wichtig erachtet.. Eine Datenbank mit detaillierten Geschäftsdaten einer Firma wird nach einigen Jahrzehnten eventuell keinerlei Bedeutung mehr haben, weil es die Firma dann vielleicht schon lange nicht mehr gibt. Das Gegenteil ist bei radioastronomischen Daten der Fall. Das Vorhandensein von Jahrzehnte alten Daten von Radioquellen kann eine Schlüsselrolle spielen, wenn es um das Aufstellen von dynamischen Modellen der Radioquelle geht. Daher müssen die Daten über sehr lange Zeit in lesbarer Form erhalten bleiben. Die DataX-Spezifikation ist diesem Ziel verpflichtet.

Framework- Funktionalität

Obwohl der Zweck einer Datensammlung im Speichern von Nutzdaten besteht, so ist es dennoch nützlich, Zusatzinformationen für die Beschreibung des Inhalts der einzelnen Felder zur Verfügung zu haben. Derartige Daten werden Metadaten genannt. Weil eine DataX-Datei ihrerseits jedoch bereits viele Metadaten enthält so könnte die Beschreibung dieser Metadaten als Meta-Metadaten bezeichnet werden. Stattdessen werden solche Daten im Kontext der DataX-Spezifikation als Framework bezeichnet.

Optionale Werte

Framework-Informationen werden durch leere Datenfelder eingeleitet, wie sie zum Beispiel durch einen zweifachen Doppelpunkt im Anschluss an eine Pfaddefinition entstehen. Alle Daten, welche dem zweifachen Doppelpunkt folgen, werden zu optionalen Werten, welche in das hierarchisch darüber liegende leere Feld eingetragen werden können.

Zum Beispiel:

Radioquelle::Sonne,Krabbennebel,3C353

Die Werte “Sonne”, “Krabbennebel” und 3C353 stellen die optionalen Werte dar, welche dem Feld “Radioquelle” als Wert auf der hierarchisch darunterliegenden Ebene zugewiesen werden können

Kommentare

Ein Kommentar wird durch zwei benachbarte leere Datenfelder eingeleitet, wie zum Beispiel:

Radioquelle:::Dies ist der Name der beobachteten Radioquelle.

Schlüsselworte auf der Ebene von Kommentaren können dazu benutzt werden, um Empfehlungen für das Ausfüllen der Datenfelder zu geben, zum Beispiel:

Radioquelle:::Limit:Zeichen:80

Die Empfehlung für “Radioquelle” ist in diesem Fall, dass sie nicht mehr als 80 Zeichen lang sein sollte.

Standardvorgaben

Sobald man ein Element am Ende einer Reihe von optionalen Werten anfügt wird dieses Element zur Standardvorgabe und die gesamte Hierarchie von darüber liegenden optionalen Werten wird an der Zielposition eingetragen. Diese Standardvorgabe kann später dadurch überschrieben werden, dass ein anderer optionaler Wert aus dem Wertevorrat als reales Element in die DataX-Datei eingetragen wird, zum Beispiel:

Beobachtung::Radioquelle:Sonne

Beobachtung::Radioquelle::Sonne,Krabbennebel,3C353

Beobachtung:Radioquelle:Krabbennebel

Zunächst wird “Sonne” als Standardvorgabe für “Radioquelle” eingetragen, was später durch den Eintrag “Krabbennebel” überschrieben wird.

Mehrfachspezifikationen

Im Falle von mehreren gleichförmigen Datenstrukturen ist es sinnvoll, die Framework-Daten nur einmal einheitlich für alle Datenstrukturen anzugeben. Bei der Arbeit mit mehreren gleichartigen Empfangskanälen kann zum Beispiel die Angabe für die Kanalnummer in der Pfadangabe freigelassen werden, wodurch sich die anschließenden Festlegungen auf alle Kanäle beziehen:

Empfangskanal,::Abtastrate:Hz

Interpretation

Framework-Festlegungen werden in der Regel in einer speziellen Framework-Datei abgelegt, welche von den darauf aufbauenden Datendateien referenziert wird. Der Inhalt einer Framework-Datei ist als Hilfe zum Ausfüllen von Datenstrukturen gedacht, zum Beispiel durch das Vorgeben geeigneter Standardwerte sowie weiterer Optionen sowie auch für das Bereitstellen von Erläuterungen für das Ausfüllen der Felder. Die Framework-Daten bewirken niemals eine Beschränkung für das Ausfüllen von Datenstrukturen, jedoch werden sie Empfehlungen für sinnvolle Einschränkungen beim Ausfüllen vorgeben, wie z.B. die Anzahl der Zeichen in:

Radioquelle:::Limit:Zeichen:80

Dennoch ist es Sache des Benutzers von Framework-Daten, ob die Einschränkungen beachtet werden oder auch nicht.

Datenintegrität

Das Ziel einer Unterstützung von Datenintegrität ist es zum einen, mögliche Datenverfälschungen zu erkennen und zum anderen ein Konzept anzubieten, mit dessen Hilfe soviel als möglich der noch unversehrten Daten eines defekten Files/Streams wiedergewonnen werden können.

Die Unterstützung von Datenintegrität in einem DataX-File/Stream basiert auf einer Zeile als kleinste Einheit, für die die Datenkonsistenz geprüft werden kann. Daher kann eine Prüfsumme an das Ende einer Zeile angehängt werden, welche von allen Zeichen der Zeile vor der Prüfsumme zuzüglich einer Zeilennummer, welche zeitweilig die Stelle der Prüfsumme einnimmt, berechnet wird.

Die Prüfsumme wird als Binärfeld eingesetzt, welches durch ein vorangehendes Semikolon eingeleitet wird. Wann immer ein Binärfeld am Ende einer Zeile erscheint, so muss es die Prüfsumme der jeweiligen Zeile enthalten.

Andererseits ist es nicht obligatorisch eine Prüfsumme anzugeben, doch in diesem Fall darf das letzte Feld der Zeile kein binäres Element enthalten.

Prüfsummenberechnung

Eine Prüfsumme wird durch ein oder mehrere Symbole des Binärdatenformats gebildet. Abhängig von der Anzahl der binären Symbole im letzten Feld der Zeile wird die Prüfsumme 216 zur Potenz der Anzahl sein, z.B. 216*216 = 46656 im Falle von zwei Symbolen oder 10077696 im Falle von drei Symbolen.

Die Anzahl der Symbole sollte in Abhängigkeit von der Länge der Zeile gewählt werden. Sie kann von einer Zeile zur nächsten variieren. Für eine kurze Textzeile wird ein einzelnes Symbol in der Regel ausreichend sein. Falls jedoch mehrere Gigabyte von Daten in einem einzelnen Element untergebracht werden, z.B. von einer Audio/Video-Datei oder wenn eine große DataX-Datei als Binärdaten in einem Element gekapselt wird dann kann es empfehlenswert sein, entsprechend mehrere Symbole für die Darstellung der Prüfsumme zu verwenden. Es gibt vom Konzept her keine Begrenzung für die Anzahl der Symbole in einer Prüfsumme.

Nach Festlegung einer Symbolanzahl wird die Prüfsumme dadurch berechnet, dass der Rest beim Teilen der gesamten Zeile durch die Basis der Prüfsumme ermittelt wird. Vor Beginn dieser Rechnung wird die Zeilennummer beginnend mit 1 für die erste Zeile an Stelle der Prüfsumme eingetragen.

Beispiel: Einstellige Prüfsumme

,Data;7

Zeichen Wert Teiler Rest

, 44 44 % 216 = 44
D 68 ( 44*256+ 68) % 216 = 100
a 97 (100*256+ 97) % 216 = 209
t 116 (209*256+116) % 216 = 52
a 97 ( 52*256+ 97) % 216 = 17
; 59 ( 17*256+ 59) % 216 = 91

7 55 ( 91*256+ 55) % 216 = 23

Das Zeichen welches dem Symbol 23 entspricht ist 23 + 32 = 55 entsprechend den zuvor für die Bildung des Binärdatentyps aufgestellten Regeln. Dieser Wert entspricht dem Zeichen für ‘7‘. Daher wird die Zeile mit der Prüfsumme wie folgt aussehen (unverändert in diesem speziellen Fall):

,Data;7

Der Empfänger der Zeile wird die gleichen Rechnungen durchführen und wird dadurch in der Lage sein, die Konsistenz der Daten durch Vergleich mit der Prüfsumme am Ende der Zeile zu überprüfen. Bevor die Rechnungen durchgeführt werden muss der Empfänger die Prüfsumme durch eine Zeilennummer ersetzen, welche Empfänger-seitig zu bilden ist. Daher wird die Zeilennummer ebenso überprüft, ohne dass diese explizit übermittelt werden muss.

Wiederherstellung defekter Daten

Gelegentlich kann es vorkommen, dass ein einzelnes Byte oder eine Serie von Bytes in einem File/Stream verfälscht werden. Obwohl eine Prüfsumme das Feststellen einer Datenverfälschung ermöglicht, so kann sie dennoch keinen Beitrag zum Wiederherstellen der ursprünglichen Daten leisten. Daher wird es von den intakten Zeilen abhängen, ob Informationen wiederhergestellt werden können. Angenommen der Pfad der Information ist durch die defekte Zeile nicht verändert worden, so werden alle anderen Daten ihre Stellung in der Datenhierarchie beibehalten. Lediglich die defekte Zeile wird in diesem Fall verloren sein.

Falls jedoch in der defekten Zeile der Pfad geändert wurde und die darauffolgende Zeile sich auf den aktuellen Pfad bezieht dann werden alle nachfolgenden Informationen an eine falsche Stelle in der Informationshierarchie gesetzt werden. In diesem Fall ist der einzig mögliche Ausweg, die Datei in einem Texteditor zu öffnen und die defekte Zeile von Hand richtig zu stellen, soweit deren Inhalt bekannt ist oder aus der Struktur abgeleitet werden kann.

DataX -Archiv

Wenn ein Computer eine DataX-Datei generiert oder einen DataX-Stream von einem anderen Computer empfängt dann wird der Inhalt dieses Files/Streams in der Regel auf die Festplatte geschrieben. Der folgende Archivaufbau gestattet, es beliebige DataX-Dateien auf die Festplatte zu schreiben, ohne dass Konflikte mit bereits dort vorhandenen früheren Dateien befürchtet werden müssen.

Der Schlüssel zum Erreichen eines eindeutigen Namens für den Pfad und die Datei ist der Zeitstempel für das Erstellen der Datei. Als eine unveränderliche Regel wird der Zeitstempel des Erstellens einer Datei immer auf Position “0-1” geschrieben und folgt damit direkt dem Identifikator auf der Position “0-0” in jedem DataX-File/Stream. Dies ist eine der fest definierten Eigenschaften von einem DataX-File/Stream, wo Funktionalität mit verbunden ist und aus diesem Grund muss diese Regel für alle Zeiten erhalten bleiben.

Die Verzeichnisstruktur in einem DataX-Archiv ist wie folgt definiert:

1 – DataX
2 – Jahr
3 – Monat
4 – Tag
5 – Stunde
6 – Minute
7 – Sekunde
8 – Millisekunde
9 – …

Abhängig von der Zeitdauer, die eine DataX-Datei umfasst, wird die eigentliche Datei zum Beispiel in einem ‘Sekunden’-Ordner abgelegt oder auf einer höheren oder niedrigeren Ebene.Die Namen der Dateien werden dabei wie folgt gebildet, wobei die Werte in Klammern zu ersetzen sind:

(Jahr)-(Monat)-(Tag)_utc(Stunde)h(Minute)m(Sekunde)s.(Millisekunde)_(Identifikator).csv

Unter der Voraussetzung, dass es für einen gegebenen Identifikator zu jedem Zeitabschnitt nur eine einzige Datei geben kann, wird der gewählte Dateiname universell eindeutig sein. Die Dateiendung .csv wird als Vorzugsvariante vorgeschlagen, wodurch die Datei bequem in Excel zum Anschauen geöffnet werden kann.

Beispiel: DataX-Archiv mit Dateien einer 6-Minuten und einer Millisekunden Zeitdauer

DataX
EKD@JO64qc.RSpectro
2004
Jan
20th
utc06
06m
12m
18m
24m
2004-01-20_utc06h24m_EKD@JO64qc.RSpectro.csv
31m
47s
719ms
2004-01-20_utc06h31m47s719ms_EKD@JO64qc.RSpectro.csv

Ein weiterer Vorteil zusätzlich zur Eindeutigkeit der Dateinamen ist es, dass Informationen sehr leicht wiedergefunden und überprüft werden können. Weiterhin können Informationen in beliebigen Portionen entnommen und mittels Diskette, CD, DVD, Ftp-Datei oder einem beliebigen anderen Medium oder Übertragungskanal zu anderen Computern übermittelt werden.

Beispiel:

Das Übertragen der Beobachtungsdaten eines ganzen Tages von einer Station zu einer anderen Station erfordert lediglich das Komprimieren des Verzeichnisses vom entsprechenden Tag sowie das Übermitteln der entstehenden Datei zur Empfängerseite. Der Empfänger kann die erhaltene Datei dem eigenen DataX-Archiv direkt hinzufügen ohne Gefahr zu laufen, dass vorhandene Daten dadurch überschrieben oder beeinträchtigt werden könnten.

Versionsverfolgung

Informationen können zum Entstehungszeitpunkt falsch oder unvollständig sein oder sie können sich mit der Zeit ändern. Daher ist eine Methode erforderlich, welche das Korrigieren, Erweitern und Ändern von Informationen gestattet. Da sich der Erstellungszeitpunkt einer Information niemals ändert besteht eine zusätzliche Anforderung darin, auch unterschiedliche Versionen einer gegebenen DataX-Datei in einem Archiv zu verwalten.

Das wesentliche Mittel für das Hinzufügen von Versionen zu bereits existierenden Dateien im DataX-Archiv ist das Zuweisen eines neuen Zeitstempels auf die Nullposition in der dem aktuellen Zeitstempel untergeordneten Informationsmenge. Jede weitere Version wird das Gleiche tun und der Nullposition in der dem aktuellen Zeitstempel untergeordneten Informationsmenge einen neuen Zeitstempel zuweisen. Der Identifikator der Person, welche die Änderung vorgenommen hat wird ebenfalls der neuen Informationsmenge zugewiesen, welche bereits den Zeitstempel der Änderung auf der Nullposition eingetragen hat.

Beispiel:

EKD@JO64qc.RSpectro,1073217600

,Frequenz:GHz,10.600

,Bandbreite:kHz,250

Etwa zwei Wochen später wird die Frequenzinformation durch eine Person mit dem Identifikator kantz@wegalink.eu von 10.6 GHz auf 10.55 GHz geändert:

EKD@JO64qc.RSpectro,1073217600,1075123807

,Frequenz:GHz,10.600

,Bandbreite:kHz,250

0-0:kantz@wegalink.eu,0-2,Frequenz:GHz,10.55

Der zweite Informationsblock kann folgendermaßen interpretiert werden:

Zusammenfassend kann festgestellt werden, dass eine neue Version von einer bereits existierenden Version dadurch erstellt wird, dass der Pfad des aktuellen Zeitstempels durch einen neuen Zeitstempel erweitert wird. Weiterhin wird der Identifikator der Person, welche die Änderung vornahm der neuen Informationsmenge hinzugefügt. Ferner werden alle unveränderten Elemente wie auch die geänderten Elemente der neuen Informationsmenge hinzugefügt.

Mehrere Versionen im Archiv

Eine Änderung zu einer vorhandenen Datei kann mit dem gleichen Identifikator vorgenommen werden oder auch mit einem beliebigen anderen Identifikator. Dies bedeutet, dass jeder Benutzer jede Information von jedem anderen Identifikator (Benutzer) freizügig ändern kann, ohne dass dies zu Konflikten führen würde.

Das Speichern der geänderten Information wird wie üblich unter Verwendung eines Zeitstempels und des Identifikators der ändernden Person durchgeführt. Zusätzlich wird jedoch ein Verweis bei der Datei eingefügt, welche die ursprüngliche Information enthält. Zur Vermeidung von Konflikten werden die Änderungsverweise in einem Unterverzeichnis mit dem Namen der ursprünglichen Datei aber ohne die Endung, wie z.B. .csv abgelegt.

Die Entscheidung zur Verwendung der ursprünglichen Information oder einer der geänderten Versionen liegt beim Anwender. Ein Anwender, der an der aktuellen Information interessiert ist, muss zunächst nach einem Verzeichnis mit dem gleichen Namen aber ohne die Endung, wie z.B. .csv schauen. Falls es so einen Ordner gibt, dann müssen die Verweise in diesem Ordner nach dem aktuellsten Verweis durchsucht werden.

Beispiel:

DataX
EKD@JO64qc.RSpectro
2004
Jan
12th
utc06
18m
2004-01-12_utc06h18m_EKD@JO64qc.RSpectro.csv

2004-01-12_utc06h18m_EKD@JO64qc.RSpectro

Verweis auf: DataX/2004/Jan/26th/utc13/31m/47s/
2004-01-26_utc13h31m47s_kantz@wegalink.eu.csv
26th
utc13
31m
47s
2004-01-26_utc13h31m47s_kantz@wegalink.eu.csv

Das Beispiel stellt eine Datei dar, welche ursprünglich am 12.Januar 2004 von einem Benutzer und dessen Ausrüstung mit dem Identifikator EKD@JO64qc.RSpectro erstellt wurde. Am 26. Januar wurde sie von einem Benutzer mit dem Identifikator kantz@wegalink.com geändert. An der Stelle, wo sich die Originaldatei befindet, wurde daraufhin ein Verweis auf die geänderte Information in einem Unterverzeichnis eingefügt.

Für das Feststellen, ob es sich bei einer Datei um die Originaldatei oder um eine geänderte Version handelt wird der Zeitstempel an der Position 0-0 untersucht. Falls es eine untergeordnete Informationsmenge gibt und diese einen Zeitstempel an der Position 0 eingetragen hat, dann handelt es sich um geänderte Informationen. Andernfalls ist es die Originalinformation.

Anfrage/Antwort-Verfahren

Zunächst soll der Vorgang des Sendens einer Anfrage und das nachfolgende Empfangen einer Antwort beschrieben werden, für den anschließend ein Verfahren definiert wird:

Speichern von Anfrage/Antwort-Streams

Das Verfahren zum Senden von Anfragen und Erhalten von Antworten wurde als hochfrequenter Prozess definiert. In der Regel kann es mehrere Anfragen/Antworten pro Sekunde in Abhängigkeit von der Bandbreite zwischen zwei Computern geben. Daher muss das Speichern von Anfrage/Antwort-Streams mit kleinem Zeitschritt von zum Beispiel einer Millisekunde erfolgen.

Weiterhin ist festgelegt worden, dass mehrere Antworten von der gleichen Originaldatei empfangen werden können, zum Beispiel wenn zunächst eine Untermenge der Information dieser Datei und anschließend die gesamte Datei angefragt wird. Alle diese Kopien werden den gleichen Identifikator und den gleichen Zeitstempel haben, da sie alle von der gleichen Datei abgeleitet wurden. Daher müssen auch mehrere Kopien von einer Datei unabhängig voneinander verwaltet werden können, um das Überschreiben von einer Kopie durch eine andere Kopie auszuschließen.

Diese Anforderung wird dadurch umgesetzt, dass alle Antwortdateien im gleichen Verzeichnis wie die Anfragedatei gespeichert werden. Diese Datei wird einen eindeutigen Speicherort haben, da der Zeitschritt für diese Dateien aufbauend auf dieser Annahme gewählt wurde. Sobald eine Antwort erhalten und abgespeichert wurde wird als nächstes ein Verweis an der Stelle im Dateisystem eingefügt, wo sich die Originaldatei befinden sollte und dieser Verweis zeigt auf die zuletzt erhaltene Kopie der Originaldatei bzw. einer Untermenge davon.

Das beschriebene Verfahren wird solange ohne Probleme funktionieren, wie jede nachfolgende Antwort mehr Daten als die vorherige von der Originaldatei enthält. Andererseits würden einige Daten an der Position der Originaldatei verlorengehen. In den Kopien der Originaldatei würden die Informationen jedoch erhalten bleiben. Diese spezielle Situation kann von der vorliegenden Spezifikation nicht bewältigt werden und eine geeignete Behandlung liegt daher in Verantwortung der Anfrage-stellenden Seite. Eine Möglichkeit ist es, die Anfragen nach immer größer werdenden Datenmengen zu stellen oder andernfalls kann die Anfrage-stellende Seite auch ein Mischen der erhaltenen Antworten in Erwägung ziehen.

Ein DataX-Archiv mit einigen Anfrage/Antwort-Daten könnte folgendermaßen aussehen:

DataX
EKD@JO64qc.RSpectro
2004
Jan
20th
utc06
00m
Verweis auf: DataX/2004/Jan/20th/utc17/31m/47s/719ms/
2004-01-20_utc06h00m_EKD@JO64qc.RSpectro.csv
10m
Verweis auf: DataX/2004/Jan/20th/utc17/31m/47s/719ms/
2004-01-20_utc06h10m_EKD@JO64qc.RSpectro.csv
utc17
31m
47s
719ms
2004-01-20_utc17h31m47s719ms_EKD@JN58ve.Lyra.csv
2004-01-20_utc06h00m_EKD@JO64qc.RSpectro.csv
2004-01-20_utc06h10m_EKD@JO64qc.RSpectro.csv

Im obigen Beispiel wurde eine Anfragedatei vom Identifikator EKD@JN58ve.Lyra gesendet, um Messdaten vom Identifikator EKD@JO64qc.RSpectro zu erhalten. Die Antwort bestand aus zwei Dateien aus der Informationshierarchie des Identifikators EKD@JO64qc.RSpectro und diese beiden Antwortdateien wurden im gleichen Verzeichnis wie die Anfragedatei gespeichert. Anschließend wurden Verweise in das Dateisystem an der Stelle eingefügt, wo die Originaldateien aufgrund ihres Zeitstempels erwartet werden.

Somit gestattet das Anfrage/Antwortverfahren die Übernahme von DataX-Archiven oder deren Ausschnitte von anderen Computern in gleicher Weise, als wenn sie mittels eines Speichermediums übertragen worden wären. Dabei läuft jegliche Kommunikation zwischen den Computern ebenfalls mit DataX-Dateien ab und kann daher leicht nachverfolgt werden.

Anfragestruktur

Das Anfragen von Informationen von anderen Computern besteht aus allgemeinen Elementen, welche eine Anfrage identifizieren sowie dem Spezifizieren der jeweils nachgefragten Information. Die Detailinformationen einer Anfrage müssen zwischen den beiden Seiten abgestimmt sein, während die allgemeinen Anfrageelemente immer gleich bleiben.

Allgemeine Anfrageelemente

Das Anfrageelement (QUERY=96, Back-Apostroph), das in der DataX-Spezifikation festgelegt wurde, stellt das allgemeine Anfrageelement dar, sobald es in der Position 0 in einer beliebigen Informationsmenge auftaucht. In diesem Fall ist die anfragende Seite an der Übermittlung der vollständigen Informationsmenge interessiert, welche sich im DataX-Archiv der antwortenden Seite an der entsprechenden Stelle befindet, einschließlich aller hierarchisch untergeordneten Informationsmengen. Der Identifikator der Anfrage-stellenden Seite wird dabei in der Position 0 in der dem Anfrageelement untergeordneten Informationsmenge übertragen.

Beispiel:

EKD@JO64qc.RSpectro,`,EKD@JN58ve.Lyra

Der Anfragesteller mit dem Identifikator EKD@JN58ve.Lyra möchte alle Informationen erhalten, welche sich unterhalb des Identifikators EKD@JO64qc.RSpectro befinden. Da es sich hierbei um eine riesige Datenmenge handeln könnte wären einige Einschränkungen zur Zeitperiode angebracht, um die Größe der erwarteten Antwort einzuschränken. Jedoch gehört dies bereits zu den speziellen Elementen, welche beide Seiten miteinander vereinbaren müssen.

Ein allgemeines Element für das Begrenzen einer Anfrage ist das Hinzufügen von ausgewählten Elementen innerhalb der Informationsmenge, welche das Anfrageelement auf der ersten Position enthält. Dies begrenzt die Anfrage auf die Untermenge an Daten, welche sich unterhalb der angegebenen Elemente in der Informationshierarchie befindet.

Beispiel:

EKD@JO64qc.RSpectro:`,Frequenz,Bandbreite

0-0,EKD@JN58xf.Lyra

Im obigen Beispiel werden nur die Frequenz und die Bandbreite angefragt. Dies würde die große Menge an Messdaten ausschließen, welche zum Beispiel unterhalb des Daten-Elementes angeordnet sind. Es würden jedoch alle Dateien zurückgesendet, wo sich die Elemente Frequenz und Bandbreite auf der zweiten Ebene, genau unterhalb vom Identifikator befinden. Dies könnte ebenfalls noch eine große Datenmenge sein, so dass auch in diesem Fall noch eine Einschränkung bezüglich des Zeitabschnittes sinnvoll wäre.

Ein gerade in Übertragung befindlicher Antwort-Stream kann jederzeit durch die anfragende Seite gestoppt werden. Das allgemeine Element zum Stoppen einer Datenübertragung ist ein Anfrageelement (QUERY) an Stelle des anfragenden Identifikators. Dieser wird eine Ebene tiefer auf der Position 0 der dem zweiten Anfrageoperator untergeordneten Informationsmenge gesetzt.

Beispiel:

EKD@JO64qc.RSpectro,`,`,EKD@JN58xf.Lyra

Das obige Beispiel stoppt den Datenstrom, der von der antwortenden Seite mit dem Identifikator EKD@JO64qc.RSpectro an die anfragende Seite mit dem Identifikator EKD@JN58ve.Lyra gesendet wird.

Anforderung von Identifikatoren

Ein einzelnes Back-Apostroph gefolgt vom Identifikator der anfragenden Stelle fordert eine Liste aller Identifikatoren an. Die Antwort besteht in diesem Fall aus einer Liste von Identifikatoren zusammen mit dem am weitesten zurückliegenden Zeitstempel für jeden Identifikator.

Beispiel:

`,EKD@JN58ve.Lyra

Die Antwort auf diese Anfrage könnte wie folgt aussehen:

EKD@JO64qc.RSpectro,1073212000

Die Antwort informiert die anfragende Seite über die Verfügbarkeit von Daten zum Identifikator EKD@JO64qc.RSpectro beginnend ab dem Zeitpunkt, welcher durch den Zeitstempel 1073212000 in Sekunden nach dem 1.Januar 1970 in UTC angegeben ist.

Zeiteinschränkungen

Eine Zeiteinschränkung gehört zu den zusätzlichen Elementen des Anfrage/Antwort-Verfahrens, welche zwischen den beiden miteinander kommunizierenden Seiten vereinbart werden muss. Eine Struktur dafür könnte wie folgt aussehen:

EKD@JO64qc.RSpectro,`,EKD@JN58ve.Lyra

0-0:Start:UTC,1073217400

:Ende:,1073217800

:Intervall:Sekunden,20

Im obigen Beispiel wird ein 400 Sekunden langer Zeitabschnitt angefordert und die Messwerte werden in einem Zeitintervall von 20 Sekunden erwartet. Solche Daten eignen sich zum Beispiel für eine Voransicht.

Appendix A

A.1 Beispiel für das Speichern von mehrstufigen Metadaten vor einem Interferometrie-Datenblock

MCL@JN76ec.SIDI,1108598400:DataX,2005-03-03

,global metadata tag1:item1,item2,...

,global metadata tag2:item1,item2,...

,global metadata tagN:item1,item2,...

,metadata for channel1,metadata tag1: item1, item2,...

,,metadata tag2:item1, item2,...

,,metadata tagN: item1, item2,...

,metadata for channel2,metadata tag1: item1,item2,...

,,metadata tag2: item1,item2,...

,,metadata tagN: item1, item2,...

,metadata for channelN,metadata tag1: item1, item2,...

,,metadata tag2: item1,item2,...

,,metadata tagN: item1, item2,...

,correlation values for baseline 1

:Time,Correlation

:1108598400.123,0.9876

:1108598400.124,0.9875

:1108598400.125,0.9877

...

,correlation values for baseline 2

:Time,Correlation

:1108598400.123,0.9836

:1108598400.124,0.9835

:1108598400.125,0.9837

...

,correlation values for baseline 3

:Time,Correlation

:1108598400.123,0.3476

:1108598400.124,0.3475

:1108598400.125,0.3477

...

A.2 Beispiel für einen Mehrkanalempfänger mit wahlfreier Kanalselektion

Frequenzkanäle werden wahlfrei und in unregelmäßigen Zeitintervallen abgefragt. In diesem Fall muss die volle Frequenz- und Zeitinformation mit jedem der Messwerte abgespeichert werden. Dies könnte folgendermaßen für eine erste Basislinie und in ähnlicher Weise für andere Basislinien aufgebaut werden:

EKD@JN58ve.RSpectro,1108598400:DataX,2005-03-03

,Daten,Basislinie1:[m],12.35

:Zeit,Frequenz,Signalstärke

:[Sekunden seit 1970-01-01],[GHz],[0..4095],@

:1109462400.111,10.610,2745

:1109462400.239,10.670,2745

:1109462400.377,10.655,2745

A.3 Beispiel für einen Mehrkanalempfänger mit regelmäßiger Kanalselektion

Eine vordefinierte Frequenzliste wird in regelmäßigen Zeitabständen abgetastet. In diesem Fall ist es ausreichend, die Liste aller Frequenzen nur einmal anzugeben und jeweils die Startzeit für einen ganzen Block von Abtastwerten hinzuzufügen. Dies kann folgendermaßen erfolgen:

EKD@JN58ve.RSpectro,1108598400:DataX,2005-03-03

,Daten,Basislinie1:[m],12.35

:Zeit,Freq1,Freq2,Freq3,Freq4,Freq5

:[Sekunden seit 1970-01-01],[GHz],[GHz],[GHz],[GHz],[GHz]

:gleiche Zeitintervalle,10.630,10.635,10.640,10.645,10.650,@

:1109462400.100,2736,2850,2473,2945,2791

:1109462500.100,2335,2457,2272,2628,2437

:1109462400.100,2533,2593,2311,2593,2692