[wilhelmtux-discussion] offene standards

Manfred.Morgner at gmx.net Manfred.Morgner at gmx.net
Mit Jan 15 18:19:42 CET 2003


Hallo Dietrich,

ja, das stimmt. ASCII-Zeichen sind in der Tat auch nur Binärcode. Insofern
ist meine Forderung im Grundegenommen ins sich widersprüchlich. Allerdings
wollte ich mich nicht wieder wortgewaltig aus dem Fenster werfen - gleich am
Anfang des neuen Jahres.

Dieses Problem und die anderen von Dir genannten Probleme sind extrem
schwierig und jeder Ansatz, es konsequent zu lösen mündet letztlich in Utopien. Es
geht ja sogar so weit, dass sich die Sprachen verändern und dadurch die
Informationen zunehmend unverständlicher werden. Die Amtssprache entfernt sich
zunehmend von der realen Sprache (naja - eigentlich ist es vermutlich
unterschiedlich).

Das Verwenden von Hilfsmitteln wie "&umla;" für "ä" ist solange kein
Problem, wie man das Wort (in dem es verwendet wird) als solches deuten und so auf
die Bedeutung der Krücke schliessen kann.

Praktisch habe ich inzwischen die Erfahrung gemacht, dass Archivmigrationen
an noch viel trivialeren Probleme ausufern und utopische Kosten verursachen
(wie etwas utopisches).

Ich denke, es ist ein mehrschichtiges Konzept. Die Beständigkeit des Inhalts
ist eine Ebene (extrem langfristig zu denken), die Beständigkeit von
Zeichensätzen ist eine andere Ebene (hier kann man inGerätegenerationen denken, also
2..5 Jahre), die Beständigkeit der Software (liegt hier zwischen 0 und etwa
20 Jahren).

Die Widergabe von Chinesischen, Japanischen und anderen Texten/Informationen
muss nicht unbedingt in dieser Form erfolgen, kann aber. Es gibt für all
diese Sprachen möglichkeiten der Darstellung in ASCII-Form, etwas so wie ein "ä"
in HTML, die derzeit tatsächlich auch verwendet werden.

Meine Erfahrung besagt, dass man Formate schrittweise entwickeln und Daten
bei der Systemmigration gleich anpassen kann (also z.B von ASCII auf BSCII
konvertieren). Auf diese Weise kann man in endlicher Zeit brauchbare Ergebnisse
erzielen. Die Entwicklung eines "Superformats" hingegen erzeugt massive
Widerstände weil hier Techniker, Kaufleute, Anwender u.a. Personenkreise mit
widersprüchlichen Interessen aufeinander prallen, die innerhalb ihrer Kaste
wiederum in Feinschaft operieren.

Ein wirklich gutes Beispiele dafür ist die Entwicklungen von CORBA und
aktuell auch SOAP. Beide Projekte wurden/werden mit einem universellen Anspruch
entwickelt und während CORBA bereits gestorben ist, wird uns SOAP sicher in
Kürze in ein totales InformationsChaos stürzen und tausenden Entwickler Arbeit
verschaffen, mit der Beseitigung von SOAP-Schnittstellen und der
GBrauchbarmachung von XML-Dokumenten.

Faktisch ist es im 2003 so, dass eine Information in folgender Form:

----------
ANFANG
An: Manfred Morgner, 9500 Wil, SG, ...
Von: Henry Halber, 8000 Zürich, ZH, ...
Am: 15.Februar 2003
Betrifft: Dateiformate
Woerter: 12730
Zeichen: 51856
Inhalt: Sehr geehrter Herr Morgner,

wie Sie sicher ....
ENDE
----------

Eine Form ist, die nicht sonderlich elegant, aber verständlich ist. Bei der
nächsten Systemmigration kann man die Form ändern, aber nicht den Inhalt. So
kann man die alten Dokumente entwder belassen wie sie sind, oder eben von
ASCII auf BSCII transformieren, während man sie von einem ASCII- auf ein
BSCII-Sytem überspielt.

Der Entscheidende Vorteil dieser Herangehensweise besteht nur darin, dass
man das sofort machen kann. Ohne Gremium und ohne Abstimmung. Einfach in Sinne
der Vernunft. Die Regeln können einfach sein und man kann einfache Leute
anstellen um dafür Software zu schreiben. Man bleibt also in jeder Beziehng flach
und geht somit kaum Risiken ein.

Wenn eine andere Böhrder vielleicht soetwas erwartet:

----------
>>>>
Anzahl Buchstaben: 51856
Anzahl Woerter: 12730
Absender: Henry Halber, 8000 Zürich, ZH, ...
Absendedatum 15.Februar 2003
Empfaenger: Manfred Morgner, 9500 Wil, SG, ...
Thema: Dateiformate
Nachricht: Sehr geehrter Herr Morgner,

wie Sie sicher ....
<<<<
----------

Kann man die Konvertierung des Formates "im fliegen" innerhalb der
Transportschicht vornehmen. Auch dies kann alles sehr flach und einfach gehalten
werden und damit sicher und schnell.

Ein solches Verfahren habe ich selbst niemals erlebt. Ich kenne nur
Katastrophenverfahren, bei denen Daten ausgedruckt und abgeschireben wurden oder für
enorme Summen Konvertierungprogramme geschrieben wurden und dann doch
Original mit Kopie manuell vergleichen werden mussten usw.


Die Frage der Sicherheit gestaltet sich dabei ziemlich einfach:
Originaldaten dürfen in Archiven nicht verschlüsselt werden weil es unmöglich ist, alle
zum Entschlüsseln erforderlichen Daten, Programme und Maschinen funktionsfähig
mit zu archivieren.

Die Sicherheit der Daten muss um die Maschine herum installiert werden.
Netzwerkzugriffe müssen über spezielle Übergänge (Gateways) geregelt und
kontrolliert werden und andere Massnahmen. Während des Transports müssen die Daten
nicht nachhaltig sein, im Gegenteil. Wenn der Schlüssel nur während der
Übertragung gültig ist, ist ein hohes Mass an Sicherheit erreicht. Die gilt für
Übertragungen durch öffentliche und interne Netze, aber auch für Übertragungen
zwischen Terminal und Datenpool.

Wenn einer einen Hauptrechner raubt, hat er eben alle Daten - wenn er
zerstörungsfrei an die Innereien herankommt. Aber das gilt für einen Einbruch in
ein Amt, bei dem Ordner geraubt werden, auch. Die EDV bietet Möglichkeit, die
Sicherungsaufwändungen zu erhöhen, weil sich mehr Daten an weniger Orten
befinden und sich so nicht nur die Daten, sondern auch die Mittel konzentrieren.

Aber ich glaube, ich schweife wieder ab.


Naja, soweit meine Position. Ich verstehe Deine Kritik gut. Mein innerer
Schweinehund arbeitet schon seit Monaten an einem Universalformat, aber ich
werde ihm nicht erlauben, irgend etwas davon nach aussen zu bringen ;-), auch
wenn mein öffentlicher Vorschlag ziemlich trocken aussieht - dafür ist er
praktikabel.

Viele Grüsse,
Manfred 


-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!