This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

How can I process an xml/xsl file pair that require the Internet Explorer dom?

  • 1 cavab
  • 1 has this problem
  • 1 view
  • Last reply by John99

more options

My personal navigation device (GPS) generates xml files that contain a record of where I have been, together with when I was there, how fast I was driving at the time, etc. taken at approx. 5 second intervals. This xml file has an xml-stylesheet with type="text/xsl" but that stylesheet is written to the Internet Explorer dom standard. The stylesheet interfaces with google maps to display a map that shows my path and it also displays tables of data including distances that are computed from latitude/longitude pairs. I can supply a small sample xml file and the xsl file as well if they are needed to diagnose my problem. I cannot find any browser other than Internet Explorer that handles these files satisfactorily. I prefer to process them from a Linux environment but with the Internet Explorer requirement I cannot do so. The browsers that I have tried and that have failed are Firefox, Opera, Konqueror, Chrome, Epiphany, Midori, Arora, and Links.

One line in the xls file in particular gives grief in the browsers like Firefox that at least attempt to do more than display the raw xml file:

xmlns:cymath="urn:smiletime-cybarber-net:math"

A comment in the xls file says this about the problem:

"Tested and currently only compatible with Internet Explorer version 6 or version 7 (as this script includes JScript functions called by XSL, msxsl:script extension is required; also, the produced XHTML document embeds javascript functions exploiting the IE DOM).

"In order to provide compatibility with Firefox, other than checking the compatibility of the IE DOM, the cymath:distCosineLaw function still needs to be ported."

My personal navigation device (GPS) generates xml files that contain a record of where I have been, together with when I was there, how fast I was driving at the time, etc. taken at approx. 5 second intervals. This xml file has an xml-stylesheet with type="text/xsl" but that stylesheet is written to the Internet Explorer dom standard. The stylesheet interfaces with google maps to display a map that shows my path and it also displays tables of data including distances that are computed from latitude/longitude pairs. I can supply a small sample xml file and the xsl file as well if they are needed to diagnose my problem. I cannot find any browser other than Internet Explorer that handles these files satisfactorily. I prefer to process them from a Linux environment but with the Internet Explorer requirement I cannot do so. The browsers that I have tried and that have failed are Firefox, Opera, Konqueror, Chrome, Epiphany, Midori, Arora, and Links. One line in the xls file in particular gives grief in the browsers like Firefox that at least attempt to do more than display the raw xml file: xmlns:cymath="urn:smiletime-cybarber-net:math" A comment in the xls file says this about the problem: "Tested and currently only compatible with Internet Explorer version 6 or version 7 (as this script includes JScript functions called by XSL, msxsl:script extension is required; also, the produced XHTML document embeds javascript functions exploiting the IE DOM). "In order to provide compatibility with Firefox, other than checking the compatibility of the IE DOM, the cymath:distCosineLaw function still needs to be ported."

All Replies (1)

more options

You may get an answer, but it is not really the sort of subject covered by this forum, I suggest you try Mozilazine and if you solve the problem post back again.