20.01.2013 Aufrufe

XML » SVG Presenter - Carto:net

XML » SVG Presenter - Carto:net

XML » SVG Presenter - Carto:net

MEHR ANZEIGEN
WENIGER ANZEIGEN

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.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!