> You will note that I phrased this very carefully,
> "... XML parser used by Saxon has been lead to believe it is a UTF-8 file ...",
And I know that you are a regular poster on this and the other list
(I didn't need to put extra emphasis on it, I guess ;)
> That's one approach I've investigated. I did create a second Java class which I named "FetchDataAsXMLWindowsEncode".
> OracleXMLQuery qry = new OracleXMLQuery(conn, sqt.getText());
Ok. Then you know by now that the problem is caused with the files that
still have the old-style without the declaration. And I am sure you know
that the default for XML is UTF-8 or UTF-16 when the xml declaration is
not present (which is the reason you receive your error).
> That would mean I'd have to manipulate it on a text level (not very appealing, but certainly do-able).
indeed, not appealing.
> In my second version, I switched to JDBC for other reasons, but this does have (as you can see) a means of setting the encoding notation. I haven't moved some of the less-frequently-run reports over to the JDBC version yet. I am poking about looking for all reasonable possibilites for dealing with the issue that arose today. Maybe it's the incentive I need to move everything over to the JDBC version post haste.
Well, I posted a workaround solution for you in XSLT with a saxon
extension. I don't believe that using this workaround is a good way of
dealing with your issue. But if it takes longer or it is somehow harder
to change it at the root, you may consider to use the workaround
temporarily until you fixed it elsewhere.
The nice thing of the workaround is that it will work both with your new
style windows-1252 files (with declaration) and with your old style
windows-1252 files (without declaration). But it remains a workaround
and nothing more ;)
-- Abel Braaksma