I think students of information systems design have a tough time compared to other designers, architects and graphic designers say. A budding architect might have lived and worked in dozens of building, visited scores more and seen hundreds before they start to design their own. Information systems designers have no such grounding in examples, their prior experience sometimes confined to being the victim of poor systems.

The web has improved this situation, particularly for interface designers, but it is still hard to see into the guts of an application to learn about database structures and software architecture. Web applications do have the wonderful advantage that they can be explored, and I exploit this feature in my teaching, getting students to take well-known sites like Flickr and del.icio.us and infer, through source viewing and experimentation, the underlying conceptual data model. This works well but only occasionally can we compare our speculations with the real thing. It would be great if more sites had their systems documentation online.

I recently came across Raymond Yee’s book, Pro Web 2.0 Mashups, a spin-off from his teaching at UC Berkeley (named I only discovered recently after the family of the nearby Berkeley Castle) . I’ll be using Raymond’s book on one of my courses next year, especially since the text is generously available online. Amongst guidance on the use of a number of mashup architectures, the book contains detailed descriptions of the URL languages of sites like Flickr. Reading his book, I realised that the understanding of this language was an implicit step in the inference of the underlying data model which I had hitherto neglected to address formally in my teaching.

As far as I know, there is no equivalent of WSDL for REST so in best NIH fashion I set about creating my own XML schema for documenting URL languages based on URL templates. Here is my attempt to define the del.icio.us language. Parameters are defined first, with local names, explanations, default values and option list if applicable, followed by templates for the URLs which invoke services. An XQuery script reads the interface definition and creates a page with a form for the user to change the parameter values followed by the service URLs with each template completed with the current values of its parameters. The script is described in more detail in a chapter in the XQuery wikibook.

We are using this tool in our internal applications as an interactive site map cum interface documentation. Next year’s students can look forward to recording their understanding of web sites with this schema. Now who’s going to tell me there’s already a standard out there I’ve missed!