Warum JSON oder XML

[hotti]

hi,

siehe Thema. XML kenne ich schon länger, JSON habe ich mir heute angeschaut. Dabei gehts im Wesentlichen darum, in welcher Struktur die Response zurück zum UserAgent kommt und wie das Geprassel (responseXML, responseText, JSON) zum DOM passend gefrickelt wird.

Aber warum mit Haubitzen auf Mücken schießen? In eine responseText kann ich auch komplizierte Datenstrukturen schreiben und mit simplen Methoden wie z.B. split() wieder DOMgefällig machen. Wobei TEXT in einer responseText dann auch noch wesentlich schlanker ausfällt, als TEXT in XML verpackt.

Sagt mal bitte, wann brauche ich XML oder JSON?

Hotte

[suit]

Sagt mal bitte, wann brauche ich XML oder JSON?

wenn du zwischen unterschiedlichen systemen daten austauschen willst, ist ein vereinheitlichtes format sehr praktisch :)

[hotti]

Sagt mal bitte, wann brauche ich XML oder JSON?

wenn du zwischen unterschiedlichen systemen daten austauschen willst, ist ein vereinheitlichtes format sehr praktisch :)

Sorry, ich hab vergessen zu schreiben, dass es mir nur um Ajax geht. Und das hab ich bis jetzt alles mit responseText hinbekommen.

Hotte

[frankx]

Hellihello,

Sorry, ich hab vergessen zu schreiben, dass es mir nur um Ajax geht. Und das hab ich bis jetzt alles mit responseText hinbekommen.

Es geht ja nicht um "hinbekommen". Mit PHP 5.nochwas hast Du eingebaute JSON-Funktionen (oder Erweiterung?). Du kannst PHP mittels derer in JS-Objekte verwandeln. Dass du das auch anders hinbekommen kannst, ist klar.

Mittels AJ.. kannst du ohne auf die Antwort zu warten im Hintergrund Daten austauschen. Mag sein, dass das zB. für bestimmte Autocompletes in JS-Frameworks genutzt wird.

Grundsätzlich, ich wiederhole micht, geht es wohl eher ums tuning denn ums "hinbekommen".

Dank und Gruß,

frankx

[hotti]

Moin,

ich habe schon einige Schnittstellen für den Datenaustausch zwischen Anwendungen programmiert. Selbstverständlich bekommt ein Auftraggeber XML, wenn er das haben will. Proprietäre Datenformate - bittesehr. 50% Overhead - mir doch egal, Kunde ist König.

Aber wenn ich selbst der Auftraggeber bin, bringe ich Zweckmäßigkeit, Aufwand, Performance und Ressourcenfreundlichkeit soweit als möglich in Einklang (neben ein paar anderen Dingen). Bezogen auf Ajax war das bisher weder XML noch JSON.

Hotte

[FraFu]

Hallo!

Aber wenn ich selbst der Auftraggeber bin, bringe ich Zweckmäßigkeit, Aufwand, Performance und Ressourcenfreundlichkeit soweit als möglich in Einklang (neben ein paar anderen Dingen). Bezogen auf Ajax war das bisher weder XML noch JSON.

Warum nicht JSON? Ich sehe hier den großen Vorteil, dass ich daraus direkt JS Objekte machen kann.
Das erspart sehr viel Zeit.
Kommt natürlich auch wieder auf die Anwendung an aber im Normalfall würde ich JSON verwenden.

Was verwendest du für ein Datenformat?

mfg
  frafu

[Struppi]

Aber wenn ich selbst der Auftraggeber bin, bringe ich Zweckmäßigkeit, Aufwand, Performance und Ressourcenfreundlichkeit soweit als möglich in Einklang (neben ein paar anderen Dingen). Bezogen auf Ajax war das bisher weder XML noch JSON.

Der Aufwand kann für dich (und evtl. dem Kunden) bei definierten Datenformaten kleiner werden, wenn es irgendwann darum geht die Daten auszutauschen, was suit schon angedeutet hat. Und es ist natürlich ein Aufwand ein eigenes Format zu entwickeln, wenn es schon fertige (Perl)Module für ein anderes gibt.

Was Datenmenge und Performance angeht, ist man heutzutage nicht mehr darauf angewiesen jedes Byte zu sparen. Performance bekommst du z.b. deutlich mehr, wenn deine Perl Skripte nicht als CGI, sondern z.b. als mod_perl ausgeführt werden oder wenn du Rechenzeit verteilen kannst (z.b. auf einen Datenbankserver).

Wenn du nur ein kleines Skript schreibst, sind aber natürlich die Vorteile nur schwer zu erkennen, bzw. hast du die von dir beschriebenen Nachteile. Ob und wie weit ein standardisiertes Format für dich nützlich ist, musst du selbst abschätzen.

Struppi.

[suit]

Der Aufwand kann für dich (und evtl. dem Kunden) bei definierten Datenformaten kleiner werden, wenn es irgendwann darum geht die Daten auszutauschen, was suit schon angedeutet hat. Und es ist natürlich ein Aufwand ein eigenes Format zu entwickeln, wenn es schon fertige (Perl)Module für ein anderes gibt.

richtig - und es hat keiner verlangt bei ajax auf json oder xml zu setzen, natürlich reicht auch eine kommaseparierte liste an werten - oder meinetwegen eine strichpunktseparierte liste

sinnigerweise ist aber auch dieses format (csv) bereits definiert

wer unbedingt etwas eigenes erfinden will: gerne

ich jedenfalls benüge mich mit xml (json hab ich noch nicht verwandt)

wenn man zb aus einem warenwirtschaftssystem in einen onlinshop synchronisiert - sagen wir 2x am tag - is man über eine einheitliche schnittstelle froh

man sagt dem entwickler der wawi-software "mach mir ein xml/csv mit den daten" und der weiß was der tun muss - wenn ich aber erst ein eigenes format erfinden muss, dem gegenüber erkläre wie es funktionert, er eine schnittstelle schreiben muss und ich das ebenfalls tun muss - prost malzeit

noch dazu: wenn sich eines der systeme ändert, das austauschformat aber universell ist, ist es wahrscheinlich, dass in einem neuen system ebenfalls wieder dieses austauschformat unterstützt wird

wie bereits erwähnt, ob ich

wert;wert,wert

oder

<node>  
  <value>wert</value>  
  <value>wert</value>  
  <value>wert</value>  
</node>

übertrage ist natürlich aus gründen des overhead relevant - die frage ist die lesbarkeit

bei einer kleinen datenmenge - sagen wir 5 werte - ist sicher die csv-variante praktischer

bei komplexen datenansammlungen (tabellen, datensätze mit sagen wir 50 feldern und 1000 datensätzen - oder komplexe baumstrukturen) würde ich DRINGEND empfehlen, ein ordentliches format zu verwenden

wenns natürlich um ajax geht und ich einen inhalt in der webseite gegen einen anderen austausche, brauch ich kein komplexes datenformat - dann reicht mir ein fertiger string den mir der server liefert (innerHTML = respnseText ist da vollig ausreichend)

wenn ich hingegen aus einem response 15 variablen lesen muss, die an verschiedenen stellen eingefügt werden sollen, werde ich mir wohl überlegen, ob ich nicht ein entsprechend strukturiertes format nehme (schon allein aus gründen der lesbarkeit)

[Joachim]

Hi,

Sagt mal bitte, wann brauche ich XML oder JSON?

ich finde json sehr angenehm, vor allem weil es ohne Aufwand wieder in ein js-Object verwandelt werden kann. Einziger Nachteil: die Php-Methode json_encode() hat Probleme mit Nicht-utf8-Daten.

Gruesse, Joachim

[Tim Tepaße]

Hallo,

Aber warum mit Haubitzen auf Mücken schießen? In eine responseText kann ich auch komplizierte Datenstrukturen schreiben und mit simplen Methoden wie z.B. split() wieder DOMgefällig machen.
Sagt mal bitte, wann brauche ich XML oder JSON?

Du bastelst ein Textformat für eine Datenstruktur und dazu Code, um Daten in Text zu transformieren und anderen Code, um Text wieder in Daten zu bekommen.
Du bastelst ein weiteres Textformat für eine andere Datenstruktur und dazu weiteren Code, um Daten in Text bekommen und weiteren, anderen Code, um Text wieder in Daten zu bekommen.
Du bastelst noch ein anderes Textformat für wieder eine andere Datenstruktur und dazu wieder weiteren Code, um Daten in Text umzuwandeln und wieder weiteren Code und Text wieder in Daten zu verwandeln.

Irgendwann danach guckst Du Dir die Menge an Quellcode an, die sich mit Text-Umwandlungen beschäftigt und vergleichst diese Menge mit der Menge an Quellcode, in der Du tatsächlich was mit den bekommenen Daten anfängst.

Schlimmer noch, Du hast Muster erkannt, es gibt verschiedene Datentypen in Deinen unterschiedlichen Struktur wie Zahlen, Strings, Wahrheitswerte, Zeitstempel und anderes. Und Du erkennst verschiedene Muster der Sammlungen von einzelnen Datentypen, wie Aufzählungen, Zuordnungen und Mengen von skalaren Werten. Und Du siehst diese Muster immer öfters, wenn Du nur darauf achtest.

Anfangs kann es Spaß machen, solche Probleme für sich selbst von Grund auf zu lösen. Aber wenn man in seinem Projekt eigentlich was anderes machen will und die Textverarbeitung nur Mittel zum Zweck sein soll, dann nervt das irgendwann. Wenn man etwas wieder und wieder in leichter Variantion macht, dann will man das Problem wegabstrahieren und sich nur noch um die leichten Variationen kümmern müssen. Dann kommt man dann vielleicht auf den Gedanken einer Metasyntax, die viele der obigen Muster vereint.

Die Frage, welches Metaformat verwenden soll, hängt von vielem Zeugs ab. Schreibbarkeit, wenn es von Menschen editiert werden soll. Definierte Datentypen, in Abhängigkeit der eigenen Daten. Eine mögliche Verarbeitbarkeit durch eine Toolchain wie Validierung, Minimierung. Die Kapazitäten von Sender und vor allem vom Empfänger. Die Serialisierungsmöglichkeit eigener, selbst definierter Datentypen. Lesbarkeit für das Debuggen. Einfachheit der Implementierung. Die eventuelle Zielgruppe anderer Software-Entwickler, die die eigene Schnittstelle benutzen müssen. Usw. usf.

Im Browser würde ich mich so entscheiden:

• Wenn nur ein skalarer Wert übertragen wird, dann den Wert einfach in den HTTP-Response-Body packen.

• Wenn nur eine flache Liste mehrerer gleicher Werte übertragen werden soll, auch in den Response-Body, zeilenbasiert, split(). Bei einer Zuordnung könnte man sich auch überlegen, das RFC-822-X-Header-System von HTTP-Messages zu überladen.

• Wenn eine verschachtelte, Baum-artige Datenstruktur übertragen werden sollen ...
• Wenn mehrere unterschiedliche in JS-abbildbare Datentypen übertragen werden sollen ...
• Wenn eine Mischung aus Zuordnungen und Listen von Werten übertragen werden sollen ...
• Wenn ich genau die serverseitige Datenstruktur auch in Javascript nutzen will ...
• Wenn ich vorher nur einen groben Überblick über die zu erwartenden Daten habe ...
... dann jeweils in JSON. Das definiert zwar nur eine Untermenge von Daten und deren Strukturen, aber eine sehr sinnvolle, weil diese sich genau in Javascript und vielen serverseitigen Sprachen ohne der Definition eigener Objekttypen abbilden lässt. Die Lesbarkeit beim Debuggen ist nahe an der Vorstellung dessen, was man im Browser verarbeitet. Und eine sichere, eval-lose Verarbeitung ist immer noch sehr klein in der Codemenge. JSON hat da einfach einen sehr intelligenten Platz gefunden.

• Wenn ein strukturiertes Dokument mit viel (Text)-Inhalt übertragen und direkt ins Browser-Dokument eingefügt werden soll, dann mit XML (Oder HTML im Response-Body und dann innerHTML).

Außerhalb des Browsers gibt es ja auch einen Haufen von Metasyntaxen; dort entscheide ich mich ungefähr wie folgt, wenn ich die Wahl habe:

• Für eine Liste von einzelnen Werten eine Textdatei mit einer Zeile pro Wert. Wunderbar zu verarbeiten mit UNIX-Tools.

• Für eine Liste von Records: charakter separated values (CSV). Auch nett zu verarbeiten mit UNIX-Tools.

• Für Daten, auf die ähnliches zutrifft wie die obigen JSON-Problemfälle: YAML. Es kann diverses mehr als JSON oder Nextstep ASCII Property Lists, deswegen nutze ich es aber nicht. Stattdessen finde ich es allein wegen der arg reduzierten Schreibweise toll. Künstliche Delimiter wie eckige oder geschweifte Klammern sind optionale Schreibweisen, es gibt auch eine durch natürliche Notation inspirierte Schreibweise, die mir sehr, sehr, sehr zusagt. YAML ist meiner Meinung nach dafür gedacht, editiert zu werden, JSON oder PLists, die gleiches leisten, sind eher dafür gedacht, leichter von Parsern verarbeitet zu werden.

• Markdown für leicht strukturierte Texte, die dennoch maschinell verarbeitet (= zu HTML umgewandelt) werden sollen. Wie bei YAML finde ich die Syntax hier sehr an meinen normalen Gewohnheiten beim Schreiben reines Textes orientiert.

• XML würde ich nicht für Konfigurationen oder reine Datenstrukturen nehmen, sondern für stark strukturierte Texte, mit einem definierten Vokabular von Strukturen, Texte die mit anderen zusammen erarbeitet werden und die von einer Standard-Toolchain verarbeitet werden sollen. SDML ist ein gutes Bespiel einer XML-Anwendung, finde ich. Ein schlechtes Beispiel für XML-Anwendung sind Konfigurationssyntaxen. Dort sind die Zuordnungen meist nur kleinere Werte, durch die XML-Syntax hat man dann mehr XML-Metasyntax auf dem Bildschirm denn tatsächliche Werte.

Andere Metasyntaxen:

Das Datenmodell von RDF ist genial für die Abbildung von (zyklischen) Graphen, bei denen Ecken und Kanten alle möglichen selbst definierten Typen von Ecken und Kanten sein. Das Textformat RDF/XML ist gräußlich, mit Notation3 oder Turtle gibt es aber sehr nette andere Syntaxen.

Lisper rufen natürlich nach der Meta-Syntax schlechthin, nach S-Expressions, die wiederum alles bedeuten können. Auch ein nettes Konzept, aber wohl eher mächtiger, wenn man es mit einem S-Expressions-verarbeitendem Prozessor verarbeitet.

Bin ich ins Abschweifen gekommen? Tschuldigung.

Tim