Loss of functionality in various browsers with fatal error

[gkholman]

Please consider the test files in this ZIP: https://www.oasis-open.org/committees/document.php?document_id=68209

The two directories are:

• doc-works - an OASIS work product using DocBook stylesheets version 1.69.1
• doc-does-not-work - same OASIS work product using DocBook stylesheets version 1.79.1

The only difference in the two directories is the deep-down "xsl/" and its descendants

I can drag and drop the file doc-works/genericode-v1.0-csd04wd02.xml into Safari and into Internet Explorer, revealing the content of the document without error. It doesn't work on Chrome, Firefox, nor Edge, but that's okay as long as my committee members have at least one browser on each of OSX and Windows.

The file doc-does-not-work/genericode-v1.0-csd04wd02.xml fails on Safari (libxslt 1.0 - without a message visible) and Internet Explorer (Microsoft's own stylesheet processor - message: Reference to variable or parameter 'l10n.xml' must evaluate to a node list.)

Please let me know if you need any further details.

Thank you for your help with this!

. . . . . . Ken

[bobstayton]

Hi Ken, I'm not able to duplicate the problem on Windows 10. I downloaded your zip file, unzipped it, and opened both top level XML files in Internet Explorer, and they both produce the same formatted results without error. I'm using IE version 1909 (OS Build 18363.1316). I don't have a Mac to test Safari. If I can ask a stupid question, why don't you render the document to HTML and post that? That way you know everyone has the same results.

[gkholman]

Thanks for responding, Bob! I don't know what to say, though. Windows 10 (10.0.19041) running Internet Explorer (2004-19041.746) gives me this:

Using 1.79.1 abends. Using 1.69.1 presents the document. I have to continue to use 1.69.1 and that has known issues for my specifications in the area of table rendering (thankfully not in the HTML). That's why I updated the OASIS library to use 1.78.1 but I neglected to test this particular use case. So now I have to use 1.69.1 in this use case and 1.78.1 in another, so the results may be inconsistent in ways I haven't found yet.

Neither test directory works when using Chrome, Firefox, and Edge ... and I've since been told that IE and Safari are about to be replaced with Chrome ... so my committees are going to be stuck at some point.

Your question isn't stupid at all ... I didn't describe the use case that brings up the scenario with the test files. I didn't think it was relevant to the fact that the latest stylesheets don't work but the earlier stylesheets do work.

I advocate my contributors to open their XML locally in IE/Safari as they are editing their contribution. If they want to see what their edits look like (and I ask them to preview their edits), they simply refresh the browser window and their edited XML is presented. Easy-peasy. One keystroke! They don't have to produce the HTML in order to review the HTML. Personally, I value the dynamic review of what is going to be produced from my edits.

I've implemented an automated GitHub publishing of DocBook for any OASIS committee. It leverages a commercial Publishing-as-a-Service remote API that uses commercial software to produce the output PDF on every push to the repository on any branch. I haven't finished the LinkedIn article I'm writing describing the Code List Representation TC use of the automated publishing, but I have put the essentials into the README file:

https://github.com/oasis-tcs/codelist-genericode#detailed-steps

Please let me know if you have any more questions. No question is "stupid". It was careless of me not to fully describe the situation. Even when the situation is so important to me.

Thanks, again!

. . . . . . Ken

[bobstayton]

Based on version numbers, it seems your version of IE is somewhat newer than mine. The failure with your version suggests that Microsoft changed their XSL processor between my version and yours. Given that the 1.79.1 stylesheets work with multiple processors outside of IE, it would seem that Microsoft's changes created this problem, not the stylesheets.

I will say that the l10n.xml parameter's content is huge, since it loads all the localization content. The collection of languages grew between 1.69.1 and 1.79.1, so it's possible some size limit was exceeded so the Microsoft processor cannot make it into a nodeset. If you are only working in English, you might try reducing the language set to just English in your distribution.

[gkholman]

Thanks, Bob ... I'll take a look in the direction of the list of languages. I will let you know how it goes.

Yes, I'm aware that the stylesheets work elsewhere ... I checked with the gold standard Saxon to make sure.

However, if my test files had failed only in IE, I would have attributed it to IE. I took the time to submit this ticket because I had evidence of two different XSLT processors that fail. Not just one. I get the same contrasting results with Safari.

Having it fail in multiple browsers left me the impression it might be the stylesheets deploying some new convention that could be replaced with the old convention to get more browser coverage.

Let's see what I find.

[gkholman]

It turns out the problems between the two browsers are very different. See issue https://github.com/docbook/xslt10-stylesheets/issues/222 for the problem with Safari.

I'm still working on IE and it has something to do with the document() function.