nicht angemeldet
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/Transform
Also 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-xsl
90% 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 Syntax
Also: 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