XSLT transformation error in IE

[sbhmf]

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:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE xsl:stylesheet [
<!ENTITY amp "&#38;">
<!ENTITY quote "&#34;">
<!ENTITY apos "&#39;">
<!ENTITY lpar "&#40;">
<!ENTITY rpar "&#41;">
<!ENTITY plus "&#43;">
<!ENTITY gt "&#62;">
<!ENTITY commat "&#64;">
<!ENTITY verbar "&#124;">
]>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"
xmlns:xh="http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-transitional.dtd">

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:
xslDoc.async = false;
xslDoc.resolveExternals = true;
xslDoc.validateOnParse = false;
xslDoc.setProperty("ProhibitDTD", false);

Any ideas?

[rnd me]

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.

[sbhmf]

Thx rnd,

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.

[sbhmf]

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.

The code:

function CreateDoc() {
if (typeof ActiveXObject != "undefined") {
return new ActiveXObject("msxml2.DOMDocument.6.0");
}
else if (typeof DOMParser != "undefined") {
//return new DomParser();
}
}

function View(Value) {
/*Instantiate Doc objects:*/
var xmlDoc = CreateDoc();
var xslDoc = CreateDoc();

/*Initialize Doc objects:*/
xmlDoc.async = false;
xmlDoc.resolveExternals = true;
xmlDoc.validateOnParse = false;
if (typeof ActiveXObject != "undefined") xmlDoc.setProperty("ProhibitDTD", false);
xmlDoc.loadXML(Value);
if (xmlDoc.parseError.errorCode != 0) {
alert("XML error code: " + xmlDoc.parseError.errorCode + "\n\nError: " + xmlDoc.parseError.reason);
return;
}
xslDoc.async = false;
xslDoc.resolveExternals = true;
xslDoc.validateOnParse = true;
if (typeof ActiveXObject != "undefined") xslDoc.setProperty("ProhibitDTD", false);
xslDoc.load("Templates/Template1_html.xsl");
if (xslDoc.parseError.errorCode != 0) {
window.open().document.write("XSL error code: " +xslDoc.parseError.errorCode + "<br /><br />Error: " +xslDoc.parseError.reason);
return;
}

var result = Transform(xmlDoc, xslDoc); //calls another function to manage cross-browser xform

if (result == null) {
alert("XSLTProcessor unavailable.");
return;
}

window.open().document.write(result);
...
}


[sbhmf]

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. &commat; 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.

[sbhmf]

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.