kudos on using XSLT, it's my 2nd favorite language.
don't use the entity name, use the hex char code html/xml escaped char method.
you can do a find and replace on the file data in jscript just before the transform.
unless you're using the msxml to load from disk, in which case you'll break a lot of things like paths and contexts by switching to a string input.
i don't recall them all now but there are several minor snags that can keep xslt from working; you may want to double check your encoding and mimetypes. I've have to output=text or xml (when i wanted html) and then replace the output with a regexp before, again, don't remember why.
in short, it's typically (imho)a much smaller battle to let xslt do the heavy lifting and use the implementation environment to do a few string subs before or after as needed.
__________________ my site (updated 5/13) STATS (2013/5) HTML5:90.2% MOB:14% IE7:0.5% IE8:8.6% IE9:9.8% IE10:10%
Testing has revealed that while the transformation succeeds on Mac, it fails on every browser on Windows.
While I remain hopeful that I am mistaken, I have concluded that CHARACTER ENTITY REFERENCES IN XSL FILE ARE NOT SUPPORTED ON ANY BROWSER IN WINDOWS (tested on Windows 7 Ultimate).
Yes strong words, yet upon replacing all character entity references with decimal entity references (e.g. @ replaced with &# 64; ) the transformation succeeded in every tested browser on both Mac and Windows.
I would be thankful for a demonstration that proves me wrong!
I appreciate that MSXML.DOMDocument.6.0 is quite stringent on validating DTDs, and inhibits it by default, but this matter is not applicable to the discussion at hand because the transformation was inhibited in all browsers and not exclusively IE. Also, the final code tested did not instantiate the MSXML.DOMDocument.6.0 ActiveXObject, so even in IE DTD-validation should not have been inhibited.
Thank you all for viewing, and to rnd_me for responding. Your constructive comments are welcome via PM as well as in this thread, though more likely to reach me via PM as this thread ages and the technology evolves.
The original XHTML, XML and XSLT are all valid, and meet w3's recommendation. Xalan and others parse it successfully, yet Firefox is the only browser that does so with minor modifications.
MSS resolution included a number of directives:
1. The Doctype declaration at the top of the XML source file had to be removed.
2. Entity references are not permitted - replace them with numeric references.
3. The XHTML file MUST contain a doctype.
4. All @Import files referenced within XML and XSLT files must contain fully qualified paths, not relative paths, to the server on which they reside.
5. When processing the IE transformation, be aware that IE v.9+ supports document.implementation and document.implementation.createDocument, so either use if (typeof ActiveXObject != "undefined") or include a meta tag that informs your IEv9+ browser to process the document using v8: <meta http-equiv="X-UA-Compatible" content="IE=8" >
The subject of cross-browser XSLT transformations remains challenging, and a working solution would be the subject of a great book; I would be very interested in procuring such a book if/when it ever gets published.
Although the resolution does not meet all of my expectations it does appear to offer a working option for the current solution.