Previous PageNext Page

Living Worlds vs. VRML97

Die Living-Worlds-Konzepte spiegeln die Komplexität ihrer Anwendungsproblematik wider. Die VRML97-Bibliothek, in der diese Konzepte prototypisch von der Living-Worlds-WG realisiert wurden (auf CD-ROM), ist deutlich komplexer, als die Living-Worlds-Konzepte es an sich verlangen würden. Der Grund für die Zunahme an Komplexität ist in der präferierten Arbeitsweise der WG zu suchen.


Zur Erinnerung: Die (ungeschriebenen n, aber dennoch von allen als verbindlich akzeptierten) Grundregeln für die WG-Arbeit lauten:


Alle drei Regel haben den unbeliebten, aber bewußt im Kauf genommenen Nebeneffekt, daß der daraus resultierende Code ziemlich undurchsichtig wird. Bei der Einführung eines einzelnen neuen Knotens mit überschaubarer Funktionalität (wie etwa der KeyboardSensor) macht dies wenig aus. Bei Living Worlds aber sind die Effekte besonders auffällig:


1) VRML97 verfügt per Definition (noch) nicht über diejenigen Sprachmittel, mit denen die neuen Living-Worlds-Konzepte mit einiger Direktheit auszudrücken wären. Man muß immer wieder ,,hinten durch die Brust ins Auge" greifen - mit zum Teil gravierenden Konsequenzen für die allgemeine Verständlichkeit.

Der größte Beitrag zur unnötigen Komplexität der Living-Worlds-Bibliothek ist aber eindeutig Regel 1). Die gemeinsame Gestaltbarkeit eines virtuellen Raumes ist nicht ein Oberflächenaspekt wie Farbe, sondern ein Grundsatzcharakter wie die Geometrie. Die Interaktion mit Gruppen von anderen Teilnehmern in persistent zu verändernden Umgebungen mit VRML97-Mitteln zu beschreiben, hat gewisse Ähnlichkeit mit der Beschreibung von 3D-Modellen in Postscript (eine Anologie, die uns bald weiter beschäftigen wird). Der Leser der Living-Worlds-Codebibliothek kommt sich etwa so vor, wie einer, der aus den 2D-Vektoren und Bitmaps eines Postscript-Perspektivbildes die dahinterliegende 3D-Topologie erkennen soll.


Die MUtech ist nämlich nur ein Trick, mit dem mehrere Clients dazugebracht werden sollen, sich in etwa komplementär zu verhalten, ohne eigentlich zu wissen, was sie tun. Nicht einmal die MUtech weiß, wie es um ihre Clients bestellt ist. Sie horcht lediglich bei jedem mit, und reicht diejenigen Ereignisse weiter, die ihr mitgeteilt werden. Auf jedem Client werden dann ganz normale VRML97-Datenflüsse erzeugt, d.h. eine Animation wird fingiert, die so aussieht, wie die lokale Sicht einer verteilten Handlung - eben ein Perspektivbild. Es bleibt einem nichts anderes übrig, wenn das lokale System das Netz lediglich als eine Quelle öffentlicher Dateien kennt - wenn es nicht weiß, das es außerhalb seines eigenen RAMs irgendetwas anderes gibt, daß entscheidet, das Ereignisse initiiert, oder dem man vielleicht sogar kommunizieren kann.


Es ist wichtig, in jeder WG damit anzufangen, die Möglilchkeiten der VRML97-Spracherweiterungsmechanismen auszuschöpfen, bevor man mit Vorschlägen für Änderungen am Standard kommt. Bei komplexeren Vorhaben, die inhaltlich wirklich grundsätzlich außerhalb der Semantik von VRML97 liegen, ist der Preis für diese Disziplin eine z.T. skurrile Code-Struktur, mit der die Durchführbarkeit des Vorhabens ungerecht in Frage gestellt wird.


Schlimmer noch: Es sieht zunehmend danach aus, als ob die Sanierung der VRML-Spracharchitektur, die notwendig wäre, um sie zu einer GevU-Sprache auszubauen, nicht mehr (auf alle Fälle nicht bald) unternommen wird.


Überraschung: Cyberspace paßt nicht ins 3D-Geschäft

Der Schritt zur ISO-Standardisierung von VRML97 heißt, daß das rasante Tempo der Sprachentwicklung jetzt schlagartig gebremst wird. Einige sprechen sogar davon, daß VRML jetzt schon komplett sei. Eine Version 3.0 sei unnötig, denn mit ExternProtos könne man alles hinzufügen, was man an Erweiterungen für nötig halte. Und schließlich will man nicht die Millionen entwerten (egal ob Dollar, DM oder Pfund), die man in VRML97-Anwendungen schon investiert hat (oder demnächst haben wird), nur um einige Syntaxverbesserungen einzuführen ...


... womit wir (endlich) wieder bei einem Thema gelandet sind, das seit langem darauf wartet, wieder aufgenommen zu werden. Wir haben nämlich im Kapitel 1 versprochen, mehr auf das komplexe Spannungsfeld einzugehen, in dem die Weiterentwicklung von VRML stattfindet. Diese Spannung zeigt sich vor allem als ein Dauerkonflikt zwischen


Dieser inhärente Konflikt zwischen Demokratie und Expertise wird durch einen zweiten Konflikt überlagert, in dem es um die angemessenen Rollen von Individuen und Großkonzernen in der Bestimmung gemeinschaftlicher Prozesse geht. Dies zeigt sich als immer wieder gestellte Frage über die Vertrauenswürdigkeit von Botschaften, die aus Redmond eintreffen - also, ob man Microsoft über den Weg trauen darf.


Faktisch ist es aber nicht Microsoft, sondern Silicon Graphics, die die Entwicklung von VRML von Anfang an maßgeblich beeinflußt hat. Der Einfluß war in den meisten Fällen nicht firmenpolitisch, sondern die persönliche Überzeugung einzelner Personen: vor allem Rikk Carey, Gavin Bell und Chris Marrin. Ihre hohe Professionalität im 3D-Bereich war immer wieder entscheidend. Es ist ihnen zu verdanken, daß VRML wohl der 3D-Standard im Netz sein wird.


Ihnen ist auch zu verdanken, daß die 3D-Themen immer den Vorrang hatten, während die Schnittstellen zur GevU-Realisierung verschoben wurden. Das erste Ergebnis der Living-Worlds-WG zeigt, wie maßgeblich die Auswirkung dieser Prioritätensetzung gewesen ist. Die Living-Worlds-WG hat konsequent versucht, möglichst alle GevU-Autorenschnittstellen in VRML97 zu definieren. Das Ergebnis ist fast unbrauchbar: eine undurchschaubare Komplexität, bedingt dadurch, daß nahezu alles, was man an Semantik zur Spezifikation einer GevU braucht, im VRML fehlt. Ein Einbenutzer-Autorensystem ist einfach eine denkbar ungeeignete Plattform für eine gemeinsam zu gestaltende Simulation.


VRML97 baut ganz konsequent auf die konzeptionelle Trennung zwischen Authoring und Viewing, also zwischen der Konzeption und Implementierung einer Szene/Seite einerseits und dem Abspielen des Implementierten auf dem Bildschirm/Drucker andererseits. In kollaborativen Anwendungen, bei denen jeder Besucher ein potentieller Co-Autor ist, ist diese Trennung nicht nur nebensächlich, sondern irreführend.


Dieses Problem wird nicht durch die Art von Interaktivität gelöst, wie sie z.B. durch die Einführung dynamischer Bindung erreicht werden könnte (obwohl dieses für eine flexible Gruppenanwendung eine wichtige Voraussetzung bleibt). Das schnelle Prototyping bleibt konzeptionell immer ein Wechselbad zwichen ,,Autorenmodus" und ,,Ablaufmodus". In einer wirklich kollaborativen Umgebung geht es aber genau darum, die Autorentätigkeit als Kategorie, als etwas, was außerhalb der Szene passiert, verschwinden zu lassen - oder genauer, mit den Tätigkeiten des ganz normalen Surfers zu verschmelzen.


VRML97: für die GevU-Semantik ungeeignet

Wenn jeder, der mitmacht, auch Teile der Szene beisteuert bzw. Teile der Aktion bestimmt (vgl. Bernds Brettspiel) und diese Beiträge jederzeit durch andere Beiträge über einen Haufen geworfen werden können (vgl. Claras Kanarienvogel) - dann ist eine Anwendung nicht mehr nur ein Satz vorgeschriebener Abläufe und auch nicht eimal ein frei durchwanderbar, aber eben doch vorgefertigter Raum mit festgelegten Animationen. Die Essenz der neuen kollaborativen Anwendungen liegt in den Regeln, nach denen Komponenten, die sich zeitweilig dazugesellen, sich andauernd miteinander abstimmen.


Für diese Essenz ist VRML genauso ungerüstet wie Postscript für 3D. Natürlich ist es möglich, solche Anwendungen in VRML zu schreiben - man kann auch den Gang durch einen 3D-Raum in Postscript beschreiben. Da jedoch Postscript keine 3D-Begriffe kennt, muß man alles zunächst auf eine 2D-Fläche projizieren. Ebenso muß man sämtliche Multiuser-Semantik - all das, was Cyberspace ausmacht und VRML nicht kennt - irgendwie an VRMLs Darstellungssemantik projizieren: Routes statt Messages usw.


Selbstverständlich ist alles noch möglich. Die VRML97-Erweiterungsmechanismen bieten ein offenes Mittel, neue Schnittstellen zu definieren. Living Worlds ist entsprechend vorgegangen. Das ist aber nicht der Punkt. Neue Sprachen werden erfunden, um für spezifische Problembereiche geeignete Beschreibungsmittel zu haben - um Arrays nicht als Listen, Vektoren nicht als Pixel und Kegel nicht als IndexedFaceSets behandeln zu müssen. Cyberspace braucht eine Entwicklungssprache, in der man dynamische Fakten und Prozesse wie Gruppenzugehörigkeit und Privilegienvergabe, oder die Reichweite, Dringlichkeit und Umkehrbarkeit einer Zustandsänderung, als die Attribute sichtbarer Gegenstände beschreiben kann. Cyberspace verlangt nach einer Sprache, in der nicht nur Avatare von Bots unterschieden werden können, sondern auch Rechte von Rollen, Einsperren von Aussperren und Inhalte von ihrer Darstellung. VRML ist diese Sprache nicht.


Dennoch bleiben wir der festen Meinung, daß VRML eine absolut fundamentale Aufgabe im Cyberspace haben wird. Deshalb wollen wir abschließend den wirklich phänomenalen Erfolg von VRML würdigen, und eine Vorhersage über seine Zukunft wagen.


Previous PageNext Page