7. Juli 2005

Poster bei PRESENCE 2005

Mein eingereichtes Paper zur PRESENCE 2005 hat es nicht ins Vortragsprogramm geschafft. Aber immerhin doch als Trostpreis noch als 2-seitige Kurzpaper (Poster) in die Proceedings. Ehrlicherweise muss ich zugeben, dass sich in der Eile der Paperabgabe ein paar Fehler eingeschlichen haben, die einfach einen schlechten Eindruck hinterlassen. 2 Überschriften waren gleich, die Bildnummerierung durcheinander und ein paar Schreibfehler, die eine Rechtschreibkorrektur nicht erwischen kann. So gesehen kann ich noch froh sein, dass es überhaupt veröffentlicht wird. Und nicht nur das. Ich bin ja nicht auf Paper-Veröffentlichungen aus, sondern auf Zuhörer. Ein Poster-Display hat auf der Konferenz selbst vermutlich größer Öffentlichkeitswirkung, als eine Präsentation. Also dann, see you at Presence 2005 in London, 21-23rd September 2005.

6. Juli 2005

Wer braucht XSL?

Habe ich jemals über meine Abneigung gegenüber XSL geschrieben? 2 Kritikpunkte: 1. Lesbarkeit, 2. Trennung von Code und Design. Wegen Punkt 2 finde ich XSL schlecht und falsch. Wegen Punkt 1 hasse ich es. Kurz: 1. XSL ist unleserlich. Die Skriptbefehle sehen genauso aus, wie die Daten und sind dazwischen verstreut. 2. Der Skriptcode im gleichen Dokument, wie das Design. Beides vermengt bildet das XSL. Früher hat man mal Code und Design getrennt.

Zu 1: XSL kommt heraus, wenn ein XML-Liebhaber eine Skriptsprache erfinden will und deshalb alle Sprachelemente in spitze Klammern packt.

Muss eine foreach Schleife wirklich so aussehen:

<?xml:namespace prefix = xsl /></xsl:for-each>

Das sah auch schon mal in anderen Sprachen so aus:

foreach (item in dom.xpath("/sales/record")) ;

Glaubten die XSL Erfinder wirklich, dass man nur XML ganz toll parsen kann und deshalb muss man eine Skriptsprachen im XML Format machen? Dazu kommt noch, dass die meisten Leute mit XSL am Ende dann HTML/XHTML erzeugen. Die HTML Fragmente stehen zwischen den XSL Tags und alles sieht nach Spitze-Klammer-Doppelpunkt-Slash Einheitsbrei aus.

Zu 2: Wo wir schon gerade bei der Mischung von XSL-Skript und HTML sind. Die XSL-Skriptanweisungen sind Code. HTML mit CSS ist das Design. Gerade, weil man bei HTML ja gerne mal Formatierung mit Tabellen macht. Also sind bei XSL Code und Design vermischt. Eine tolle Idee. Wer hat schon mal von Templates gehört? Ein Template, das ist ein Dokument, dass ein Design festlegt. Es enthält keinen Code, außer vielleicht Javascript Code für die Clientseite. Code sollte ein Template benutzen, nicht im Template drin stehen.

Das richtige Design wäre gewesen: Eine Skriptsprache, die aus Daten und einem Template schließlich HTML erzeugt. 3 Dateien: Skript(Code), Daten(XML oder Datenbank), Design(Template). XSL verwendet typischerweise nur 2 Dateien: Daten(XML), Code und Design(XSL). Schade.

Skriptsprachen gibt es genügend. Die hätte man nicht erfinden müssen. Im Fall von XSL hätte sich das Javascript angeboten, weil das sowieso schon im Browser implementiert ist und auch in vielen Application-Servern. Oder vielleicht PHP oder Python oder man hätte das variabel gelassen und nur eine einheitliche Templateschnittstelle geschaffen.

Warum rege ich mich überhaupt auf? Wir trennen Skriptsprache und Template bei allen Projekten. Was schert uns was die anderen machen? Es gibt eben Leute, die großen Einfluss auf die technische Entwicklung haben, weil sie in einem Moment an der richtigen Stelle sitzen und alle zu ihnen aufschauen. Eine solche Stelle ist(war) das W3C (WWW Consortium), dass die Web Standards macht(e). Wenn solche Leute falsche technische Entscheidungen treffen, dann haben sie eine Chance, dass es trotzdem die ganze Welt nachmacht. Auf diese Weise ist XSL zum Standard geworden und sogar in Browser eingebaut worden. Das wäre einfacher und besser gegangen. Schade dass keine 3-komponentige Formatierungsengine in Browser eingebaut wurde. Die könnte man gut verwenden.

Bei der Gelegenheit möchte ich auch noch mal anmerken, dass Leute, die HTML und PHP mischen, keinen Deut besser sind, als XSL-ler.

Etwas ausführlicher und auch schon etwas früher steht das auch hier, aber ich habe es erst heute entdeckt und musste das mal loswerden.

_happy_coding_

1. Juli 2005

Jabber Software Foundation stellt sich selbst ein Bein

Apple hat seit einiger Zeit auch einen Instant Messenger. Apple spielt dabei den Good Guy und verwendet ein Open Source Instant Message Protokoll, naemlich Jabber. Natuerlich will Apple das Programm schoen machen fuer die User und dazu gehoert ein Bild von den Kontakten in der Buddyliste. Da fragte sich der Apple-Entwickler, wo er das Bild unterbringen soll. Der Benutzer will sein Bild uploaden. Das Bild soll im Server gespeichert werden, damit andere User es dort abrufen koennen. Leider hatte die JSF das JEP-0008, in dem der Avatarspeicher im Server spezifiziert war, zurueckgezogen. Aber es gab einen Rettungsanker. In der digitalen Visitenkarte (genannt vCard) kann man auch ein Bild unterbringen. Das tut Apple dann auch, und ist voellig standardkonform.

Daraufhin geht ein Aufschrei durch die Jabber Community, wie schlecht das technisch gemacht ist, weil jeder, der eine Email- oder Postadresse vom anderen braucht, sich die vCard runterlaedt und dann ausser 300 Byte Daten auch noch 10 Kb Bild bekommt ohne sich wehren zu koennen. Das ist wirklich schlecht und zeigt, dass das Bild nicht in die vCard gehoert. Schade, dass die JSF das JEP-0008 fuer ungueltig erklaert hat. Denn Apple haette es bestimmt verwendet. So blieb aber nicht anderes uebrig als das Bild in die vCard zu speichern.

Warum die JSF JEP-0008 'retracted' hat kann man nur vermuten. Ich glaube das geschah in der fruehen Euphorie des Publish and Subscribe (PubSub, JEP-0060). Damals meinten mache Leute in der Jabber Community, dass man eigentlich alles mit PubSub machen sollte und wollten die Entwickler davon abhalten, 'alte' Protokolle zu verwenden. Das war 1. unfreundlich gegenueber den Entwicklern, die das schon implementiert hatten (z.B. LLuna) und 2. ein Schuss ins Knie, wie die iChat/Avatar Geschichte zeigt. Zu allem Ueberfluss ist PubSub in 3 Jahren nicht so richtig in die Gaenge gekommen, so dass es seit 3 Jahren keine technisch vernuenftige Avatar-Spezifikation gibt, obwohl es schonmal eine gab.

_happy_coding_