Saxon

Thanks. I just updated Chrome on my Mac to Version 132.0.6834.84 (Official Build) (arm64) and I get the same problem.

Somehow it seems, at least in that <?xml-stylesheet?> loaded XSLT, Chrome doesn't parse/load the https://www.saxonica.com/contents.xml?cache=20241218 successfully, the count($contents-doc) is 0.

When I use local files and create a new contents.xml that is simply UTF-8 encoded the file is loaded/parsed.

I haven't found any other parsers fail parsing https://www.saxonica.com/contents.xml?cache=20241218, not sure why Chrome/Edge 132 fail.

I think this is fixed, but I'm not sure what the underlying issue was.

With a little debugging code in place, I noticed that if I hit reload several times, sometimes contents.xml would load. So I started doing binary search in there to find what was wrong. After a bit of digging, I concluded that it was the presence of the XML declaration that caused the problem. Perhaps because an alternate encoding was specified?

I made a cursory look for a character that isn't valid ISO 8859-1 but didn't find one.

I took out the XML declaration and republished and it seems to be working now. :-/

Yes, looks fixed.

When trying to find out at what could be wrong or quirky I also found that the XSLT https://www.saxonica.com/make-menu.xsl?cache=20241218 is served as application/octet-stream.

But it still is and although that seems wrong or at least like a lack of MIME type mapping of .xsl files for the server it doesn't seem to cause an issue.

Thanks, I've created another issue on one of our internal trackers to track (and eventually fix) the content type mapping.