----- Forwarded message from Kristian Koehntopp <[EMAIL PROTECTED]> -----
Date: Sun, 21 Sep 2003 17:19:22 +0200 From: Kristian Koehntopp <[EMAIL PROTECTED]> To: Peter Ross <[EMAIL PROTECTED]> Subject: Re: [FYI] Bin?res XML - On Sun, Sep 21, 2003 at 07:41:56PM +1000, Peter Ross wrote: > was ist eigentlich so furchtbar an ASN.1? ASN.1 tut in etwa das, was XDR tut, das ist richtig. Aber die OSI ist da mit sich selber durchgegangen: Zunächst einmal verwenden die ASN.1 an stellen, wo es nur eingeschränkt sinnvoll ist (ich glaube, daß sowohl X.509 als auch LDAP mit etwas im Klartext lesbaren wesentlich besser dran wären). Dann definiert ASN.1 nur die Hälfte, nämlich die Datenstruktren, jedoch deren Repräsentation - also genau kein Format auf dem Kabel, sondern nur "Es gibt etwas, das heißt x und es enthält y, z und q von den Typen a, b und c". Man braucht einen Satz Endcoding Rules, damit aus dieser Definition ein Wire Format wird. Zum Glück gibt es dann mehr als einen solchen Satz Encoding Rules, damit die Sache nicht zu einfach wird, BER und DER. Weitere sind möglich. Dann sendet mindestens einer dieser Satz Encoding Rules ähnlich wie XML jedes Mal nicht nur die Daten, sondern auch die Strukturdefinition der Daten. Also nicht ein n-Tupel (1, 13.7, "hallo", ...), sondern (("Item", integer, 1), ("Preis", float, 13.7), ("Bezeichnung", string80, "hallo"), ...) und so weiter. Das ist natürlich redundant, und eine der Argumentationen für ASN.1 gegenüber lesbarem Text war natürlich "Es ist kompakter". Dummerweise wird aber nicht wirklich "Item" gesendet, sondern es wird eine OID 1.3.271.23.4.1.2.3.55.1 verwendet, das heißt, anders als bei XML nutzt einem diese Selbstbeschreibung der Struktur gar nichts, denn man muß den Katalog des Herstellers mit dem Prefix 1.3.271.23.4 haben, um zu wissen was ein 1.2.3.55.1 ist. "Item" wäre nicht nur kürzer, sondern würde auch etwas aussagen. Ditto für selbstdefinierte Typen. Anders als Java versendet ASCII-XML und auch ASN.1 nur structe, aber keine Objekte. Das bedeutet, um mit den Empfangenen Daten etwas anfangen zu können, muß der Empfänger schon wissen, was das für Daten sind und was man mit denen machen kann. Es würde also reichen, den struct als "struct artikelinfo" zu bezeichnen, denn wenn der Empfänger nicht weiß, was ein struct artikelinfo ist und wie man ihn bearbeitet, dann nutzt ihm die Kenntnis der inneren Struktur nur sehr eingeschränkt. Java würde mit einer class artikelinfo auch den Code senden könne, und der Empfänger hätte dann eine portable Repräsentation der auf die Daten anwendbaren Methoden. ASN.1, XDR und XML senden die Methoden nicht, XDR aber immerhin dann auch nur den zusammengesetzten Typ und keine Informationen über die innere Struktur, ist also kürzer. XDR definiert außerdem bytegenau und unzweideutig das Wire Format. XML sendet wie ASN.1 Informationen über die innere Struktur, aber immerhin auf eine Weise, die auch einem Empfänger ohne Dokumentation und ohne Decodertools mit natürlicher Intelligenz zugänglich sein kann. ASN.1 kombiniert die Nachteile aller dieser Methoden, und fügt noch einen Haufen Quirks inferiorer Implementationen mit dazu. Kristian ----- End forwarded message -----