nicht angemeldet
auch: (XSLT). Praktischer Einsatz? Generelles...
Hi ihr,
ziemlich weit unten ist ja ein Thread über XML/XHTML gelandet, ein Leser des Forums hatte vor einigen Tagen ungefähr die Frage gestellt: "Ich frage mich sowieso, warum jetzt alle Welt XML Dokumente ins Web stellen möchte", an die ich mich anschließen möchte.
XML, hört sich ja sehr interessant an, rast ja wie einst Java durch die IT Welt und alle wollem mitmachen. Jetzt hab ich mich mal etwas damit beschäftigt und bin zu folgendem Schluß, bzw. folgenden Fragen gekommen:
-
Um mit XML selbst konkrete Webseiten zu erstellen, braucht man heute noch die Unterstützung von XSLT, die serverseitig das XML-konforme Dokument in HTML übersetzt. Der Vorteil liegt darin, daß man einfach ein anderes Stylesheet nimmt, um das ganze auf WAP cellphone zu bringen. Doch warum sollte ich so etwas tun? Sicher, Trennung von Design und Daten, ist an sich eine feine Sache, aber...
-
Wie kann ich mit XML arbeiten? Es böte sich doch eine Datenbankanbindung (z.B. das freie MySQL) an, doch wie spreche ich diese an? XML selbst bietet sowas ja nicht, ist ja "nur" eine Markup Language, also brauche ich eine weitere Sprache, die das erledigt.
-
Wie sähe die Realisierung aus? PHP, das XML Dokumente erstellt, die dann per XLST nach HTML konvertiert werden? Java? Ich habe etwas von dem XML-Apache gelesen, dazu fallen mir Schlagworte wie "Coocon", "Jakarta" oder "TomCat" ein... wie könnte man sich denn nun konkret einen Software-Backend vorstellen, der folgendes leistet:
a) XML Dokumente mit XLST nach HTML parsen
b) das XML Dokument soll teilweise oder auch ganz aus einer Datenbank zusammegesetzt werden können
- Bei dieser ganzen Aufwand stellt sich mir langsam wirklich die Frage, ob es überhaupt sinnvoll ist, so zu reagieren. Der Hintergrund dieser Fragerei ist der Versuch, ein Portal aufzuziehen, daß integriertes Content-Management für beliebige Benutzergruppen mit sich bringt. Ursprüngliche Idee ist ja PHP/MySQL gewesen, aber XML bietet ja durch die Verwendung von XLST ja gewisse Vorteile (superleichte Änderung des Designs, z.B.).
Nachdem ich mich mit XML beschäftigt habe, muß ich sagen, daß mir die Sprache, bzw. das Programm gut gefällt. Das ganze mittels JSP zu realisieren sollte keinen allzu großen Aufwand bereiten, da Javaprogrammierung nicht das Problem ist. Nachdem ich aber nach konkreten Realisierungsmöglichkeiten gesucht habe und immer weiter in den Sumpf der notwendigen Programme, bzw. auftauchenden Probleme gestolpert bin, frage ich mich (und euch) nun, ob sich das ganze lohnt - wenn das Portal irgendwann fertig ist, ist das Stichwort XML natürlich ein weiteres Zugpferd, daß den Verkauf ankurbeln könnte *g*
<mfg>Sebastian Will</mfg>
-
Hallo Sebastian
herzlich willkommen im Club von http://www.teamone.de/selfaktuell/artikel/inflation.htm! ;-)
Nein, das soll kein Hetz-Thread gegen XML werden. XML ist viel zu schade dazu, um Gegenstand von solchen billigen Gut-Boese-Auseinandersetzungen zu werden. XML ist ein Riesenfortschritt fuer die gesamte EDV, denn endlich wird es moglich, beliebige Daten mit Hilfe eines einheitlichen und gegen DTD pruefbaren Schemas zu speichern. Das wird auch noch gewaltige Konsequenzen haben. Die ganzen alten Dateiformate werden verschwinden, egal ob Word, Corel oder sonstwas. Wird alles XML frueher oder spaeter.
XML hat den Vorteil, Tag-Sprachen fuer beliebige Zwecke zu definieren. Damit sind wir beim Thema "Zweckmaessigkeit". Welche Tag-Sprache ist wohl am zweckmaessigsten, wenn man normalen Hypertext machen will? Richtig, die Hypertext Markup Language. Dafuer ist sie schliesslich gedacht, und es spricht eigentlich nichts dagegen, sie dafuer auch weiterhin zu benutzen. Denn mit XML kann man ja auch nix anderes machen, als sich irgendwelche konkreten Tag-Sprachen, also "Dokumentvorlagen" zu basteln. Keine Tag-Sprache kann alles abdecken, aber man kann auch nicht fuer jedes Dokument eine neue erfinden. Also benutzt man fuer normale Zwecke wie normale Webseiten bewaehrte, allgemein und public definierte solcher Sprachen. Und HTML ist eben so eine.
Derzeit versuchen halt wieder mal alle moeglichen Gschaftlhuber (bayerischer Ausdruck ;-), mit Kanonen auf Spatzen zu schiessen. Die wollen dann eine Aufzaehlungsliste mit 10 Punkten im Web darstellen und brauchen dazu einen XML-XSL-Overhead von einem viertel Jahr Entwicklungszeit. Obwohl die DTD dann hinterher fuer sonst gar nix mehr benoetigt wird und das tolle XSLT-Sheet wieder nix anderes erzeugt als popeliges HTML. So was nennt man hierzulande "professionell".
Es gibt aber auch im Web durchaus sinnvolle Anwendungsmoeglichkeiten fuer XML. Eigentlich immer, wenn man individuelle Datenstrukturen hat. Zum Beispiel so eine Forumsmessage. Die besteht aus typischen Elementen, fuer die HTML keine typischen Befehle kennt. Da macht es durchaus Sinn, XML zu benutzen. Denn so hat man die Daten fein saeuberlich in semantisch optimalem Markup und hat dann immer noch alle Optionen offen, wie und in welcher Form man diese Daten anschliessend praesentiert. (um Fragen zuvorzukommen: ja, das kuenftige SELF-Forum wird auf XML basieren ;-)
viele Gruesse
Stefan Muenz-
Hi Stefan,
Es gibt aber auch im Web durchaus sinnvolle Anwendungsmoeglichkeiten fuer XML.
Das sehe ich eigentlich genauso, aber wie würde man jetzt und heute ein Projekt auf XML/XSLT Basis realisieren? Was ich oft im Zusammenhang mit XML gehört habe, ist der Einsatz von Java, sei es als JSPs oder EJBs (O-Ton Marketing: "The power of Java combined with XML defines YOUR success", *g*). Wie wird das neue SelfForum von der technischen Seite aus gesehen realisiert sein?
<mfg>Sebastian Will</mfg>
<ps>Nochmals - nein eigentlich: Erstmals von mir - ein besonders Danke für dieses Forum. Es ist für mich immer die erste Anlaufstelle, wenn ich schnelle Hilfe auf hohem Niveau benötige.</ps>
-
Hi,
Es gibt aber auch im Web durchaus sinnvolle Anwendungsmoeglichkeiten fuer XML.
Das sehe ich eigentlich genauso, aber wie würde man
jetzt und heute ein Projekt auf XML/XSLT
Basis realisieren?ALso um mal einen anderen Aspekt reinzubringen: Fuer
die Speicherung von Datenstrukturen ist XML richtig super.
So benutz ich seit einiger Zeit fuer die Abspeicherung von
Daten fuer meine CGI-Skripte nur noch CGI.
Dies vor allen Dingen deswegen, weil ich nur noch ein
Zugriffsmodul hab und damit alles abhacken kann was
sonst zu Porblemen fuehren kann:
Filelocking, Keywordsuche, Plattformunabhaengigkeit.Stefan hat schon ein sehr gutes Beispiel gebracht, naemlich den eines Forums.
genau sowas hab ich mit Hilfe von XML-Datenstrukturen
schon gemacht. Dort sieht dann die DB fuer mein Forum so aus:<message id=1>
<titel>Hallo Leute</titel>
<autor>Wolfgang Wiese</autor>
<text>blablanbla</text>
<date name="creation" value="19.8.2000">
<date name="last access" value="20.8.2000">
<accesses>214</accesses>
<son>2</son>
</message>
<message id=2>
...
</message>Der Vorteil ist das ich damit ein Standard fuer meine DB's
hab, der mir nichts kostet, der keine eigenen Datenbanken
benoetigt aber trotzdem von einem 'billigen' Skript
sowohl unter Unix als auch unter Win genutzt werden kann.Ausserdem kann ich optional meine Datensaetze selbst
lesbar mnachen, so dass bei obigen Beispiel eines
Forums Leute ihre eigen DTD machen koennten
und die File lesen koennen ohne extra mein Forumsskript
aufrufen zu muessen.Ciao,
Wolfgang-
Hi Wolfgang,
vielleicht hab ich mich mißverständlich ausgedrückt: Mir ist schon klar, wo die Vorteile liegen, wie man ein XML Dokument definiert etc. Mir ist aber eher die technische Seite wichtig - nicht die programmiertechnische, sondern die Realität... mh, wie sag ich's?
Du benutzt ein Modul/Skript, um die XML-Sachen zu parsen, die Ausgabe selbst generierst du wieder in Perl, richtig? Das ist also ein Ansatz... ich möchte gerne wissen, was ich im Hintergrund für Plugins/Module/wasauchimmer benötige, wenn ein Besucher auf ein XML Dokument trifft, in seinem Browser aber ein sauber designtes Stück HTML haben soll, also: Der Server soll das XML Dok. erkennen, es mittels XSLT parsen und dem Browser schicken. Welche Lösungsansätze existieren da? Ich möchte es eigentlich vermeiden, das XML Dokument selbst zu parsen, wenn es diese Funktionalität doch schon mit dem XSL-"Standard" gibt.
Soweit ich das bis jetzt verstanden habe, gibt es bei Apache den Ansatz über Coocon/TomCat, wobei letzteres für die Bereitstellung der Servlets und ersteres für das processing der XML/XSLT Dokumente verantwortlich sind. Leider habe ich hier auf dem Rechner kein Linux, aber selbst wenn, würde das wieder ewig dauern, bis ich alles richtig zusammenkompiliert habe, unter Windows fehlt mir der Compiler :( Mich würde einfach interessieren, inwieweit diese Technik schon für den Praxiseinsatz tauglich ist, bzw. wieviel Aufwand man benötigt, um etwas darauf zu machen.
<mfg>Sebastian Will</mfg>
-
Hallo
Coccon läuft auch unter dem Personal Webserver der bei Windows mit dabei ist. Und Du brauchst weder bei Tomcat noch bei Cocoon irgendwas zu kompilieren. Das einnzige was Du brauchst, ist eine Java Laufzeitumgebung. Die Installation ist einfach und auch gut beschrieben. Die Dokumentation zeigt darüber hinaus die Einsatzmöglichkeiten aus (sehr) technischer Blickwinkel.
Gruß
Michael
-
-
-
-
Hallo Stefan,
<<Die ganzen alten Dateiformate werden verschwinden, egal ob Word, Corel oder sonstwas. Wird alles XML frueher oder spaeter.>>
Nehmen wir mal als Beispiel die Wavelet Kompression - einen extrem komplizierten Algorithmus aus dem Bereich Graphics File Formats. Wie soll sowas denn in XML umgesetzt werden, ohne das Übertragungsvolumen ins Unermessliche zu steigern?
Bin nur neugierig
Uwe
-
Hallo Uwe!
Nehmen wir mal als Beispiel die Wavelet Kompression - einen extrem komplizierten Algorithmus aus dem Bereich Graphics File Formats. Wie soll sowas denn in XML umgesetzt werden, ohne das Übertragungsvolumen ins Unermessliche zu steigern?
Bin nur neugierig
Svalable Vector Graphic
Grüße
Thomas-
Hi Thomas,
Scalable Vector Graphics sind doch auch nur ein weiteres Dateiformat, in diesem Fall halt ein grafisches. Das du damit Kompressionsraten wie z.B. beim Wavelet Verfahren (das uebrigens nicht nur im Grafikbereich eingesetzt wird) realisieren kannst, wage ich zu bezweifeln.
Stefan sagte, dass alle alten Dateiformate verschwinden. Sorry, aber das ist schwer vorstellbar. Er meinte wohl nur bestimmte Grafik- und Textformate, die durch WWW taugliche ersetzt werden.
Viele Gruesse
Uwe
-
Hallo Uwe!
Scalable Vector Graphics sind doch auch nur ein weiteres Dateiformat, in diesem Fall halt ein grafisches. Das du damit Kompressionsraten wie z.B. beim Wavelet Verfahren (das uebrigens nicht nur im Grafikbereich eingesetzt wird) realisieren kannst, wage ich zu bezweifeln.
Wenn es nur um kompression geht: was läßt sich besser komprimieren: Bilder oder ASCII Text?
Grüße
Thomas
-
-
-
-
-
Hallo Sebastian!
Es gab weiter unten auch ein anderer Thread, wo ich mal zur konkreten Anwedung von xml was sagte.
»»Der Hintergrund dieser Fragerei ist der Versuch, ein Portal aufzuziehen, daß integriertes Content-Management für beliebige Benutzergruppen mit sich bringt.
Ich kann dir nur paar Links geben:
http://www.gauss-interprise.com/en/index.htmNachdem ich mich mit XML beschäftigt habe, muß ich sagen, daß mir die Sprache, bzw. das Programm gut gefällt. Das ganze mittels JSP zu realisieren sollte keinen allzu großen Aufwand bereiten, da Javaprogrammierung nicht das Problem ist. Nachdem ich aber nach konkreten Realisierungsmöglichkeiten gesucht habe und immer weiter in den Sumpf der notwendigen Programme, bzw. auftauchenden Probleme gestolpert bin, frage ich mich (und euch) nun, ob sich das ganze lohnt - wenn das Portal irgendwann fertig ist, ist das Stichwort XML natürlich ein weiteres Zugpferd, daß den Verkauf ankurbeln könnte *g*
Tja, dann müsst ihr ein fertiges Produkt kaufen:
xsm-server:
http://www.softwareag.com/tamino/
http://www.exceloncorp.com/und richtig gut zum "stöbern":
http://www.xml.com/pubGrüße
Thomas -
Hi,
noch ein link zur praktischen Anwendung von xml:
http://www.heise.de/ix/artikel/2000/09/166/
Gruss,
Armin