Mal wieder was aus dem richtigen Leben: Wie jeder Heimwerker weiss, mach man beim Fliesenlegen Abstandhalter zwischen die Fliesen, damit sie sich nicht verschieben oder gar ohne Luecke aneinanderstossen. Da verwendet man typischerweise sowas: Abstandhalter aus Kunststoff.
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.
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 />
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_
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_
Mario Sixtus hat in Technology Review einen schönen Artikel geschrieben über neue echte Leben im Web: Das Web sind wir. Hier mein offener Brief an Mario Sixtus und alle, die sich für das wahre Leben im Web interessieren:
Mit grossem Interesse habe ich ihren Artikel "Das Web sind wir" in Technology Review gelesen.
Bei diesen Themen glaube ich, dass Sie sich auch fuer virtuelle Praesenz (VP) interessieren. Das passt perfekt zu Ihren Beobachtungen. Wir betreiben seit langem das Jabber Virtual Presence Project, dass sich zur Aufgabe gemacht hat, Menschen auf dem Web sichtbar zu machen. User erscheinen als Avatarfigur auf den Webseiten auf denen sie gerade surfen. User sehen sich gegenseitig. Sie treffen sich auf Webseiten. Sie sind also virtuell praesent auf den Seiten. Dort koennenn sie sich unterhalten durch Chat/Video und bald Voice.
Virtuelle Praesenz passt perfekt zu ihren Aussagen: Sie schreiben "Das Web sind wir" und dass immer mehr als reale Menschen auf dem Web erscheinen im Gegenatz zu erfundenen Identitaeten. Das passt zum Claim des VP Projekts: LLuna - das wahre Leben im Web (LLuna ist der Client Name). LLuna ist Social Software weil sich Leute auf Webseiten treffen. Oft kennen sie sich nicht vorher, aber manchmal trifft man sogar Bekannte. Fast immer trifft man Leute mit gleichen Interessen, weil man sich auf den gleichen Seeiten herumtreibt und sich so oefter trifft. Weblogs sind ideal als Seiten zum Treffen. Die Weblogs sind ja sozusagen die neuen Homepages und Autoren, die dort virtuell praesent sind, koennen dort ihre Leser treffen. NETZ-PARTYS: dazu muss man wenig sagen. Mit Usern, die sich auf Webseiten treffen, kann man richtige Netzparties machen. Eine LLuna-Userin macht bald eine Vernissage fuer ihre Gallerie-Website mit virtueller Praesenz. Sehr interessant, aber noch nicht implementiert, ist die Kombination von Virtueller Praesenz (VP) und Social Networks (SN). SNs koennen Hintergrundinformationen zu den Leuten geben, die man im Web mit VP trifft. Mit VP allein hat man nur einen Nickname und eine animierte Figur. Aber mit SN kann man erfahren ueber welche Ecken man denjenigen kennt, den man da trifft, selbst wenn man keine direkte Beziehung hat. Mit anderen Worten VP ist der ideale Stichwortgeber fuer SN.
Ich zitiere aus Ihrem Artikel: Wer Vorteile aus dem Internet ziehen und dort für sich nutzen will, wo wir alle Sozialversicherungsnummern haben, der muss als echte Person präsent und aktiv sein. Das "Web 2.0" wird ein Ort für echte Menschen sein. Herzlich Willkommen in der Wirklichkeit." - Das spricht mir aus dem Herzen. Mit virtueller Praesenz treffen sie im Web echte Menschen. Das sind zwar auch anonyme Chatter, aber der Trend gehtr eindeutig dazu sich selbst darzustellen und nicht eine Kunstfigur. Willkommen beim wahren Leben im Web.
Falls sie das interessiert, probieren Sie doch mal:
http://community.lluna.de (fuer User)
oder:
http://developer.lluna.de (fuer Entwickler)
