"SQL3 kann nicht weniger als alles"

[gears]

Vorlesungs-Script: "SQL3 kann nicht weniger als alles".
.NET
usw.
Das sind monolithische Systeme.
Problem: Wenn irgendwann mal IE9 das HTML5 implementiert, dann nur die Hälfte und das schlecht und Teile fehlen und HTML6 kommt nicht in die Pötte.

Also nimmt man sich ein Vorbild an Java: Es gibt einzelne Inseln und jede kann sich eigenständig entwickeln.

Oder W3C selber: xpath, xslt, svg->tinySVG, xforms, css usw. sind eigenständig, und damit handhabbarer. W3c ist ultra-langsam. Aber in xslt2 sind wenigstens viele Sachen drin, die in xslt1 auch schon reingehört hätten, und einem voll auf den Keks gehen, weil man sich die finger wund-"schreibt" (bei xml completed man 90% des Codes. Das sieht viel viel mehr aus, als man wirklich getippt hat). Doof nur, das IE damals nur XSLT-1 konnte und Opera gar nicht :-(

Von daher sind eigenständige Inseln besser als ein Block den man auf einen Schlag "implementieren" muss.

Und was ist, wenn man es weiterentwickeln will ? Muss man dann 10 Jahre auf HTML6 warten, damit EReader und Graustufen-Displays unterstützt werden ? Oder ist schon festgelegt, das es HTML5.1 HTML5.2 usw. jedes Jahr als Update definitiv geben wird ?

Da sind Inseln mit jeweils eigenständiger Entwicklung trotzdem besser:
HTML5/Storage1.4
HTML5/Video1.2
HTML5/FileSystem1.5
usw.
Dasselbe hätte SQL3 auch gut angestanden. SQL3/Cube SQL3/DataMining SQL3/Statistik SQL3/BLOBs und dann hätte man irgendwann ergänzen können: SQL3/XML oder SQL3/Scriptsprachen . Das geht natürlich nicht mehr. Weil XML-Funktionen dann erst in SQL4 rein kommen ?
"SQL4: Es kann sogar noch mehr als alles. Watch the Movie: Chuck Norris fights SQL4"

[xsosos]

Ja nur das alles was nicht HTML im Namen ist ungern implementiert wurde in den Browsern (SMIL, SVG kommt ja jetzt langsam in die Gänge) davon das sich "Webdesigner" sowas ansehen ganz zu schweigen.

[gears]

Es muss auch einen Vorteil liefern und von wichtigen Sites genutzt werden.

Das zwingt die Browser-Programmierer zu klarerer Modularisierung usw.
Wenn der Standard schlecht ist, hilft das nicht.
Und wenn keiner xslt1 benutzt, wird auch kaum jemand xslt1 implementieren.

Der svg-Standard ist ungünstig definiert. Viele Funktionen sollte und kann man als syntactic sugar betrachten und die anderen Funktionen als Referenz darauf aufbauen.
Dann muss man nur noch wenige Funktionen wirklich implementieren und die anderen sind Macros für die Basisfunktionen.
Z.b. diese 3x2(2x3?)-Matrix für Scheren, Verschieben, Verkleinern, Rotieren implementiert man dann. Verschiebungsfunktion ist nur ein Makro dafür.

Kurzum: Man hat extrem schnell eine Implementierung die läuft.
Dann kriegt man natürlich mit, das die Leute gerne ständig irgendwas rotieren und programmiert es dann mit der Hand. Aber man hat quasi sofort etwas, das den Standard erfüllt. Danach optimiert man Speicher, Geschwindigkeit usw.

Und bei sowas wie Implementierung und Tests usw. könnten Standards hilfreicher sein. Aber erst wenn man lange genug dabei ist, und sieht, wie die sub-level-Coder unter einem dieselben Anfängerfehler und Zeitverschwendungen machen, wie man selber, man selber aber dann verantwortlich für deren meist miese Leistung ist, dann merkt man, was wohl besser wäre... . Geschichte wiederholt sich. Muss sie aber nicht. Wenn man dazulernen würde.

[xsosos]

> Wenn der Standard schlecht ist, hilft das nicht.
> Und wenn keiner xslt1 benutzt, wird auch kaum jemand xslt1 implementieren.

Wie soll man etwas benutzen was nicht Implementiert ist?

> Der svg-Standard ist ungünstig definiert. Viele Funktionen sollte und kann
> man als syntactic sugar betrachten und die anderen Funktionen als Referenz
> darauf aufbauen.
> Dann muss man nur noch wenige Funktionen wirklich implementieren und die
> anderen sind Macros für die Basisfunktionen.
> Z.b. diese 3x2(2x3?)-Matrix für Scheren, Verschieben, Verkleinern, Rotieren
> implementiert man dann. Verschiebungsfunktion ist nur ein Makro dafür.

Ja ist doch eh so:
transform="rotate(90), translate(100,100)"
unterscheidet sich nur Syntaktisch von der Angabe als Matrix
Aufwand zum implementieren = 0;
> Kurzum: Man hat extrem schnell eine Implementierung die läuft.
> Dann kriegt man natürlich mit, das die Leute gerne ständig irgendwas
> rotieren und programmiert es dann mit der Hand. Aber man hat quasi sofort
> etwas, das den Standard erfüllt. Danach optimiert man Speicher,
> Geschwindigkeit usw.
>
> Und bei sowas wie Implementierung und Tests usw. könnten Standards
> hilfreicher sein. Aber erst wenn man lange genug dabei ist, und sieht, wie
> die sub-level-Coder unter einem dieselben Anfängerfehler und
> Zeitverschwendungen machen, wie man selber, man selber aber dann
> verantwortlich für deren meist miese Leistung ist, dann merkt man, was wohl
> besser wäre... . Geschichte wiederholt sich. Muss sie aber nicht. Wenn man
> dazulernen würde.

Das Problem ist das die Browserhersteller von HTML verdorben sind, auch wenn man nur 50% schludrig implementiert irgendwas zeigt es schon an und für den Rest müssen die Webdevs eben Hacks verwenden, bei einem Grafikformat wie SVG geht sowas eben nicht, stell sich einer vor ein Postscript Drucker hat nur 80% Postscriptunterstütztung…

[gears]

xsosos schrieb:
--------------------------------------------------------------------------------
> > Wenn der Standard schlecht ist, hilft das nicht.
> > Und wenn keiner xslt1 benutzt, wird auch kaum jemand xslt1
> implementieren.

> Wie soll man etwas benutzen was nicht Implementiert ist?
Ich hab mich natürlich vertippt und meinte:
Und wenn keiner xslt1 benutzt, wird auch kaum jemand xslt2 implementieren.

Aber die erste Version gilt auch. Weil andere Browser es implementieren, muss man nachziehen. Oder weil man soft rübergehen kann oder eine Weile beides unterstützt, bis genug User gewechselt haben. Die anderen User mit IE6 sind dan arm und eh nicht "die Zielgruppe" für Werbung. Die kriegen "ihr Browser ist dumm"-Werbung oder sowas angezeigt. Die verderben nur die Klickrate und Klick-to-pay-Ratio usw.


> Ja ist doch eh so:
> transform="rotate(90), translate(100,100)"
> unterscheidet sich nur Syntaktisch von der Angabe als Matrix
> Aufwand zum implementieren = 0;

Geh den Standard mal Durch. Dann überleg, Das Du Deinem Chef die Zeit verantwortlich bist, die 100 Funktionen zu coden.
Wenn man jetzt einen pre-converter hätte, der auf xml/xslt-level alle Funktionen dieser Sorte auf die 3x2-Matrix umschreibt, musst Du für die erste Lauffähige Version nur diese 3x2-Matrix-Funktion wirklich coden. Andere Funktionen für andere Dinge muss man natürlich auch coden. Aber pseudo-pascal oder pseudo-c als Referenz der Implementierung würden dabei auch helfen.
Sowas war gemeint.
Man muss den Erst-Aufwand für die Implementierung klein halten. Optimieren kann dann jeder wie er will.


> Das Problem ist das die Browserhersteller von HTML verdorben sind, auch
> wenn man nur 50% schludrig implementiert irgendwas zeigt es schon an und
> für den Rest müssen die Webdevs eben Hacks verwenden, bei einem
> Grafikformat wie SVG geht sowas eben nicht, stell sich einer vor ein
> Postscript Drucker hat nur 80% Postscriptunterstütztung…

SVG ist m.W. nicht wirklich aufwendig, wenn man sowieso schon Linien, Grafiken, Buchstaben usw. auf den Bildschirm "produzieren" kann, weil man z.B. wie opera oder firefox eine Render-Engine für HTML hat. Und TinySVG gibt es auch noch. Damit kann man u.U. anfangen.

Die Probleme bei der Nutzung von SVG sind andere.
Nur ein Beispiel: Da es Koordinaten-Transformation erlaubt (was ich damals in den Beispielen nicht gesehen habe und erst, als ich mal den Standard überflog), kann man die original_Daten nehmen. Z.b. Börsenkurse als xml oder csv und dann ohne viel eigenen Aufwand malen lassen und mit Javascript+DOM halt interagieren lassen. Aber dann könnten die Kunden die Daten als xml "leechen". Also lieber alles in Trash-Flash... .
Anderer Grund: Die Media-"Agenturen" ("Webdesigner") können nur Flash und/oder die Zeichentools dafür sind denen geläufiger.

www. heise.de/ct/schlagseite/04/11/
(und dann auf "größer" klicken) Ich mag urls lieber lesbar. Daher das Space.

Das Beispiel mit Postscript nur 80% implementieren ist gut. Muss ich mir merken.

[xsosos]

> Geh den Standard mal Durch. Dann überleg, Das Du Deinem Chef die Zeit
> verantwortlich bist, die 100 Funktionen zu coden.
> Wenn man jetzt einen pre-converter hätte, der auf xml/xslt-level alle
> Funktionen dieser Sorte auf die 3x2-Matrix umschreibt, musst Du für die
> erste Lauffähige Version nur diese 3x2-Matrix-Funktion wirklich coden.
> Andere Funktionen für andere Dinge muss man natürlich auch coden. Aber
> pseudo-pascal oder pseudo-c als Referenz der Implementierung würden dabei
> auch helfen.
Im Ramen von Amaya gibt es sowas, muss man natürlich erst finden ;-)

>
> SVG ist m.W. nicht wirklich aufwendig, wenn man sowieso schon Linien,
> Grafiken, Buchstaben usw. auf den Bildschirm "produzieren" kann, weil man
> z.B. wie opera oder firefox eine Render-Engine für HTML hat. Und TinySVG
> gibt es auch noch. Damit kann man u.U. anfangen.
>
> Die Probleme bei der Nutzung von SVG sind andere.
> Nur ein Beispiel: Da es Koordinaten-Transformation erlaubt (was ich damals
> in den Beispielen nicht gesehen habe und erst, als ich mal den Standard
> überflog), kann man die original_Daten nehmen. Z.b. Börsenkurse als xml

Ja kannst du und das ist eigentlich eine ziemlich coole Sache
sowas meinist du mit xslt http://de.wikibooks.org/wiki/SVG/_XSLT

Aber zwingen kann dich keiner dazu das du es nicht serverseitig generierst.

Was auch viele vergessen Flash kann man auch "beklauen" der bytecode ist keine Einbahnstraße.
> oder csv und dann ohne viel eigenen Aufwand malen lassen und mit
> Javascript+DOM halt interagieren lassen. Aber dann könnten die Kunden die
> Daten als xml "leechen". Also lieber alles in Trash-Flash... .
> Anderer Grund: Die Media-"Agenturen" ("Webdesigner") können nur Flash
> und/oder die Zeichentools dafür sind denen geläufiger.
>
> www. heise.de/ct/schlagseite/04/11/
> (und dann auf "größer" klicken) Ich mag urls lieber lesbar. Daher das
> Space.

Ja das ist ein Hauptproblem