XML » SVG Presenter - Carto:net
XML » SVG Presenter - Carto:net
XML » SVG Presenter - Carto:net
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>XML</strong> <strong>»</strong> <strong>SVG</strong> PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 109<br />
der Granularität der Benutzer-Kontrolle 1 ist an dieser Stelle insbesondere der Aspekt der fehlenden Texteigenschaft<br />
des Formates relevant. Da Flash-Textinhalte im Rahmen von SWF nicht nur „recht umständlich“<br />
[Katz00] implementiert, 2 sondern überdies auch binär komprimiert werden, können semantische Inhalte<br />
Flash-basierter Präsentationen somit derzeit weder von Suchmaschinen indiziert, noch von einem Mensch<br />
gelesen werden. Die Lizenzvereinbarung des Macromedia-Konzerns geht sogar noch einen Schritt weiter:<br />
Demzufolge ist es verboten, Flash-Software „in irgend einer Weise zu dekompilieren oder in eine menschenlesbare<br />
Form zu überführen“. 3<br />
4.5.5.3 Flash versus Lesbarkeit<br />
Nicht nur dieser „erschütternde Wortlaut“ [vgl. Cagl01], sondern insbesondere die dahinter stehende<br />
Grundhaltung Macromedias macht an dieser Stelle deutlich, dass das Unternehmen trotz offen gelegter<br />
SWF-Interna [vgl. Macr98,02b] und des (mittlerweile eingestellten) SDKs keineswegs primär um Offenheit<br />
und Transparenz bemüht ist, (erkennbar auch an den fehlenden Bemühungen um eine Standardisierung<br />
des Formates), 4 sondern das Flash-Format vielmehr immer noch eine in erster Linie „proprietäre“ [vgl. Abbe00,<br />
Doug01] und „geschlossene“ [Arty02] Dateistruktur repräsentiert.<br />
Die nähere Betrachtung der SWF-Architektur [s.4.5.3.1] legt überdies weitere Schwächen des Formates offen:<br />
Neben der recht problematischen „Frame-Fragmentierung“ und der hiermit verbundenen Schwierigkeiten<br />
bezüglich Rekonstruktion der Animationszusammenhänge und dem erschwerten Parsing der SWF-<br />
Dateien [s.4.5.3.3.3] erscheint überdies die unstrukturierte und willkürliche Ordnung von Objektdefinitionen<br />
und Kontrollanweisungen innerhalb der Flashdatei zumindest „strukturell fragwürdig“. Das eigentliche<br />
Hauptproblem des Formates besteht jedoch letztendlich in der maßgeblich durch die geschlossene Binärstruktur<br />
des Formates gekennzeich<strong>net</strong>en, mangelnden Web-Fähigkeit Flashs, welche das in Grundzügen<br />
funktionell überaus interessante SWF-Format schlussendlich für einen Einsatz im Rahmen Web-basierter<br />
Präsentationen ungeeig<strong>net</strong> erscheinen lassen: So stehen das strikt animationsbasierte Präsentationsmodell<br />
Flashs sowie zweifelhafte Usability-Eigenschaften [vgl. Niel00] des Formates letztendlich unseren eingangs<br />
formulierten Anforderungen [s.Kap.1] bezüglich Web-Fähigkeit (und hier speziell der Anspruch einer auch<br />
konsequent webgemäßen Lösung) sowie dem eher auf dem Dexter-Modell beruhenden [s.2.2], konventionellen<br />
Präsentationsprinzip entgegen.<br />
Insbesondere die zahlreichen, bereits existierenden Ansätze, das „geschlossene“ SWF-Format in eine menschenlesbare<br />
Form zu überführen, weisen an dieser Stelle jedoch einen möglichen Ausweg aus diesem „Dilemma“:<br />
So ermöglichen nicht nur unzählige 3rd-Party-Frameworks [KuCu02, Dabb01, Main00, Wana02]<br />
schon jetzt die beidseitige Konvertierung Flash-basierter Binärdaten in das strukturierte, textbasierte<br />
<strong>XML</strong>-Format – auch die Konzentration der MX-Generation des Flash-Autorenwerkzeugs auf <strong>XML</strong>-<br />
Funktionalität [vgl. Cham02] machen insbesondere die offensichtliche Notwendigkeit deutlich, präsentationsbezogene<br />
Informationen neben einer binären, stark komprimierten Variante überdies in einer logisch<br />
strukturierten, textbasierten Form hinterlegen und somit sowohl für Menschen als auch für Inter<strong>net</strong>-<br />
Suchmaschinen besser durchsuchbar machen zu können. An dieser Stelle drängt sich freilich der unter anderem<br />
hierfür konzipierte <strong>XML</strong>-Standard zur Lösung dieses Konfliktes geradezu logischerweise auf.<br />
1<br />
Für einzelne Teil-Seiten oder –Bereiche der Anwendung lässt sich, im Gegensatz zu Html, keine separate URL angeben (zweifelhafte<br />
„Notlösung“: Pseudo- URLs mit „Einstiegs-Pointern“)<br />
2<br />
“[Flash’s] text handling, by being user-agent-neutral, requires the programmer to jump through hoops...” [Katz00]<br />
3<br />
frei übersetzt aus der Flash-Lizenzvereinbarung Macromedias (Abschnitt 2 (b) VI.)<br />
http://www.macromedia.com/support/shockwave/info/licensing/license.html [12.2.03]<br />
4<br />
vgl. [Cagl02] pp.10ff.