[kris@xxxxxxxxxxxxxxxxxxxxxxxxx: Re: [FYI] Bin?res XML -]
----- Forwarded message from Kristian Koehntopp
<kris@xxxxxxxxxxxxxxxxxxxxxxxxx> -----
Date: Sun, 21 Sep 2003 17:19:22 +0200
From: Kristian Koehntopp <kris@xxxxxxxxxxxxxxxxxxxxxxxxx>
To: Peter Ross <Peter.Ross@xxxxxxxxxxxxxxxxxxx>
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 -----
--
To unsubscribe, e-mail: debate-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: debate-help@xxxxxxxxxxxxxx