XML at the Virtual Laboratory

I've started using XML at the Virtual Lab.  It is about time.  To do this, I'm using the textuality Lark XML processor and the Java Web Server from JavaSoft.  I've written a preprocessor for the server that dynamically turns XML documents into HTML documents.

What is, and Why use, XML?

If you don't know what all this means, I'll explain.  XML is one way of solving the static HTML page problem.  The fact of the matter is that any web site will get so complex that it becomes difficult to manage the web pages.  For one thing, if the layout changes, someone has to go through and change the layout of every web page in the site, or the site will have an inconsistant appearance.  For another thing, the people supplying the content aren't always the people you want controlling the layout, but with HTML this is norm.  One solution is to have a software package that extracts data from a database and inserts the data into an HTML template and presents that final document to the client.  This allows content to be separated from layout, and provides consistancy throughout the web site, regardless of changes to the layout; when the layout template is changed, all documents henceforth are served with the new layout.  Another solution is XML.  XML is a lot like HTML, only more general.  In HTML, the types of usabe tags are limited and are generally very closely linked to the layout.  In XML, this can be avoided.  For example, I'm using an XML DTD which allows me to write a document that looks like this:
<units>
<unit measure="Energy" value="Joules">
<unit measure="Mass" value="Kilograms">
</units>
This describes the data, not the layout.  Now, with my translator, this comes out like this:
 
<table border=0 width="100%">
...
<tr><td><b>Units</b></td>
    <td><table border=2>
        <tr><th>Measurement</th><th>Units</th></tr>
        <tr><td>Energy</td><td>Joules</td></tr>
        <tr><td>Mass</td><td>Kilograms</td></tr>
    </table></td></tr>
...
(the surrounding table is part of the overall document structure)  Notice that not only is the form that I enter much more compact than the final output, it is also much more clear.  On top of this, should I decide to change how I lay out the document output, I only have to change the translator, not the sourcecode.

Problems

I've had some problem getting the web server to pass my preprocessor a valid stream.  At this point, I've hacked it into a working state by directly opening the source XML file and bypassing the server's input stream.  I'd like to fix this, since, while it does work, it isn't strictly the proper way to do this.

Right now I'm doing 1:1 translations.  That is, I have a package for each conversion.  Since we're only outputting HTML, this isn't too bad (at this point).  I forsee several problems with this method, none of them very surprising; these are all well known problems, but I like to itemize them for my own cognitive and motivational processes.

  1. Changing the layout requires changing the Java translation classes, recompiling, and restarting the server.  The XS language, as far as I'm concerned, isn't any easier to learn than Java, but it does avoid all of the mess of getting the web server to recognize the changes.
  2. This 1:1 translation is fine, until we want to output to a format other than HTML.  The way I'm doing things now is complexity O(n*m).
  3. The proper way to do this is to support XS style sheets on the server side (or on the client side, but at this point in time we can't rely on that).  The translation problem then achieves a O(n+m) complexity.  The problem, of course, is that I have to write all of the XS support myself, and I scarce have time for this.

Current Progress

As of this writing, I've been very pleased with the progress I've made.  In the past 8 hours I've installed the JavaWebServer and written the servlet that does the translations.  I have two supported XML DTDs; the DTD support is almost trivial to implement, and most of the effort is in debugging and getting the layout to look the right way.  I spent way too much time discovering that a problem I was having was due to the web server not passing my servlet a valid input stream, and not any fault of my code.  I imagine that particular problem is going to be taking even more time to work out.  Also, I've been having trouble getting the Java Web Server admin tool to run in HotJava; it works fine via HTTP using the appletviewer in the JDK1.1.4, but HotJava barfs on the admin class.  That's another bug report I'm going to have to submit tomorrow.

Talk is Cheap

Why isn't everything I'm doing in XML?  For one thing, nobody has written an XML word processor yet :-)  The primary reason, however, is that I don't have enough time to write translators for side projects, like this document.  On top of this all, I really want to get XS support before I convert everything.  For now, I'm concentrating on the VLab, where this technology is needed most.  I'll let my own web page suffer along until I get XS support.