Alle großen Anbieter (Omniture, At Internet, Nedstat) bieten dabei XML als Ausgabeformat an. Toll denkt man sich da. Als jemand der seit Jahren mit XML arbeitet und schon etliche Mashup-Projekte gemacht hat träumt man dann schon von tollen neuen Charts und großen Monitoren im Entrée unserer Kunden.

Und dann bekommt man von den Anbietern XML-Beispieldateien. Und plötzlich fallen all die Träume wie ein Kartenhaus zusammen. Von einem Schema oder einer Definition ist weit und breit nichts zu sehen. Weder DTD, noch XSD oder Relax NG ist bei den WebAnalytics-Anbietern in Gebrauch. Mir ist schleierhaft, wie man eine API entwickeln kann, die XML generieren soll, ohne eine Beschreibung der Struktur und der Typen zu verwenden.

Entsprechend katastrophal ist dann auch die Struktur der XML-Dateien. Bei allen Anbietern sieht man mit einem Blick, dass es sich eigentlich nur um gewrappte CSV-Dateien handelt. Typisch ist sowas hier:

<Col>
<Row>Veränderung in %</Row>
<Row>-5,4</Row>
<Row>0,45555555</Row>
<Row>10,3</Row>
</Col>

Und das sieht zumindest – aus Sicht der Formatierung – noch gut aus. Zu finden ist jedoch auch sowas hier:

<Col
/><Row
/>

Womit eigentlich sofort klar wird, dass die Programme mit denen diese Ausgaben generiert werden, noch nie einen XML-Parser gesehen haben, denn einen solchen zu solcherlei Formatierung zu bringen, bedarf es schon einiger Handstände.

Wenn aber die Programme mit denen diese Ausgaben generiert werden, noch nie einen Parser gesehen haben wird früher oder später folgendes passieren: Die Daten, die ausgegeben werden sollen enthalten irgendwelche Zeichen oder eine Struktur, die besonders behandelt werden müsste, damit das ausgegebene XML überhaupt noch wohlgeformt ist.

Und so erhält man dann tatsächlich – sogar als Beispieldatei zugesandt – eine XML-Datei über die jeder Parser stolpern wird:

<?xml version=”1.0″ encoding=”utf-16″?>
<Export>
…
<Metric265>Temps passé par page (chargement)</Metric265>
…

Etliche Versuche mit verschiedenen Programmen, die alle meinten, dass es sich um chinesische Zeichen handeln würde, scheitern. Xmllint meldet dann auch, dass die Daten – entgegen der XML-Deklaration –  nicht in UTF-16 vorliegen sondern in UTF-8 geschrieben sind. Jedes vernünftige System zur Verarbeitung von XML (also z.B. Saxon) wird sofort den Dienst einstellen.

Wäre die Ausgabe mit einem echten XSLT-Prozessor generiert worden, könnte sowas nicht passieren. Dieser hätte die Daten entweder tatsächlich als UTF-16 codiert oder den Dienst verweigert und man hätte eine vernünftige Fehlermeldung ausgeben können.

Aber was soll man auch von Firmen erwarten, die mehr Leute im Verkauf haben als im Support plus Entwicklung?

<wp:post_date>2009-09-16 01:15:29</wp:post_date>

<wp:post_date_gmt>2009-09-16 01:15:29</wp:post_date_gmt>

Kein vernünftiges Programm kann das lesen, man muss noch selber zwei Werte vergleichen um die Timezone rauszubekommen und eine XSD gibt es dafür bestimmt auch nicht.

Jetzt hat er ein Plug-In veröffentlicht, dass Safari beibringt, XML vernünftig – als strukturierten Baum – darzustellen. Und Marc wäre nicht Marc, wenn dieses Plug-In nicht auch noch konfigurierbar und sogar über prototype mittels JavaScript ansprechbar wäre.