Why Data Islands Matter
Data Islands let developers embed structured XML data directly inside an HTML page and then manipulate that data with JavaScript. The trick is that the XML stays in the page’s DOM, so you can query it, transform it, and render it back to the user without making a separate round‑trip to the server. Because only Internet Explorer implements the feature, many tutorials and legacy codebases refer to it as an “IE‑only” trick, but the underlying idea is still useful for understanding how browsers can host XML natively.
In Internet Explorer you declare a Data Island by placing an <xml> element anywhere in your markup. The element must have an id attribute that you can use later to grab the island with JavaScript. You can either embed the XML inline or point to an external file using the src attribute. A second <xml> element can hold XSLT, allowing you to separate presentation logic from data.
Once the page has loaded, you can access the Data Island like any other DOM object. The native MSXML methods such as selectNodes, selectSingleNode, and transformNode become available, giving you a powerful set of tools to work with the XML. This means you can filter, sort, or alter the data on the fly, and then send the updated XML back to a server if needed.
Using a Data Island has a few advantages. First, it keeps the data in the same file as the presentation, so developers can see the raw XML next to the XSLT that renders it. Second, because the browser parses the XML once, you avoid the overhead of parsing the same string repeatedly. Third, you get a consistent API across all browsers that support the feature, which historically has meant Internet Explorer 6 through 9. The biggest drawback is obvious: only IE supports the <xml> tag, so you’ll need a polyfill or alternative strategy for other browsers. That said, if you’re working on an internal tool that runs in a corporate environment where IE is still common, Data Islands can be a quick and dirty way to get XML into the browser.
Even though the feature is old, you’ll still see it referenced in older examples of XML manipulation in JavaScript. Knowing how to set up a Data Island and call transformNode is a handy skill for anyone looking to understand how client‑side XML processing works under the hood.
Hands‑On: Manipulating Data Islands with JavaScript
Let’s walk through a concrete example that shows how two Data Islands - a data source and an XSLT stylesheet - can be used together to produce a dynamic list of items. In this demo, the user clicks a “Where to Buy” link next to each item, which updates a selected attribute in the XML. After the attribute changes, the page re‑renders the list to highlight the selected item. All of this happens client‑side with a handful of lines of JavaScript.
The first step is to define the two islands in the page. The XML island holds a simple list of products, each identified by an id. The XSLT island references an external stylesheet that knows how to turn that list into HTML. Because the islands are defined in the same document, the script can reference them by ID immediately after the page loads.
<my-list>
<my-item id="3" name="Milk"></my-item>
</my-list>
</xml>
<xml id="demoXSL" src="list.xsl">
The XSLT file (list.xsl) is a standard stylesheet that loops over my-item nodes and produces an <a> element for each. Each link calls the SetSelected function when clicked, passing the item’s ID as an argument.
Next, we write the JavaScript functions. SetSelected builds an XPath expression to locate the item node you clicked. It then clears any existing selected flags on the list, sets the flag on the chosen node, and calls Render to refresh the view.
The Render function simply asks the XML island to transform itself using the XSLT island. The result is injected into a <div> that the page can display. Because transformNode returns a string of HTML, you can assign it directly to innerHTML without any further processing.
To see the code in action, load the page in Internet Explorer, click on a “Where to Buy” link, and watch the list update. The selected item gets a highlighted background or bold text, depending on the CSS you’ve defined in the XSLT. If you want to inspect the raw XML after a change, simply add a button that prints demoXML.xml to the console or a text area.
Because the entire workflow runs in the browser, you avoid the latency of round‑trips to the server. If you’re working on a small tool or a proof‑of‑concept where speed matters more than cross‑browser compatibility, this pattern can be surprisingly effective. Just remember that anyone who opens the page in a non‑IE browser will see the raw <xml> tags, so the technique is best reserved for controlled environments.
From the Browser to the Server: Updating Data with Web Services
Data Islands are not limited to static demonstrations. They can act as a staging area for data that you’ll eventually send back to a server, or they can receive updates from a web service in real time. The key to this integration is the XMLHttpRequest object, which lets JavaScript fetch XML (or JSON) from a remote endpoint without reloading the page.
Consider a scenario where the list of products comes from a web service that returns an XML document. You can load that document into a Data Island and then render it with XSLT. When the user selects an item, you could update the island locally and then push the modified XML back to the service. Below is a minimal example that shows how to fetch data, bind it to the island, and send updates.
In this script, loadData pulls the XML from the service and assigns it to the demoXML island’s xml property. The assignment automatically parses the string and makes it available for XPath queries. Once the data is in the island, Render transforms it and displays it to the user.
When the user interacts with the list and modifies the selected attribute, calling sendUpdate will package the whole island back to the server. The service can parse the incoming XML, apply any business rules, and respond with a status code. Because the communication uses standard HTTP verbs, you can integrate the pattern with existing RESTful APIs.
To make the experience smoother, you might want to add error handling that shows a friendly message if the network call fails, or a loading spinner while the request is in flight. You can also cache the XML locally with localStorage or sessionStorage so that repeated visits load faster, falling back to a server call only when the cache is stale.
When you pair Data Islands with web services, you create a powerful client‑side data layer that can stay in sync with a server without page refreshes. It’s a pattern that predates modern frameworks like Angular or React, but the core idea - keep data in the browser, transform it for display, and send it back to the server - is still relevant today for small projects or for learning how XML and XSLT work together.
Try extending the example by adding a “Save” button that calls sendUpdate after the user makes a selection. As you experiment, you’ll discover that the same principles can be applied to a wide range of data‑driven web applications, even when you’re working in an environment that only supports Internet Explorer.





No comments yet. Be the first to comment!