A third-party supplier is providing me with some XML, that one of my applications is happily processing. For debugging reasons, I want to look at it, but it doesn't display anything in the browser, and I (and other members of my team) have to viewsource to look at the (ugly) XML.
This sounds like a classic use-case for XSLT, I thought. I will write a few simple transforms in XSLT to convert this XML into clean HTML. Pop those rules, maybe some Javascript, and a pointer to the XML's URL into a local HTML file, and every time I open the file, voila - freshly fetched and formatted HTML.
However, I am being bitten by the "Common Origin Policy" XMLHttpRequest. It declines to fetch the XML because it comes from a different server - apparently for security reasons to avoid sending inappropriate cookies. That concern is inapplicable in this situation.
I could use the fake the document.domain trick to circumvent this, but I don't think that is applicable when the file was opened in the browser from a local machine, not from a server.
I could redirect everything through a proxy-like web-site to make it look like it came from the same source, but that seems like an bad hack to me, and adds unnecessary network hops.
I could write an whole application for this task, but that seems over-the-top.
I thought I would check if I am missing something obvious. I just want to say "Show me THAT XML document over there, with THIS XSLT file I have with me here." without needing to involve an unnecessary web-server. I'm not sure why it is turning out to be difficult.