Я пытаюсь обслуживать динамически сгенерированные xml-страницы с веб-сервера и предоставить пользовательский статический xslt с того же веб-сервера, который выгружает обработку в клиентский веб-браузер.
До недавнего времени у меня это нормально работало в Firefox 2, 3, IE5, 6 и Chrome. Однако в последнее время что-то изменилось, и Firefox 3 теперь отображает только текстовые элементы в исходном коде.
Исходный код страницы начинается так:
<?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 показывает, что файл Root.xsl загружается, а заголовки ответов для него включают строку
Content-Type text/xml
Я также пробовал использовать application / xml в качестве типа содержимого, но это не имеет значения :-(
Расширение веб-разработчика также показывает правильный сгенерированный источник, и если вы сохраните его и загрузите страницу в Firefox, он отобразится правильно.
Версия Firefox, отображающая проблему, - 3.0.3.
Есть идеи, что я делаю неправильно?





попробуйте использовать его как application / xml вместо text / xml
Отображение только текстовых элементов - это поведение, которое вы получите от пустой таблицы стилей XSL.
Для меня это говорит о том, что с вашими выражениями xpath происходит что-то подозрительное и что атрибуты xsl: template / @ match не соответствуют исходному документу.
Вы не предоставляете достаточно информации для дальнейшей диагностики, поэтому это слепое предположение - все, что я могу предложить.
EDIT: оказалось, что проблема в том, что IE и Chrome молча принимают набор узлов в качестве аргумента длина строки, а FF3 - нет. Обратите внимание, что спецификация требует наличия необязательного строкового аргумента и не определяет поведение с аргументом набора узлов.
Я посмотрю и перепроверю. И IE, и Chrome, похоже, выполняют преобразование нормально, а расширение Web Developer в Firefox отображает html, который выглядит допустимым для сгенерированного источника. Насколько точно сгенерировано исходное окно? Показывает ли он точный источник, используемый для рендеринга?
Также не используйте подчеркивание в имени файла XSLT. У меня это было, и когда я изменил имя файла без подчеркивания, он отлично работал в Firefox.
Отвечая на свой вопрос в свете последующего расследования. ddaa ведет меня в правильном направлении.
Firefox кажется довольно привередливым с преобразованиями xslt. Дважды проверьте свой xslt, чтобы убедиться, что в нем нет ошибок, которые маскируют IE и Chrome.
XML Spy - хороший, хотя и не дешевый продукт, который выявит ряд ошибок в xslt. Кажется, он решает как минимум столько же проблем, сколько и средство визуализации Firefox.
Похоже, что вы не можете полагаться на расширение Web Developer, чтобы решить эту проблему, к сожалению.
Итак, действительно ли это была проблема сопоставления пространств имен?
Нет. У меня была проблема с xpath. string-length () в IE и Chrome не возражает, если аргумент является списком узлов, но XML Spy жалуется, что есть «слишком много элементов», и изменение выражения заставило Firefox вернуться к жизни.
Есть ли способ получить сообщение об ошибке от Firefox? У меня такая же проблема, и XML Spy не жалуется. 8- /
Я пишу здесь для потомков - у меня был такой же симптом, как и у Firefox 3. Однако в случае мой проблема была в другом:
Firefox, похоже, действительно, В самом деле не любит, когда в имени файла XSL есть символ подчеркивания _. Мой XSLT-файл назывался что-то вроде my_super_nice_xslt_which_loads_in_opera_and_ie.xsl.
Итак, народ, давайте не будем использовать подчеркивания. Вместо этого используйте дефис (минус):
my-super-nice-xslt-which-loads-in-opera-and-ie.xsl.
Затем он загрузится и в Firefox. Я думаю, что с этого момента я буду использовать просто мертвые простые имена с буквами и цифрами. Вы знаете поговорку «один раз укусил, дважды стеснялся». (В моем случае меня дважды укусили, но в первый раз я забыл, так что на этот раз я стесняюсь в четыре раза.)
Если вы используете NoScript, это также отключает таблицы стилей XSL, пока вы не Allow <site>.
Это было для меня. Я бы никогда не догадался, что NoScript отключал загрузку таблицы стилей XSL, не говоря уже об обработке, но пока я не внес сайт в белый список, FireFox даже не выполнял HTTP-запрос для таблицы стилей XSL. После того, как я внес сайт в белый список, страница автоматически перезагрузилась, запросила и использовала таблицу стилей.
Я чувствую себя таким глупым сейчас, но это была моя проблема. Я знаю, что комментарии "спасибо" обычно не одобряются в отношении SO, но Спасибо.
Иногда это происходит с другими браузерами, так что неплохое предположение.