Saxon

I would need to see the files in use to get to the bottom of this. I can't think of any obvious reason.

You appear to be processing an HTML file using the doc function, is that right? I wonder if there's some URI redirection going on that is confusing things.

Saxon of course doesn't retrieve the external entities referenced by the DTD itself; this is done by the XML parser, but it does it using an EntityResolver that Saxon supplies. It's the XML parser, however, that is responsible for determining the base URI (that is, the location in which to look for the file). Ideally it would be the parser's job to hold copies of well-known entities to avoid fetching them from the (unresponsive) W3C site, rather than this being done at the Saxon level. What Saxon does it to supply an EntityResolver which the XML parser uses to resolve references. The most common reason for this going wrong is that a file is parsed whose base URI is unknown.

The presence of a public ID in the version attribute of the root element looks very odd, and I would be tempted to investigate it; it could be a symptom of some deeper problem.

Yes, I am using several calls to the document function. I want to process epub files. The shell script is supposed to take care of unzipping and zipping, the xslt for the transform. As quite a lot of single files are read and included in the process, I though it might be a good idea to store the needed file paths in variables, using no relative but absolute paths, that I've built with base-uri(). Anyway, the document() calls are kind of nested: the second document() call is made in from a template that is itself processed from a document() call.

I've taken your hint about the parser and integrated xercesImpl.jar explicitly on the classpath and setting it as DOM and SAX parser with -D. But still I get the same error message. So, with my multiple document() calls it really must be the case that a file is parsed whose base URI is unknown, as you say. How can I make the base-uri's all known to the EntityResolver?

I've uploaded an archive with an example of my process and attached it.

The java call to saxon is in "pagelist.sh". I put saxon9he.jar and xercesImpl.jar in the /bin directory (not included in the example archive). A sample set of files I want to process is in the /temp folder.

By the way: originally all my document()-calls were with just one argument. I've later included the "/" as a second argument, but that didn't change the behavior - error message is the same with both versions. Anyway, with my file paths being absolute, I thought the "/" as second argument wouldn't be necessary anyway.

And another note: I've not only tried this as a shell script on Ubuntu linux, but also with a batch script version on a Windows 7 installation. Same error message there.

Best regards, Kai Weber

Thanks for your efforts in putting this evidence together.

I'm afraid it's a simple typo in Saxon's internal catalog of internally-held DTD entities. It's mapping a particular public ID to the location xhtml11/xhtml-inlpres1.mod when it should be w3c/xhtml11/xhtml-inlpres1.mod.

I haven't yet established how this bug got through our tests of this feature.

We'll fix this in our next maintenance release, which is imminent. I can't suggest any easy circumvention - you can disable Saxon's internal DTD cache, but it will then try fetching the DTDs from the W3C web site, which will give you a different kind of problem.

I'll raise the bug on the "Issues" side of this tracker, and you can follow progress there.