Firefox 3 no aplica mi hoja de estilo xslt, pero otros navegadores lo hacen

Question

Estoy intentando servir páginas xml generadas dinámicamente desde un servidor web, y proporcionar un xslt personalizado, estático, desde el mismo servidor web, que descargará el procesamiento en el navegador web del cliente.

Hasta hace poco, funcionaba bien en Firefox 2, 3, IE5, 6 y Chrome. Recientemente, sin embargo, algo ha cambiado, y Firefox 3 ahora solo muestra los elementos de texto en la fuente.

La fuente de la página comienza así:

<?xml version="1.0" encoding="UTF-8"?> 
<!-- Firefox 2.0 and Internet Explorer 7 use simplistic feed sniffing to override desired presentation behavior for this feed, and thus we are obliged to insert this comment, a bit of a waste of bandwidth, unfortunately. This should ensure that the following stylesheet processing instruction is honored by these new browser versions. For some more background you might want to visit the following bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=338621 --> 
<?xml-stylesheet type="text/xsl" href="/WebObjects/SantaPreview.woa/Contents/WebServerResources/Root.xsl"?> 
<wrapper xmlns="http://www.bbc.co.uk/ContentInterface/Content" xmlns:cont="http://www.bbc.co.uk/ContentInterface/Content" sceneId="T2a_INDEX" serviceName="DSat_T2"> 
    .... 

Firebug muestra que el archivo Root.xsl está siendo cargado, y las cabeceras de respuesta para que incluya la línea

Content-Type text/xml 

tengo también lo intenté con application/xml como tipo de contenido, pero no hace diferencia :-(

The Web Developer Extension sh También muestra la fuente correcta generada, y si la guarda y carga la página en Firefox, se muestra correctamente.

La versión de Firefox que muestra el problema es 3.0.3

Alguna idea de lo que podría estar haciendo mal?

Answer 1

Viendo sólo los elementos de texto es el comportamiento que se obtiene a partir de una hoja de estilo XSL vacía.

Para mí, eso sugiere que algo sospechoso está ocurriendo con tus expresiones xpath, y que los atributos xsl: template/@ coinciden no coinciden con el documento fuente.

No proporciona suficiente información para diagnosticar más, por lo que esta conjetura ciega es todo lo que puedo ofrecer.

EDITAR: Resultó que el problema era que IE y Chrome aceptan silenciosamente un conjunto de nodos como argumento a string-length, mientras que FF3 no lo hace. Tenga en cuenta que la especificación exige un argumento de cadena opcional y no especifica el comportamiento con un argumento nodeset.

Answer 2

trate de servir como application/xml en lugar de texto/xml

Answer 3

Respondiendo a mi propia pregunta a la luz de una investigación posterior. ddaa guíame en la dirección correcta.

Firefox parece ser bastante quisquilloso con las conversiones xslt. Vuelva a verificar su xslt para asegurarse de que no tiene errores que IE y Chrome están enmascarando.

XML Spy es un producto bueno, aunque no barato, que resaltará una gama de errores en el xslt. Parece recoger al menos tantos problemas como lo hace el procesador de Firefox.

Parece que no puede confiar en la extensión Web Developer para resolver el problema, desafortunadamente.

Answer 4

Escribo aquí para la posteridad: tuve el mismo síntoma, también Firefox 3.Sin embargo, en mi caso , el problema era otro:

Firefox parece muy, muy desagrado cuando un archivo XSL tiene un guión bajo _ en el nombre. Mi archivo XSLT se llamó algo así como my_super_nice_xslt_which_loads_in_opera_and_ie.xsl.

Así que, gente, no usemos guiones bajos. Use un guión (menos) en su lugar: my-super-nice-xslt-which-loads-in-opera-and-ie.xsl.

Luego se cargará en Firefox también. Creo que usaré nombres simples muertos con letras y números a partir de ahora. Ya sabes el dicho, "una vez mordido, dos veces tímido". (En mi caso, me picaron dos veces, pero se olvidó la primera vez, por lo que me hace como cuatro veces evitan este momento.)

Answer 5

Si está utilizando NoScript, que también desactiva hojas de estilo XSL hasta que Allow <site>.