XSLT transformation error in IE
MSXML's parser is crashing on load with error:
Reference to undefined entity 'commat'.
@ references the popular '@' symbol.
Following the normal XML parser directive (<?xml...), the xsl document defines a local dtd, where the entity reference is explicitly defined:
The transformation succeeds outside of the browser (e.g. xalan).
Note that posting the entirety is quite impractical, as the xml file is well over 15KB, and the XSL file contains over 1000 lines on its own, plus multiple imports.
The code uses "msxml2.DOMDocument.6.0", and the doc object is set with:
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.
I've last used the browser's transform processor when version 3.0 was current, and was hoping that these issues were resolved by now. Apparently not.
Further investigation revealed:
The original issue was with the previously-parsed xml file. the error was eliminated when I appended to it a reference to a the same doctype.
Now I am receiving a different error whose errorcode is -1072896679, from the xsl parser, indicating 'Unexpected end of file.' The xsl file is well-formed, as indicated in the original post.
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.
Microsoft Support(MSS) Resolution
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
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.
Apparently, Chrome, Firefox, and Opera don't support this part of the XML 1.0 spec, and therefore those browsers magically render the document anyway. Assuming I've read the spec correctly,
Thank you for great comments, I concur.
During testing, the amp was commented out and the transformation still failed.
The MS support engineer also asserted that a DTD in the xml source file will inhibit IE from transforming it, contrary to Microsoft's own docs on MSDN.
|All times are GMT +1. The time now is 09:04 PM.|
Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.