Monitoring Updates with XML and Java

June 23, 1999

Lisa Rein

XSA (XML Software Autoupdate)

Lars Marius Garshol, a graduate student at the Department of Informatics at the University of Oslo, developed XSA (XML Software Autoupdate) to help him maintain his Free XML Software list. Now XSA is being used by software vendors and developers get the word out about new products and updates.

Over the course of its development, XSA has evolved into an alternative distribution network, connecting content providers with products and software they might not otherwise have ever come across. Currently, 29 vendors and developers are using this XSA-based polling system to provide information updates to three different XML software directories: the Resource Guide, the Gershol's "Free XML Software" web site, and the software directory.

In this article, we'll go through the steps required for software vendors and developers to participate, as well as how software list maintainers can implement their own XSA client-side system. In the future, we'll take a more detailed look into how has recently begun using XSA to help maintain the Resource Guide.

How It Works

The process begins with a vendor using the XSA Wizard available online to create an XSA document describing the current state of every available product. This XSA document is then uploaded to a publicly-accessible URL, which is registered with XSA's central registry. Thus, a product is added to the master list of XSA participants, which is accessed by software list maintainers to create their polling documents.

To participate as a software list-maintainer, you must install a simple Java-based client that is freely available for download. With this client, you can create a different type of XSA document containing the list of product URLs that you wish to monitor.

Figure 1. The locally-run XSA Java client polls its list of provided URLs and compares the new information to its previous record of product information.

When a new product or an update to an existing products "happens", the vendor modifies its XSA document to describe the changes in detail, and then reloads the document. Such modifications, additions, and deletions can be automatically-detected using the XSA-aware Java-based client. Thus, the list or directory maintainer can detect updates by polling the documents of their preferred XSA vendors.

Ideally, the information retrieved by XSA will be used to automatically update a directory or list. Currently, however, most list maintainers manually update the information on their system after being notified by XSA.

The XSA client comes complete with its own general API to enable list maintainers to build a customized client application on top of its core "XSA engine" or integrate the XSA engine into an existing system, if they so desire.

No Hassle For Developers

In summary, here's the procedure for any vendor or developer to use XSA:

  1. Use the form-based XSA Document Wizard to create an ".xml" file containing technical requirements, product features, version date, documentation links, and contact information about the software or product.

  2. Upload the XSA document to a publicly-accessible portion of their web site.

  3. Register their document with XSA's central document registry.

Here is a sample XSA document describing the details of the xmlproc parser's latest update.

<?xml version="1.0"?>

<!DOCTYPE xsa PUBLIC "-//LM Garshol//DTD XML Software Autoupdate 1.0//EN//XML" 





    <name>Lars Marius Garshol</name>




  <product id="xmlproc">







The parser is now even faster, especially when validating. 




How Software List Maintainers Setup and Use the XSA Java Client

Setting up the command line Java tool that is used client-side by software list-maintainers can be a little hairy (particularly if you don't already have the required SAX-compliant parser installed), but once a software list-maintainer has successfully installed and configured the XSA Java-client, all they need to do is decide which products they wish to monitor, and create a simple XSA file containing the appropriate product URLs. The "product list" file can have either an "xsa" or "xml" file extension. Only the list-maintainers themselves will need to access their own product lists, so it is not necessary for them to be uploaded to the Web, and can instead be stored locally on the end-user's machine.

Lars provides a master list of vendors and developers currently using the XSA document format, and XML Tree, one of the participating software list maintainers, also has a nice listing of XSA participants, with a more complete description of each.

Here's a short example of the Product List Document


  <xsadoc url=""/>

  <xsadoc url=""/>

  <xsadoc url=""/>


To see the XSA system in action, run the XSA Java client from a command line window. Wait a minute or two, and then check your results. UNIX users might want want to run a cron job to poll selected XSA documents at regular intervals.

On Windows 95/NT, open a DOS window, and at the command prompt type:

java SimpleClient prodlist.xml file.sav

"File.sav" is a binary file that is dynamically-created to store any detected software update information.

The output can be viewed directly from the console or saved as a text file for later viewing by adding the following code to the end of the string:

java SimpleClient prodlist.xml file.sav> file.txt

I even wrote a little batch file to make it easy to run the client by simply typing: "xsacheck" at the command line (see xsacheck.bat, below):

@echo off

echo "Checking XSA documents"

java SimpleClient prodlist.xml testupdate.sav > testupdate.txt

notepad testupdate.txt

The above batch file causes the result output to pop up in a Microsoft Notepad window when the program has completed.

Here is an example of some output from the Java client:

XSA simple client, version 1.00, XSA version 1.0.

Product FOP has been updated to version alpha-0.7.1

Changes:  Added support for display- and inline-sequence    

Product DB2XML has been updated to version 1.1


DOM interface, tutorial on DB2XML usage, new online example. 

To test both sides of the equation for yourself, create a "dummy" XSA vendor document, upload it to your public site, and add its URL to the list of product URLs contained in a local XSA file. Then run the Java client, to see if you can detect your own update.

To see XSA's complete Document Type Definition, click here.


As simplistic as XSA is, it has the right idea: XML works great as a syndication-enabling format, providing a single solution for a few separate problems.

Independent developers and software vendors can use the format to assist in getting the word out about their latest products and updates, while software list-maintainers can use XSA to help them keep track of all the products and software-at-large.

Although a software list maintainer must install a configure a Java client to implement the system, the only requirement for a software or product developer to participate is the creation and upload of a single file (containing an XSA-defined description of their updated software). An online XSA document wizard makes this generation and registration process a non-issue.

The Resource Guide is proud to be one of the three XML Software Directories currently using the XSA software update notification system.


XSA  (XML Software Autoupdate)

XSA Specification

Software Vendors/Developers using the XSA Format