nicht angemeldet
Version des XML Parsers ermitteln
Hallo an alle.
Ich schlage mich jetzt schon einige Zeit mit einem Problem herum und möchte hier um Hilfe bitten.
Angefangen hat alles mit dem Wunsch nach XML/XSL. Klappte auch ganz gut (Dank an den XML/XSL Autor) und wird für die Navigation eingesetzt. Aber dann: w3C ändert den Namespace! Also Namespace anpassen und: es läuft noch bei mir (hab ja auch .net ß), aber sonst auf (fast) keinem Rechner. Problem soll sein, das der neue Namespace nicht von alten xml-Parsern unterstützt wird! (Kann das jemand bestätigen?)
Also: Alternative Seiten, je nach Version des Parsers (Client-Seitiges parsen!)
Aber:
Wie stellt man das Vorhandensein des Parsers und seine Version fest? (Wenn ich mich nicht täusche könnte man auch allgemein nach ActiveX Controlls fragen)
Oder hat jemand eine alternative Lösung? (In jedem Fall aber auf Basis XML/XSL und parsen beim Client)
Auf meiner Homepage habe ich das mit dem alten Namespace eingesetzt. Der Source ist da auch zu finden. (Die Homepage ist spielerei und sollte nicht ernst genommen werden!)
Vielen Dank für das Interesse an meinem Problem!
mfg
Dirk
-
Hallo,
Aber dann: w3C ändert den Namespace!
Wann denn das!
Das W3C hat den Namensraum für XSLT in der Empfehlung vom 16. November 1999 festgelegt und seitdem nie mehr geändert. Er lautet: http://www.w3.org/1999/XSL/TransformAlso Namespace anpassen und: es läuft noch bei mir (hab ja auch .net ß), aber sonst auf (fast) keinem Rechner.
Häh? Ich nix verstehen.... ;-)
Microsoft hat mit dem IE einen XSLT-Prozessor ausgeliefert, der einen alten Arbeitsentwurf (in MS-weise ;-)) von XSLT unterstützt. Der Namensraum den MS verwendet ist:
http://www.w3.org/TR/WD-xsl90% der Weltbevölkerung nützt es deswegen nix, wenn Sie auf Ihrem Client korrektes XSLT mit der korrekten Namensraumangabe bekommen. Daher ist die einzig praktikable Lösung (auch wenn der IE 6 den neuen Namensraum unterstützt und man den IE 5 updaten kann, dass erst auch tut) die XSLT-Transformation auf dem Server auszuführen und HTML zu erzeugen.
Genaueres zu allen diesen Problemchen gibts hier (leider nur auf englisch, aber dafür erschöpfend behandelt):
http://www.netcrucible.com/xslt/msxml-faq.htm»»Problem soll sein, das der neue Namespace nicht von alten xml-Parsern unterstützt wird! (Kann das jemand bestätigen?)
Ja, s.o.
Nicht nur der Namensraum wird nicht unterstützt, sondern es handelt sich um eine komplett andere SyntaxAlso: Alternative Seiten, je nach Version des Parsers (Client-Seitiges parsen!)
Nein, serverseitig transformieren und HTML an den Browser schicken.
Wie stellt man das Vorhandensein des Parsers und seine Version fest? (Wenn ich mich nicht täusche könnte man auch allgemein nach ActiveX Controlls fragen)
Da musst Du mal bei MS schauen. Du musst dann abfragen, ob dein User die 3-er-Version des MSXML-Parsers unterstützt. Steht auch sicher in der Doku zu dem Parser.
Oder hat jemand eine alternative Lösung? (In jedem Fall aber auf Basis XML/XSL und parsen beim Client)
Clientseitig ist sicher die einzige Möglichkeit, aber besonders praktikabel ist sie nicht, zumal dunicht allzuviel mit der alten Syntax machen kannst.
Gruß
Franz-
Hi Franz?
90% der Weltbevölkerung ...
_So_ viele Benutzer haben den M$ IE 5.0 gekauft???
Wenn ich das geahnt hätte, hätte ich wohl doch Billys Aktien kaufen müssen ... ;-)
Viele Grüße
Michael-
Grüssi,
90% der Weltbevölkerung ...
_So_ viele Benutzer haben den M$ IE 5.0 gekauft???
Wenn ich das geahnt hätte, hätte ich wohl doch Billys Aktien kaufen müssen ... ;-)
Wenn du da jetzt erst drauf kommst - was hast du das letzte Jahrzehnt so getrieben? ;-) Wenn schon nicht 90% der Welt den IE haben, dann haben sich zumindest ebensoviele Leute in den A... gebissen, dass sie keine Billy-Aktien gekauft haben *g*
lg regenfeld
-
Hi regenfeld,
90% der Weltbevölkerung ...
_So_ viele Benutzer haben den M$ IE 5.0 gekauft???
Wenn ich das geahnt hätte, hätte ich wohl doch Billys Aktien kaufen müssen ... ;-)
Wenn schon nicht 90% der Welt den IE habenich wußte nicht, daß schon 90% der Weltbevölkerung einen PC besitzen sollen.
Angesichts der finanziellen Voraussetzungen in den bevölkerungsreicheren Teilen dieser Welt würde mich das auch ziemlich überraschen.Viele Grüße
Michael-
Hallo Michael,
Angesichts der finanziellen Voraussetzungen in den bevölkerungsreicheren Teilen dieser Welt würde mich das auch ziemlich überraschen.
Unterschätz den Billy nicht ein zweites Mal! Der verschenkt seine PCs bereits an die noch nicht infizierten Teile der Welt (mit vorinstalliertem Windows und IE natürlich) und verkauft das dann als Entwicklungshilfe bzw. Aufklärung.
Also, überlegs Dir nochmal mit den Aktien. Kann nicht mehr lange dauern bis die 90% keine Propaganda-Statistik mehr darstellt. ;-)
Gruß
Franz-
Hi Franz,
Unterschätz den Billy nicht ein zweites Mal! Der verschenkt seine
PCs bereits an die noch nicht infizierten Teile der Welt (mit
vorinstalliertem Windows und IE natürlich) und verkauft das dann
als Entwicklungshilfe bzw. Aufklärung.Haben denn 90% der Weltbevölkerung überhaupt schon Stromversorgung?
Viele Grüße
Michael-
Hi Michael,
Haben denn 90% der Weltbevölkerung überhaupt schon Stromversorgung?
Billy regelt das. Habe Vertrauen!
Schönen Sonntag noch
Franz
-
-
-
-
-
-
-
Angefangen hat alles mit dem Wunsch nach XML/XSL. Klappte auch ganz gut (Dank an den XML/XSL Autor)
XML und XSLT haben sehr viele Väter. Falls du dich auf ein Buch beziehst, würde ich mir das Lob nochmal überlegen. Ein gutes XSLT-Buch wird z.B. das demnächst auf Deutsch erscheinende "XSLT - Mastering XML Transformations" aus dem Hause O'Reilly sein.
und wird für die Navigation eingesetzt. Aber dann: w3C ändert den Namespace!
Das tut das W3C nicht, das kann das W3C auch nicht so ohne weiteres.
Also Namespace anpassen und: es läuft noch bei mir (hab ja auch .net ß), aber sonst auf (fast) keinem Rechner. Problem soll sein, das der neue Namespace nicht von alten xml-Parsern unterstützt wird! (Kann das jemand bestätigen?)
Ich möchte fast wetten, irgendjemand hat dich auf die dumme Idee gebracht, den Internet Explorer mit einem XML-Dokument zu füttern, dass sich auf eine XSLT-Vorlage bezieht, die das Dokument transformieren soll. Nun bist du aber zum einen mit einem MSXML 2.x-System konfrontiert, dass XSLT 1.0 überhaupt nicht implementiert und einem MSXML 3.x-System, dass XSLT 1.0 beherrscht.
Also: Alternative Seiten, je nach Version des Parsers (Client-Seitiges parsen!)
Ha, vergiss es. Ich würde an deiner Stelle Webbrowser mit Webseiten füttern. Webseiten werden in XHTML geschrieben.
Wie stellt man das Vorhandensein des Parsers und seine Version fest? (Wenn ich mich nicht täusche könnte man auch allgemein nach ActiveX Controlls fragen)
Das geht nicht. Du täuschst dich.
Oder hat jemand eine alternative Lösung? (In jedem Fall aber auf Basis XML/XSL und parsen beim Client)
Du willst den Client verarbeiten lassen, analysieren (parsen) ist was anderes. Die Idee, den Client das machen zu lassen ist keine gute, lass es einfach und du hast keinen Ärger.
Auf meiner Homepage habe ich das mit dem alten Namespace eingesetzt.
Was weiss ich, wo sich deine Homepage finden lässt. Wenn es http://www.pegasusprivate.de/ sein soll, besteht die nur aus einem Haufen Frames mit dem Inhalt: Ein Werbebanner.
-
Hallo Björn
Vielen Dank für die Hunweise. MIt dem Namespace habe ich aufgrund deiner und der anderen mails jetzt halbwegs verstanden. Insbesondere, daß es wohl keine gute Lösung gibt.
Ha, vergiss es. Ich würde an deiner Stelle Webbrowser mit Webseiten füttern. Webseiten werden in XHTML geschrieben.
Guter Hinweis, da ich xhtml noch nicht kenne. Ziel war es, wie es ja xml xsl machen, Inhalt und Darstellung strikt zu trennen und das xml als Inhalt auch weiter, z.B. für Übersetzungen oder DTP, zu verwenden. Geht das in xhtml ähnlich? Ich habe hier mal angefangen die Informationen zu xhtml zu lesen, habe aber (noch) nicht einen solchen Hinweis gefunden.
Was weiss ich, wo sich deine Homepage finden lässt. Wenn es http://www.pegasusprivate.de/ sein soll, besteht die nur aus einem Haufen Frames mit dem Inhalt: Ein Werbebanner.
Wie gesagt ist die HP mehr ein Speilzeug für mich gewesen. Aber etwas Inhalt sollte schon kommen oder? Das Werbebanner kommt von meinem (dafür Gratis) HP-Anbieter, der zu meiner HP bei arcor weiterleiten sollte.
mfg
Dirk
-
-
Also: Alternative Seiten, je nach Version des Parsers (Client-Seitiges parsen!)
Ich erinnere mich noch zu gut an folgenden Satz:
"Client-side XSL is considered harmful"Einer der vielen "harmful"-Sätze, die die Computerwelt hervorgebracht hat, aber anscheinend nicht ganz von der Hand zu weisen. Wenngleich diese Bemerkung wohl aus anderen Gründen entstanden ist, so frage ich dich doch, was du machst, wenn der Browser zwar XML versteht, aber mit XSL garnicht umgehen kann. Opera z.B. kann XML+CSS, und das ist auch gut so, aber alles andere läuft ins Leere.
Warum nicht dort die Transformation ansetzen, wo man nicht tausende Programme beachten muß, sondern nur eines: Auf dem Server?
- Sven Rautenberg
-
Warum nicht dort die Transformation ansetzen, wo man nicht tausende Programme beachten muß, sondern nur eines: Auf dem Server?
- Sven Rautenberg
Hallo Sven
Wir hatten uns halt überlegt den Server zu entlasten und die Clients arbeiten zu lassen. Hälst du das für Quatsch? Das Projekt, das wir damit später machen wollen, könnte etwas größer werden!
mfg
Dirk
-
Hallo Dirk,
du hast zwar Sven gefragt, aber ich mische mich nochmal ein ;-)
Hälst du das für Quatsch? Das Projekt, das wir damit später
machen wollen, könnte etwas größer werden!Quatsch ist vielleicht übertrieben, aber wenn Du nicht sicher sein kannst (z.B. in einem Intranet), dass Deine Clients alle IE mit MSXML 3 haben (im Replace Mode), dann macht Euch das Projekt nur Ärger. Selbst in einem Intranet ist die Aktion des Updatens des IE erstmal zu machen.
Also wenn die Seiten dynamisch sein sollen, dann auf dem Server on the fly wandeln. Da gibts auch Frameworks für z.B. Cocoon vom Apache XML Project (http://xml.apache.org).
Falls es sich um statische Seiten handelt, kannst du auch die Seiten alle mit einem XSLT-Prozessor in HTML-Dateien wandeln und dann als solche publizieren. Lohnt sich natürlich nur, wenn du nicht alle 2 Stunden ein Update brauchst.
Gruß
FranzPS: Damit wir hier nicht nur über den IE reden: Mozilla hat seit einiger Zeit auch einen XSLT-Prozessor integriert (TransforMiix). Aber Opera z.B. verzichtet ganz auf XSLT und beim NS gehts auch nicht.
-
Hallo Franz,
du hast zwar Sven gefragt, aber ich mische mich nochmal ein ;-)
Natürlich habe ich gehofft, dass sich alle an so einem Posting interessierten auch beteiligen (Gibts da so was wie netiquette?)
Quatsch ist vielleicht übertrieben, aber wenn Du nicht sicher sein kannst (z.B. in einem Intranet), dass Deine Clients alle IE mit MSXML 3 haben (im Replace Mode), dann macht Euch das Projekt nur Ärger. Selbst in einem Intranet ist die Aktion des Updatens des IE erstmal zu machen.
Es handelt sich tatsächlich um ein Intranet-Projekt (Sorry, man kann immer erst nachher sagen, was man am Anfang alles hätte schreiben sollen)
Also wenn die Seiten dynamisch sein sollen, dann auf dem Server on the fly wandeln. Da gibts auch Frameworks für z.B. Cocoon vom Apache XML Project (http://xml.apache.org).
Falls es sich um statische Seiten handelt, kannst du auch die Seiten alle mit einem XSLT-Prozessor in HTML-Dateien wandeln und dann als solche publizieren. Lohnt sich natürlich nur, wenn du nicht alle 2 Stunden ein Update brauchst.
NaJa, dynamisch: Ja, alle 2 Stunden: Nein. Eine feste Grenze wird es sicher nicht geben. Also was haben wir vor: Zunächst erzeugen wir eine Art Grundgesetz, das eher statisch ist (alle paar Monate). An das wollen wir weitere Dokumente anhängen. Das soll dezentral (Im Intranet) aber "Just in Time" funktionieren. Bisheriger Plan: Erster Teil in XML (Wir brauchen den Inhalt auch noch an anderer Stelle). An dem sollen dann die eher dynamischen Sachen "hängen". Das XSL muß also auch den Zugriff auf diese Daten ermöglichen! Wenn ich dich recht verstehe sollten also alle Clients ein upgrade bekommen oder wir müssen alles auf dem Server machen.
mfg
Dirk
-
Hallo,
»»Gibts da so was wie netiquette?
nicht dass ich wüsste, war mir schon klar, dass du alle meinst ;-)
Es handelt sich tatsächlich um ein Intranet-Projekt (Sorry, man kann immer erst nachher sagen, was man am Anfang alles hätte schreiben sollen)
na, das ändert die Sache ein wenig
NaJa, dynamisch: Ja, alle 2 Stunden: Nein.
Mit dynamisch meinte ich hauptsächlich, ob du Seiteninhalt in Abhängigkeit von Benutzereingaben erzeugen willst. Also wenn Dein Benutzer z.B. eine personalisierte Seite enthält, mit Namen angesprochen wird usw.
Dann benötigst du sowieso auf dem Server ein Programm, das die Daten irgendwo herholt (DB oder eben XML-Files oder XML-DB). In diesem Fall würde ich dann auch die Transformation auf dem Server laufen lassen.
Ein Problem bei XML sind allerdings Performance-Dinge, aber wenn es sich nicht um große Datenmengen handelt sollte es gehen. Da muss man Testen....Mit dem alle " Stunden, bezog ich mich auf eine dritte Variante, aus XML über XSLT HTML zu erzeugen. Nämlich nicht "on the fly", sondern im Batch-Betrieb sozusagen. Du erzeugst einfach mit einem XSLT-Prozessor aus Deinem XML HTML-Seiten und die legst du dann auf Deinen Web-Server. Unpraktikabel ist diese Lösung aber eben, wenn es dynamische Inhalte gibt ODER die Seiten zwar statisch sind, aber ständig aktualisiert werden müssen.
»»Wenn ich dich recht verstehe sollten also alle Clients ein upgrade bekommen oder wir müssen alles auf dem Server machen.
Bei IE-Nutzung (und Mozilla werdet Ihr wohl nicht nutzen) bedeutet das konkret:
IE 5 und 5.5 benötigen ein Upgrade auf den MSXML Parser Version 3 (Replace Mode)
IE 6 benötigt kein UpgradeAlso nochmal: Ein clientseitiger Einsatz von XSLT ist eigentlich nur zu empfeheln, wenn:
a) Intranet und Nutzung IE garantiert (oder Mozilla)
b) keine dynamischen Inhalte gefordert sindGruß
Franz
-
-
-
Wir hatten uns halt überlegt den Server zu entlasten und die Clients arbeiten zu lassen. Hälst du das für Quatsch? Das Projekt, das wir damit später machen wollen, könnte etwas größer werden!
Ganz generell würde ich mit dem Serverentlasten dann anfangen, wenn es soweit ist. Und definitiv nur bei Sachen, die wirklich jeder Client leisten kann. Also z.B. Formularvorprüfung. Aber selbst da muß der Server nochmal alles nachprüfen, er wird halt nur von unnötigen Doppeltprüfungen verschont.
Mit clientseitigem XSLT machst du dich richtig abhängig von einem bestimmten Browser, der deine Anforderungen erfüllen kann. Oder du baust wieder für alle Browser eigene XSLTs - davon wollten wir doch gerade wegkommen, oder? One file fits all - wenn man mal von Netscape 4 absieht, dann klappt das heutzutage schon ganz gut.
- Sven Rautenberg
-