Xslt8690 ошибка при обработке xslt

Extensive research did not lead me to understanding why the below happens — I hope that the SO community can help…

I copied the files mentioned in Why HTML1113: Document mode restart from IE9 Standards to Quirks to local filesystem and opened the xml in IE9 (by specifying the path D:... in the url bar).
Surprisingly, the behavior is quite different from opening the web version.
Now I can understand that «My Computer» zone settings differing from Internet zone ones explain the pop-up windows mentioned below, but I don’t understand why the result is different and why quirks mode is not automatically chosen, just like was done when opening the xml on the web.

When I open the local file, I get the following:

which no doubt is caused by a local zone setting. Next, the browser mode is IE9 (not auto quirks as earlier) and it fails on applying the XSLT:

First I thought that this was caused by MSXML6 DOM basic settings like AllowXsltScript not being set to true, but I am not sure about that any more, because it all works OK when opening the web version.
So why does the local one fail?

Stranger still, opening the web version led to auto quirks mode and correct result, but when I switch to quirks mode for the local file, it fails on the MSXML6 DOM object — actually this makes more sense to me than no error, because quirks mode probably only offers MSXML3 (or should only offer that — but then why was auto quirks in web version OK?).

After accepting, it changes to

Now, when selecting IE9 standards mode again, I get

and the result is the expected

Reciting events when using local files (apart from zone setting differences):

1. IE9 standards mode XSLT8690 error
2. Switching to quirks mode errors
3. Switching back to IE9 standards mode is OK now

Reciting the events when opening the web version (apart from differences due to zone settings):

1. quirks mode automatically
2. page opens correctly in quirks — apparently MSXML6 is still used here in the auto quirks mode
3. switch to IE9 standards mode is OK too
4. Back to quirks mode errors as above («The parameter is incorrect'»)

What is causing all these peculiar differences?

Обширные исследования не привели меня к пониманию того, почему происходит следующее: я надеюсь, что сообщество SO поможет…

Я скопировал файлы, упомянутые в статье Почему HTML1113: Режим документа перезапускается из стандартов IE9 в Quirks в локальную файловую систему и открыл xml в IE9 (указав путь D:... в строке url).
Удивительно, но поведение отличается от открытия веб-версии.
Теперь я могу понять, что настройки зоны «Мой компьютер», отличные от зон интернет-зоны, объясняют всплывающие окна, упомянутые ниже, но я не понимаю, почему результат отличается и почему режим quirks не выбирается автоматически, как это было сделано, когда открытие xml в Интернете.

Когда я открываю локальный файл, я получаю следующее:

что, несомненно, вызвано настройкой локальной зоны. Далее, режим браузера — IE9 (а не автоматические причуды, как раньше), и он не работает при применении XSLT:

Сначала я подумал, что это вызвано базовыми настройками MSXML6 DOM, такими как AllowXsltScript не установлены в true, но я не уверен в этом, потому что все работает нормально при открытии веб-версии.
Так почему же местная неудача?

Тем не менее, незнакомец, открыв веб-версию, появился режим автоматического приведения и правильный результат, но когда я переключаюсь в режим quirks для локального файла, он терпит неудачу в объекте DOM MSXML6 — на самом деле это имеет для меня больше смысла, чем отсутствие ошибки, поскольку режим quirks возможно, только предлагает MSXML3 (или должен только предложить это — но тогда почему были автоматические причуды в веб-версии ОК?).

После принятия он меняет

Теперь, когда вы снова выбираете режим стандартов IE9, я получаю

и результат — ожидаемый

Чтение событий при использовании локальных файлов (кроме различий в настройках зоны):

Ошибка режима IE9 XSLT8690 Переход к ошибкам режима quirks Переход в режим стандартов IE9 в порядке

Чтение событий при открытии веб-версии (кроме различий из-за настроек зоны):

режим quirks автоматически страница открывается правильно в причудах — видимо, MSXML6 по-прежнему используется здесь в режиме автоматического причудливости переключиться на режим стандартов IE9 тоже хорошо Вернуться к ошибкам режима quirks, как указано выше («Неверный параметр»)

Что вызывает все эти своеобразные различия?

I am glad that the issue was fixed — in this particular case that is.
But the real reason for the error in IE9 is not disclosed yet, so I will do that here.

The reason for the encountered behavior is a bug in XSLT processing in IE9.

Well OK — it’s not really a bug, just bad error reporting. The point is that IE9 applies MSXML6 by default, and a lot of things have changed with respect to MSXML4. When there’s a plain error in the XSLT, it’s not reported — IE9 seemingly skips processing onto default text() templates, which results in presenting all text nodes.
Worse, when something is done in the XSLT that is prohibited by default in MSXML6, the same thing happens. So what’s prohibited by default in MSXML6? A lot! Applying Jscript for instance. And DTD’s. And the document() function won’t work.

In the case above, one might suspect from the text shown (which obviously comes from applying the default templates), that there is an error in the xslt — waiting to be discovered with good tools. But this IE9 behavior is not so obviously linked to the xslt when there’s no text in the xml part of the file opened (that is, when the xslt itself supplies all the data to be processed, for instance by importing xml files on runtime, or the data in the xml that the xslt processes is all in attributes and nodenames). You just have to know…

You can see the error message behind all this yourself if you go to developer tools by pressing F12 (or select it from the Tools menu). In developer tools subscreen, select Script Menu and load your page now. You will see that on the right, in the console, an error message appears:
XSLT8690: XSLT processing failed.
When this error occurs, only the text nodes in the xml are displayed (so, for an empty xml root node, the page will be blank).
I could find only one reference to this error on the web: http://www.wikistep.org/bugzilla/show_bug.cgi?id=4140.

Note that when you select «compatibility view» by clicking the torn page button next to the refresh button (which is not always available, another -minor- IE9 bug), the page goes back to IE8 display, and will be OK again — well, apart from any errors in xslt of course, but MSXML 4.0 does not have all these restrictions that MSXML 6.0 has by default. It’s safer, for sure, but very annoying too.

Note that by selecting compatibility view, the site part of the file’s url is added to the list of sites for which compatibility view is automatically applied.
To recreate the issue, you will have to remove the site from that list, by pressing Alt to open up the menu, selecting tools/compatibility view settings, and removing the site from the list before trying again.
Also note that the trick of applying compatibility view does not always fix things: when for instance the xslt calls embedded javascript containing classes not available in IE8 Jscript version, the xslt will fail in compatibility view too.

Now what can be done about this? Actually I am not sure — worth another question on SO!
The properties which are off by default can be switched on — but the examples I have seen only do so when loading an XML type string in a DOM object within a sequence of statements — and then one can assign the new DOM object the necessary properties before loading the string.
Here, IE9 takes care of loading the XML automatically and also loads the XSLT to process the XML. So where the hell can we set the XML load properties before the loading takes place?
I am sure it will take time — but I will find out!

I am glad that the issue was fixed — in this particular case that is.
But the real reason for the error in IE9 is not disclosed yet, so I will do that here.

The reason for the encountered behavior is a bug in XSLT processing in IE9.

Well OK — it’s not really a bug, just bad error reporting. The point is that IE9 applies MSXML6 by default, and a lot of things have changed with respect to MSXML4. When there’s a plain error in the XSLT, it’s not reported — IE9 seemingly skips processing onto default text() templates, which results in presenting all text nodes.
Worse, when something is done in the XSLT that is prohibited by default in MSXML6, the same thing happens. So what’s prohibited by default in MSXML6? A lot! Applying Jscript for instance. And DTD’s. And the document() function won’t work.

In the case above, one might suspect from the text shown (which obviously comes from applying the default templates), that there is an error in the xslt — waiting to be discovered with good tools. But this IE9 behavior is not so obviously linked to the xslt when there’s no text in the xml part of the file opened (that is, when the xslt itself supplies all the data to be processed, for instance by importing xml files on runtime, or the data in the xml that the xslt processes is all in attributes and nodenames). You just have to know…

You can see the error message behind all this yourself if you go to developer tools by pressing F12 (or select it from the Tools menu). In developer tools subscreen, select Script Menu and load your page now. You will see that on the right, in the console, an error message appears:
XSLT8690: XSLT processing failed.
When this error occurs, only the text nodes in the xml are displayed (so, for an empty xml root node, the page will be blank).
I could find only one reference to this error on the web: http://www.wikistep.org/bugzilla/show_bug.cgi?id=4140.

Note that when you select «compatibility view» by clicking the torn page button next to the refresh button (which is not always available, another -minor- IE9 bug), the page goes back to IE8 display, and will be OK again — well, apart from any errors in xslt of course, but MSXML 4.0 does not have all these restrictions that MSXML 6.0 has by default. It’s safer, for sure, but very annoying too.

Note that by selecting compatibility view, the site part of the file’s url is added to the list of sites for which compatibility view is automatically applied.
To recreate the issue, you will have to remove the site from that list, by pressing Alt to open up the menu, selecting tools/compatibility view settings, and removing the site from the list before trying again.
Also note that the trick of applying compatibility view does not always fix things: when for instance the xslt calls embedded javascript containing classes not available in IE8 Jscript version, the xslt will fail in compatibility view too.

Now what can be done about this? Actually I am not sure — worth another question on SO!
The properties which are off by default can be switched on — but the examples I have seen only do so when loading an XML type string in a DOM object within a sequence of statements — and then one can assign the new DOM object the necessary properties before loading the string.
Here, IE9 takes care of loading the XML automatically and also loads the XSLT to process the XML. So where the hell can we set the XML load properties before the loading takes place?
I am sure it will take time — but I will find out!

IE9 применяет MSXML6 по умолчанию, где IE8 применяет MSXML3. Тот факт, что определенные функции отключены по умолчанию в MSXML6, вызывает проблемы, особенно при загрузке таких страниц, как

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="test.xsl"?>
<root>...</root>

где упоминается таблица стилей xslt, применяется встроенный javascript (например, пользовательские функции расширения).

Свойства DOM xslt можно задавать в коде сценария, например, в Jscript:

var xsltDoc = new ActiveXObject("Msxml2.DOMDocument.6.0");
xsltDoc.setProperty("AllowXsltScript", true);
xsltDoc.loadXML(xsltfile);

Но при загрузке файла, указанного выше, IE9 загружает файл xslt автоматически, со значениями свойств по умолчанию. И это приводит к поразительной разнице в IE8: IE8 будет загружать страницу безупречно, но IE9 выдает ошибку из-за свойства объектов MSXML6 DOM по умолчанию «allow xslt scripting = false». Это неправда — см. Мой ответ ниже. Остальная часть вопроса, таким образом, незначительна

Как я могу заставить IE9 загрузить файл выше и все еще разрешить запуск скриптов в xslt?

Примечание. Я уже пробовал настройки Internet Options/Security/Custom level…/Scripting/Active Scripting = Enable, как было предложено в msdn, но эта настройка была уже правильной.

Я надеюсь, что есть специальная инструкция по обработке IE9, но я думаю, что нет. Но, возможно, это специальный атрибут stylesheet, который взаимодействует с загрузкой IE9 xslt.
Конкусоном также может быть, что это возможно только при запуске скрипта в главном html файле, где автоматическая загрузка не выполняется, но XML и XSLT загружаются в указанные объекты DOM с указанными свойствами (такими как AllowXsltScript), и вывод преобразование затем загружается в браузер явно.