Gestaltung einer DTD fuer XMLHttpRequest Antworten

[Lucien]

Hi Leute,

ich experimentiere gerade ein wenig mit XMLHttpRequest herum und bin nun am ueberlegen wie die XML-Antworten aufgebaut sein sollten. Vielleicht koennt ihr mit ja ein paar Vorschlaege machen, bzw. mich auf Fehler / falsche Ideen hinweisen.
Per "GET"-Request wird dem Server (hier eine PHP Applikation) mitgeteilt welche Funktion geladen und ausgefuehrt werden soll.

• Zunaechst habe ich mir ueberlegt, dass der Server stets einen Integer (code) mitschicken sollte, der angibt ob es bei der Verarbeitung des Requests zu Fehlern gekommen ist.

• Im Fehlerfall wird des weiteren eine "Dump-Id" gesendet, die eine Datei auf dem Server identifieziert, welche weitere Informationen zu dem Fehler enthaelt. Dadurch vermeide ich, dass u.U. sicherheitsrelevante Informationen zum Benutzer gelangen, dieser aber mit dem Fehler in Verbindung gebracht werden kann, sollte er mit mir in Kontakt treten.

• Wird die Funktion korrekt ausgefuehrt (code == 100) wird deren Ergebnis (kann ein Integer, String, Boolean oder XML-Dokument sein) mitgesendet.

Also sieht eine XML-Antwort im Fehlerfall z.B. so aus:

<?xml version"1.0"?>
<response>
    <data id="code">602</data>
    <data id="dumpid">45433e33f2</data>
</response>

... und wenn alles glatt laeuft:

<?xml version"1.0"?>
<response>
    <data id="code">100</data>
    <data id="result">true</data>
</response>

Also, erst mal danke fuers durchlesen :-)
Bin auf Antworten gespannt...

Grüsse, Lucien

[MudGuard]

Hi,

<response>
    <data id="code">602</data>
    <data id="dumpid">45433e33f2</data>
</response>

<response>
    <data id="code">100</data>
    <data id="result">true</data>
</response>

was spricht für die ids und gegen

<response>
  <code>602</code>
  <dump>wasauchimmer</dump>
</response>

<response>
  <code>100</code>
  <result>wasauchimmer</result>
</response>

cu,
Andreas

[Lucien]

was spricht für die ids und gegen

<response>
  <code>602</code>
  <dump>wasauchimmer</dump>
</response>

<response>
  <code>100</code>
  <result>wasauchimmer</result>
</response>

Bisher hab ich es auch noch so wie du vorschlaegst. Aber da ich im Moment nochmal alles neu ueberdenke dachte ich, dass ich es spaeter beim auswerten einfach habe. Sprich in JavaScript:

var code_node = xml.getElementById("code").

Ausserdem ist wohl nur eine Code-Angabe in einer Response sinnvoll und diese mache ich ja durch id unique. Denkbar waehre aber auch ein:

<code value="601" />

Da bin ich mir einfach nicht sicher. Gibt es irgendwelche Empfehlungen wann man was benutzen sollte?

Grüsse,
Lucien

[MudGuard]

Hi,

Bisher hab ich es auch noch so wie du vorschlaegst. Aber da ich im Moment nochmal alles neu ueberdenke dachte ich, dass ich es spaeter beim auswerten einfach habe. Sprich in JavaScript:
var code_node = xml.getElementById("code").

getElementsByTagName("code")[0] sollte doch auch funktionieren.
Oder über firstChild des response-Elements usw.

Und verschiedene Datenarten (den Ergebniscode, den Fehlerdump und das tatsächliche Ergebnis) in ein und derselben Elementart (bei Dir: <data>) unterzubringen, finde ich schlecht.
Dann kann man auch gleich
<a id="response"><a id="code">100</a><a id="dump">asdlkfjasfd</a></a>
machen - warum sollte man noch zwischen response und data unterscheiden, wenn man nicht zwischen code und dump bzw. result unterscheidet?

Wie legst Du z.B. in der DTD fest, daß das erste Kind von response ein data-Element sein muß (ok, soweit noch kein Problem), das die id="code" hat?

Wenn sich die Element_NAMEN_ unterscheiden, ist das kein Problem, in der DTD festzulegen, daß das code-Element das erste Kind des Response-Elements sein muß.

Oder wie legst Du fest, daß es ein data-Element mit id code geben muß und entweder eins mit der id dump oder eins mit der id result?
Mit Elementnamen ist das kein Problem: (code (dump|result))

cu,
Andreas

[Lucien]

Und verschiedene Datenarten (den Ergebniscode, den Fehlerdump und das tatsächliche Ergebnis) in ein und derselben Elementart (bei Dir: <data>) unterzubringen, finde ich schlecht.
Dann kann man auch gleich
<a id="response"><a id="code">100</a><a id="dump">asdlkfjasfd</a></a>
machen - warum sollte man noch zwischen response und data unterscheiden, wenn man nicht zwischen code und dump bzw. result unterscheidet?

Da hast du natuerlich recht. Das faellt mir der Begriff Semantik ein, der diese Problematik sinnvoll beschreibt, ODER?

Ich denke mit einem <code value="601" /> fahre ich schon mal ganz gut, da code definitiv nur ein Integer sein wird und nie kindknoten besitzen wird.
Aber wie kann ich festlegen, dass er nur EINEN code-Knoten geben darf?

Ausserdem moechte ich, dass innhalb des <data>...</data>-Knotens belibiges anderes XML stehen darf. Kann ich das in einer DTD auch festlegen?

Grüsse,
Lucien

[MudGuard]

Hi,

Und verschiedene Datenarten (den Ergebniscode, den Fehlerdump und das tatsächliche Ergebnis) in ein und derselben Elementart (bei Dir: <data>) unterzubringen, finde ich schlecht.
Dann kann man auch gleich
<a id="response"><a id="code">100</a><a id="dump">asdlkfjasfd</a></a>
machen - warum sollte man noch zwischen response und data unterscheiden, wenn man nicht zwischen code und dump bzw. result unterscheidet?

Da hast du natuerlich recht. Das faellt mir der Begriff Semantik ein, der diese Problematik sinnvoll beschreibt, ODER?

Ja.

Ich denke mit einem <code value="601" /> fahre ich schon mal ganz gut, da code definitiv nur ein Integer sein wird und nie kindknoten besitzen wird.

Dann ist es egal ob als Content oder Attributwert, ja

Aber wie kann ich festlegen, dass er nur EINEN code-Knoten geben darf?

Schau Dir nochmal das von mir angegebene Content-Model an: (code (dump|result))

Siehst Du da irgendwo etwas, was mehrere code-Elemente erlaubt?

cu,
Andreas

[Lucien]

Schau Dir nochmal das von mir angegebene Content-Model an: (code (dump|result))

Siehst Du da irgendwo etwas, was mehrere code-Elemente erlaubt?

Jetzt ist's klar. War mir vorher nicht bewusst was du damit meinst. Danke fuer dir Hilfe.

Grüsse,
Lucien

[Tim Tepaße]

Hallo,

mal eine etwas andere Lösung, eine Ebene tiefer als XML, da die von Deinem Server gelieferten Informationen sich eigentlich schon mit HTTP übermitteln lassen:

• Zunaechst habe ich mir ueberlegt, dass der Server stets einen Integer (code) mitschicken sollte, der angibt ob es bei der Verarbeitung des Requests zu Fehlern gekommen ist.

Das macht er schon teilweise, ich würde einfach das bestehende System mitnutzen, nämlich die HTTP Status Codes, an die Du Dein System angelehnt zu haben scheinst. Wenn ich den RFC zu HTTP 1.1 lese, sind die Erläuterungen zu den bestehenden Status Codes lediglich Empfehlungen, zudem kann man den Zahlenraum der Statuscodes erweitern (z.B. 337, 289 ...), d.h. Du könntest zusätzliche Fehlermeldungen zusätzlich zu den bestehenden definieren und vom Server senden lassen. Wobei vieles, eigentlich alles schon von "500 Internal Server Error" abgedeckt sein würde.

Auf der Javascript-Seite hättest Du diesen Status Code dann in XMLHttpRequest.status sofort verfügbar, ohne den Umweg über XML zu gehen.

• Im Fehlerfall wird des weiteren eine "Dump-Id" gesendet (..)

Diese könntest Du dann bei deinen Status Codes der 5xx-Klasse in die Reason-Phrase packen, d.h. zum Beispiel "500 Fehler 45433e33f2". Wie gerade gesagt ist die Reason-Phrase im HTTP-Standard nicht verbindlich, d.h. man kann sie im Prinzip ändern und an eigene Bedürfnisse anpassen, solange das nicht gegen die prinzipielle Information eines 500er-Fehlers verstoßen.

Auf die Reason-Phrase könntest Du dann mit XMLHttpRequest.statusText zugreifen.

<response>
    <data id="code">100</data>

Nebenbei halte ich es hier mit MudGuard, ich würde die Information gleich als Element, nicht als ID schreiben. Ist einfach lesbarer.

<data id="result">true</data>

Wobei: Ich würde das Result hier nicht mehr in als Response-Phrase verwenden.

Zusammenfassend:

Bei meiner hypothetischen HTTP-Lösung würde ich den Fehlerstatus schon gleich in HTTP rein kodieren, in Deinem Javascript wirst Du ihn eh abfragen, ob nun als HTTP Status Code oder als eigener, selbstdefinierter Code in der XML-Botschaft. HTTP und seine Status Codes sind nun mal ein bekanntes System, zudem gilt das KISS-Prinzip.

Außerdem hätte das den Vorteil, dass Du in Deiner Javascript-Anwendung gleich die gesamte Fehlerbehandlung mit einem Schlag behandeln kannst. Es gibt ja immer noch die HTTP-Fehler, die nicht von Deiner Server-Anwendung zurückgeliefert werden, wenn zum Beispiel der Webserver Dein PHP/Perl/Python/whatever-Script nicht findet oder nicht ausführen kann. Anstatt einmal eine Fehlerbehandlung für solch generelle Fehler über XMLHttpRequest.status zu basteln und zusätzlich noch eine Fehlerbehandlung mit Deinen eigenen Status Codes, die wahrscheinlich mit "200 OK" gesendet werden und die Du aus dem XML raus fummeln musst.

Wenn kein Fehler auftritt, wird eben wie über HTTP üblich "200 OK" zurückgeliefert, vom Server angeforderte Daten dann in XML oder wie es Dir beliebt.

Tim

[Lucien]

Danke für diese Anregung. Die Idee gefällt mir sehr gut...

Grüsse,
Lucien