No developer in their right mind can deny XML its future. XML is already all over the place. Wherever it isn't already it, more than likely, soon will be. This has been the case for quite some time now. However it has taken me until now to start looking at it in depth. I am more convinced now than ever of its importance. Hopefully you soon will be too. This is the first of what I hope to be a collection of articles on using XML with Domino that will no doubt expand in the future.
Domino started to adopt XML when release 5.0.2 introduced the "?ReadViewEntries" URL command. Since this feature was introduced I have never really understood its significance in relationship to Domino. After all, the only place I could see it was actually being used was in the R5 View Applet.
Before we start looking at what we can do with the command, let's look at what the above feature does. Consider this view:
Despite the fact that I called the view "xml", it is nothing more than an ordinary view and has no special formatting whatsoever. However here is a screen shot of Internet Explorer displaying results of a ReadViewEntries call to the view using this URL:
This is all very well, but what can we do with the above XML that is going to be useful to us, as developers? To a certain extent there is not much we can do. The problem is that to convert this into meaningful HTML we need to edit the source to include the line which tells the browser how to format the XML. Obviously we can't do this. The rest of this article is devoted solely to demonstrating how we can convert this data and to serve as an introduction to XSL.
Applying a little style:
The first thing I did was to save the source XML code returned from the above view to an .xml file on my hard drive. This meant that I could edit the file and add the following line to the top of it:
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
The browser now knows that the XML should be rendered according to the rules defined by the specified XSL file.
You might well be thinking that the title of this article is now a little misleading. Sorry, maybe it is. In practice you can't save the source and edit the file. Stick with me though as what I'm demonstrating is extremely useful and future articles will start to build on this technique to the point where it really is putting the XML to good use.
Let's now look at the XSL file and see what it is that formats the XML. In this particular instance I chose to design the XSL such that the resulting HTML will resemble the layout of CodeStore's "All View". Here is the code:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">
<title>An XML Example</title>
<h3>All recent articles from CodeStore.</h3>
<xsl:apply-templates select="viewentries" />
<!-- Top level template -->
<!-- Loop through each document (viewentry) and apply create the rows for each one-->
<tr><td style="padding: 0px 5px 10px 10px;">
<xsl:value-of select="entrydata[@name='Abstract']" />...
Don't worry if the above is all Double-Dutch. Notice however that the format should be familiar due to the fact that XSL is derived from SGML in the same way HTML and XML are. Also, trust me that XSL really isn't that complicated. Explaining it in detail is well beyond the scope of this article and there are plenty of resource out there so I won't bother explaining it now. If you go through the above example line-by-line it should become obvious what it going on. Basically the "template" matches patterns within the data and reformats it. The format from the ReadViewEntries command is useful in that it always follows the pattern of /viewentries/viewentry/entrydata.
If you are using a browser that supports XML then you can take a look at the XML file that I saved and edited and see for yourself what effect the above XSL has on it. If you can't do that then here is what it should look like:
Obviously, the line that I added to the .xml file can't be added to the source generated by the ReadViewEntries command. To this end it is not possible to reproduce the above effect in practice. However what I hope to have introduced to you is the basis of the principles involved in XML processing. Future articles shall take this method further and show how we can actually use the technique in our applications. The key being that we can use JScript and the MSXML parser to parse the XML without the need to include the XSL refernce directly.
If you are planning on getting serious with XML then I highly recommend you consider buying yourself a copy of XML Spy from Altova Software. A very powerful tool that should help you learning these new languages in more detail than I can ever explain.
Note: If you are using IE5 or IE5.5 you may well have been surprised to see that the XML linked to above didn't parse as you'd expect. This is due to the fact that these versions ship with version 2 of the MS XML Parser. This only includes support for a working-draft of the W3C's XSL Recomendation whereas the more up-to-date version 3 supports the final release.
If you aren't sure which version you are using then have a read of the answer to the first question in this FAQ. This should take you to this Version Sniffer. When there you need to check that version 3 is installed and that it is in Replace mode.
You can get version 3 of the MS XML Parser here....