responseXML is a tricky beast, on most platforms it refers to an XML document.
This means you can do things like access the root node through the documentElement
property. Unfortunately this does not work on Internet Explorer:

The code above will load and parse an external XML file. The resulting object is
a true XML document which can be treated the same as the responseXML
returned by the XMLHttpRequest object on other platforms.

The above code will only work on a local file system. When dealing with remote data you check the readyState property to ensure that the data has been fully loaded. You can also trap the onreadystatechange event as you would for the XMLHttpRequest object.

Comments (40)

I guess it’d only be useful for XML data though, which is rarely how I use XMLHttpRequest. And it wouldn’t support POST parameters. And you’d still need to do things the XMLHttpRequest style for non-IE browsers.

Still, if you’re doing something that fits, this looks like a much better way than using ActiveX.

You are absolutely right about what XML-Islands don’t do for you. They also dont provide you with a simple way of passing data to the Server (well, you could encode the Data in the URL).

You can get what you want by using a hidden iframe, document.write() a form with a textarea holding your data and set the method to “POST”. Then you sumbit that form and use onreadystatechange on the iframe. You can get the XML-Document as the iframes document then.

The server of course must check for the POST-parameter.

The bad news is that the above is harder to do than to talk about – there are many cases where you need setTimeout() to decouple things from each other. The XML-islands are a simple way if what they deliver to you is enough for your problem.

documentElement works for responseXML !!!
If the document returned by XMLHTTP is an xml document (mime-type = text/xml) then request.responseXML.documentElement works as expected.
In IE, if the mime-type is not text/xml and/or the document is not a valid XML document, then responseXML is not valid, and you can use responseText to access the plain text returned by the server.

The main problem with Data Islands (as has been pointed out) that I have is that they’re only viable for IE.

If you have a use for them that you can be sure only needs to work in IE, they’re great.

Short of that, I personally see only one use for them: as a failover for XMLHTTP. My current library does just that, but they’re not as flexible as XMLHTTP so unless you’re sending a GET and expecting text/xml as a response, it won’t work.

Shure XML islands only work for IE, but you have to distinguish between IE and real browsers as well if you use XMLHttpRequest. You can do that by simply testing if window.XMLHttpRequest exists. You can even use a try{}-block around the instantiation of the ActiveX-component and only fall back to XML islands in the catch-block (the user may have deactivated ActiveX). If you realy whant a 100% solution you can chose to use a hidden iframe or XML Islands depending on the usecase.

The XML island is easier to handle than the hidden iframe an I guess it is also a bit faster. The drawback is that you can only use it for GET-requests and you are very limitet in the ammount of data transfered to the server in a single request.

This is really great idea! A little googling showed that you can also call transformNode on the data island. I’ll have to test transformations later today when I have more time. XML *and* XSLT without ActiveX would be pretty cool!

Comment by: Fuzztrek

Posted: 2006/04/25 4:11 pm

Comment: #11

IceWeb 2006 notes – Shaun Inman, “Responsible Asynchronous Scripting”
First of all, to Simmi and any others who might be in the room as I type this: Hi!* Briefly explains the difference between the asynchronous model and the plain HTTP model. * In the really early days…

Just to add a bit to the conversation here… While true XML data islands are only available in IE, you can gain similar capabilities by creating a container within your document, set the CSS display property to none, and then use this container as a simple cache for storing and retrieving XML fragments.

A hack, yes… And even more so can lead to various issues that come along for the innerHTML ride, especially when you attempt to transform this via XSLT only to discover that what you have is nothing remotely even close to well formed text, much less XML. But at this stage of the web’s future history it’s tough to determine the difference between intentional feature and unintentional side effect (and therefore destined to cause a bit of trouble along the way) anyway.

None-the-less, results may vary, but if used with care, can make browser-based XML handling just a touch nicer, of which XML data islands in IE, without a doubt, most definitely do.

During creation of web application using AJAX I am facing the following problem.

In case of IE6 it work correctly. But in case of mozilla it does not work properly, i.e. in some case it return correct “responseXML” but in some case it return null “responseXML” for same type of code the code fragment is as follows.

Does this data island mechanism bypass the XMLHTTPRequest security issue? That is, XMLHTTPRequest won’t let you fetch XML data from a server that is different than the one the original page was loaded from.

But you *can* load script from anyplace.

I am wondering if this data island machinery also bypasses that security feature in XMLHTTPRequest…

To answer my question: no, it doesn’t bypass the security model. I get a dialog warning when I try to load from an external site.

Comment by: HenryMinsky

Posted: 2006/07/12 7:11 pm

Comment: #24

[…] In this post from Dean Edwards, he quickly shows off a feature of Internet Explorer that could replace the use of ActiveX for XML communication – XML data islands. A little known but cool feature of Internet Explorer is it’s support for XML data islands. Basically, you can embed some XML data in a page and reference an external data source. […]

You guys are missing a couple of important points about XML Data Island
support in IE:
– not only is it proprietary, but it has also been deprecated;
– it invokes the MSXML3 Dom engine internally (which can cause you problems if you’re also working with documents created using the newer version.)

For those interested in following up on data islands .. they are kind of supported in Mozilla : see here basically you can dump an <xml> element containing xml on your page and it wont display and you can access it using DOM methods. This could be useful for client side caching.

I’ve only just got started with AJAX. Figured it was high time I learned it, so I decided to put a slideshow of sorts on my home page. After much headscratching, I ran across IE’s problem with the responseText property and after a bit of Googling I was led here. Thank you very much indeed for showing me how to get through that particular problem as it was driving me nuts. Keep up the good work!

“When dealing with remote data you check the readyState property to ensure that the data has been fully loaded. You can also trap the onreadystatechange event as you would for the XMLHttpRequest object.”

How do you do this? I don’t think that property and event are available for anything except the XMLHttpRequest object.

will not work on IE7 ,
I think this is bcoz the use of createElement() which i suppose IE7 does not support.

So is there ny altenative to this which will work in IE7..

please make a try..

Comment by: Soubhagya

Posted: 2008/03/07 1:07 pm

Comment: #35

[…] How To Load And Parse XML Data Without ActiveX Apr 27, 06 A little known but cool feature of Internet Explorer is it’s support for XML data islands. Basically, you can embed some XML data in a page. […]