Title: Members' Experiences

The Apache Cocoon™ project is an open source XML publishing system, written in Java. Because of the recent prevalence of XML (eXtensible Markup Language) and a host of other related acronyms, I gave the idea a try.

If you have written any Web pages then you hopefully know what HTML looks like. HTML (Hyper Text Markup Language) is a "markup" language - it puts "tags" around text to suggest formatting and so forth, which is rendered by a Web browser. An XML file looks very similar to an HTML file, except that the meaning of each tag is not defined - how to interpret the file is up to the parser. This makes XML a popular format for data files with arbitrary hierarchical structures; a good XML library takes away most of the work of writing your "saving and loading" code, and you stand a chance of exchanging data with other XML programs (although this is ridiculously over hyped - XML does not magically make all programs compatible with each other; you still have to interpret the tags correctly).

XML also has a stricter syntax than HTML (and indeed SGML, the Standard Generalised Markup Language, from which both HTML and XML are taken). For example, in HTML, some tags, such as <H1>, need closing tags such as </H1>, but other tags, such as <HR>, are not closed. In XML, every tag must be closed (you can abbreviate by writing, for example, <BR /> instead of <BR></BR>). This restriction simplifies parsing and validation. There is a variant of HTML called XHTML, which is XML compliant (every tag must be closed); existing Web browsers have no trouble with it because they just ignore the surplus closing tags.

The idea behind XML publishing is to separate the "content" (the textual data in a document) from the "presentation" (the layout and formatting that a Web browser might perform). XML tags can be used to indicate the abstract structure of the data they enclose, such as <news-item>, <weather-report>, <example> and so on; how to translate these into actual formatting is specified in a different file (which might be maintained by a different person). The potential advantages of this separation are obvious: Content and presentation can be independently maintained and debugged; there can be different versions of the presentation for different browsers, media types (not necessarily limited to HTML), intended audiences, and so on; presentations can select relevant data out of the document rather than having to display all of it; and any text that is presented in multiple places need only be written once. Note that XML does not actually enforce any of this; you still have to use it properly.

Before XML was all the rage, there was CSS (Cascading Style Sheets), which went some way toward separating content from presentation by separating off details like fonts and colours. CSS is a "client-side technology"; its processing is done by the browser, which means that if you do not want the style sheets then you can turn them off (if you know how), use a browser that does not support them, or get my access gateway to quietly remove them. However, CSS does not really go far enough from the XML point of view; a paragraph is still a paragraph and a table is still a table, no matter what its fonts, colours, borders and margins are, and you still cannot edit a document's content without thinking in HTML. XML allows more abstraction, and because it is "server-side" (the browser only sees the HTML result), it does not introduce additional browser compatibility issues. However, XML is not a replacement for CSS; they can be used together (although you still have to be careful with CSS because there are so many buggy browsers out there).

Emacs has a mode for editing XML. You can write a Document Type Definition (DTD) file, which lists the names of your tags (and attributes) and specifies how they are related to each other (what can go inside what); Emacs can then help you by checking for errors, telling you which tags are valid at the cursor position (and inserting them for you), doing your indentation, hiding away the tags that you don't want to see, and maybe highlighting it all in different colours, but you have to give it the right commands (or put them in your startup file).

Before I could download Cocoon, I tried transforming an XML file into HTML with some "search and replace" operations (first with sed, then with perl). This was surprisingly effective, but it was limited, sometimes difficult, and not very robust. XML publishing systems like Cocoon use scripts in a language called XSL to transform the XML into HTML. XSL is a mixture of HTML (actually XHTML) and processing directives, built around "templates" that match the tags in your XML. XSL files can include other XSL files, call procedures in them, set variables, test conditions, and so on.

Cocoon is based on a Java "servlet" that renders the XML (using an XSL stylesheet) "on the fly" when the document is requested by a Web browser (it does cache documents it has already rendered). Installation is complex, but it is easier to install it as a "package" from a Linux distribution (I installed the Debian package).

At the time of writing, Cocoon is very much under development; many features (such as XSP) are not yet implemented. One problem with writing about a large open source project is that it may well have moved on by the time the article is published. Nevertheless, I found a number of shortcomings in Cocoon 1.5 and I feel I should at least mention some of them.

For a Web server, Cocoon is slow, particularly on the first request of a page; it sometimes takes several seconds to respond on my 150MHz processor. The Debian package has scant documentation on XSL; you have to look at examples, use trial and error, or decompile the program. Some parts of the XSL processor are case sensitive, which is not intuitive in markup languages and can be a trap. The XML parser is not fully internationalised; certain character set encodings, such as the ISO-2022 encodings of Chinese, Japanese and Korean, can confuse it (you can still use these languages but you have to encode them in EUC or UTF-8). The XSL commands to examine the browser's query string do not work at all, and the XSL "include" commands must be given absolute pathnames. Error reporting is scant; if you do make a mistake then you might end up with the raw data in your browser, and then Cocoon's cache will not recognise any changes to the XSL until you update the time stamp on the XML file itself. And although an XSL file is itself an XML document, Emacs cannot treat it as such because its "psgml mode" does not support XML namespaces (":" in tags), so you have to edit XSL files in Fundamental mode (this is not Cocoon's problem but it does make debugging more difficult).

At university I help maintain a website for one of the Chinese societies, and I moved it to XML with the aid of Cocoon. The use of XML allows the committee to make changes to the content without having to worry about the complex HTML that their design requires, and the XSL stylesheets can make sure that the various indices on the site are kept up-to-date and the different versions of each page (default, "noframes", and text only) are kept in step. Writing and debugging the XSL files was more effort than I had anticipated, and the site still needed a shell script to get Cocoon to process the files and save the resulting HTML, because this was the only working way of applying more than one XSL stylesheet to the same XML file and allowing the user to choose between versions (and anyway the site had to go on an ordinary Web server).

Given its prevalence, XML is probably worth knowing about, and XML publishing can be useful for managing complex websites, although I would not recommend moving every website to it just for the sake of keeping up. Cocoon shows promise (especially as an Apache project), but only time will tell if it becomes as common as the Apache Web server.

ED™ is an editor that runs under Unix. It is hardly an ideal programming environment by modern standards, because, rather than displaying the file you are editing and letting you cursor through it, everything is done at a command prompt that accepts cryptic-looking commands to edit a line at a time, and there is very little on-line help. It s a bit like a more powerful version of DOS's EDLIN™ (which was based on it), or the 'editor' that came with BBC BASIC™. So why bother with it nowadays?

The answer is that, particularly if you are involved in Unix system administration (or trying to help someone to install your software), then sooner or later you may have to edit a file using a machine with a telnet client that does not know how to position the cursor and therefore cannot run a full-screen editor, or does know how to position the cursor but is full of bugs that corrupt the display when it does so. Alternatively, you might be doing the same when the remote machine is over a very slow link or on the other side of the planet, and the latency destroys the ease of full-screen editors. I've been in that situation and I found a rudimentary knowledge of ED useful.

ED is invoked by typing "ed" with a filename, and usually responds with the size of the file in bytes. It then waits for a command, such as 1,10n to list lines 1 through 10 with line numbers ('l' instead of 'n' lists without line numbers; this is less useful because practically anything you do with ED will involve knowing about the line numbers). $ represents the last line in the file, and offsets are possible, so $-9,$n lists the last 10 lines and 1,$n lists the entire file (with paging). The "current" line is represented by . (dot); this is initially the last line (so you can type ".a" to append to the file) but is usually set to any line you "do something" with.

For small configuration files, this may be all the navigation you need; you can view the whole file and decide what to change. To change a line, use "c", e.g. 27c changes line 27 - just type the replacement text (it may be more than one line) and end by typing a single dot on a line of its own (as in the SMTP protocol). You can also insert lines - 27i inserts before line 27 and 27a appends after line 27. 'd' deletes (so 1,5d deletes the first five lines). Change ('c') is essentially delete and insert (so you can give it a range of lines too). Also worth knowing is "wq" (write and quit), "q" (quit without saving - you have to enter it twice if the file has been modified), and "u" (undo - but it only remembers one operation).

For larger files, ED's regular expression facilities are useful. /x/ finds the next line containing x (?x? searches backwards); both of these are used in line numbers, so /x/+1n means list the line after the next line containing x (errors can happen if you try to list lines beyond the beginning or the end). A small edit will often take the form of

/x/n

.c

to find (and list) an occurrence of something and then change the line it is on.

There is also a search and replace facility; 1,10s/A/B/g/ means replace all (g=global) occurrences of the regular expression A with B, in lines 1 through 10. A number can be substituted for the 'g' to mean replace only that occurrence (1 for the first occurrence and so on). Note that in all cases we are dealing with regular expressions (like grep uses), not simple search strings.

When dealing with a slow remote machine, it helps to go into "line mode" so that a whole line of input may be edited locally before it is sent to the remote machine in one go. On most telnet clients this can be done by going into command mode (usually Control-']') and typing "mode line"; you may have to do this twice (for some reason).

Season's Greetings and best wishes for the coming year from all who write C Vu to all who read it. Remember we need each other. Let us make 2001 even better than 2000.