CSW Summer School, Oxford 2005.

Homewards bound after an enjoyable week in Oxford at the CSW Summer School, I set off on a train from Oxford at 9:30 a.m. Northwards for Birmingham. I chose that route avoiding London after the last two bomb incidents. On reaching Birmingham I was informed that my 11:24 train was firstly late, then cancelled, due apparently to one of BR's famous incidents, which seems to cover a multitude of sins ranging from a mechanical problem to a suicide, but almost certainly including a bomb alert. The problem seemed to be in Leicester, since all trains on that route were slowly cancelled. Sat around patiently and then approaching noon I was told that the track through Leicester was closed indefinately. Asking for alternatives, I was told of a route North to Leeds, then South again on the main London Edinburgh route. My arrival time in Leeds was 1 minute after the departure of the first train I'd been given; hence I wasn't hopeful. However, I changed platforms and lo and behold, the guard was ready, the train was there, so I hopped on. One of those rare occasions when changes worked, and worked well to the n'th degree. I settled back for an hour and twenty minutes journey South, even managing a sandwich from the trolley on the train. Then.... sods law took retribution for the smooth connection. Probably about five or six miles outside my final destination, the brakes slammed on and we stopped in rather a hurry. Wait. The staff announced a technical problem with the train, we'd be kept informed. Fifty minutes later, and after the fourth message telling us nothing (but apologising nevertheless), we were told of an attempt to limp into Peterborough at low speed. Another ten minutes passed by with no movement. Seven hours travelling, and I'm tantelizingly close to home, yet so far away!

After stopping for an hour and ten minutes, we slowly drew away at a speed which seems likely to get us into Peterborough before it gets dark! Keep your fingers crossed! It does indeed. First train was 09:30 from Oxford. Alighted in Peterborough around 16:45. Nice on British Rail et al.

Whilst waiting. The conference. Summary? A good week. John Chelsom seems to find a happy mix of good technical sessions (at least on the track I attended) and fine evenings out. Punting, a formal dinner, a pub crawl and dinner at the Ashmolean museum after a tour!

The presentation that sticks in my mind, and has been churning round and round since I heard it, was from Sean McGrath of Proplyon. His blog if you are interested. He is a good presenter, has a sense of humour ideal for technical presentations, and to me anyway, found a way of introducing ideas by sidling up to them, then dripping them into the flow almost without us noticing! I'd previously asked him directly what his talk was about, but he gaily sidestepped answering, as a tempter to go, which I did. Well, what would you have deduced from a title such as "Chameleons, Platypus, Snakes and Ants."

He opened with a story about his mum's cooking which proved almost but not quite a total diversion. The end game was worth it, the meanderings and comical interludes kept the journey pleasurable, so I certainly don't regret attending.

Sean has a way of seeing more than the basics, perhaps more insight than some, and draws lessons from odd places which seem to add perspective and provide the glue that makes it stick in my mind. Go listen to some of his stories, this also has some of his stories in mp3. Judge for yourself.

Returning to my view of his message, from his presentation. I concluded some time back that administrative type people simply don't get, and don't want to use XML editors. Sean (if I interpret him rightly), is faced with customers who have authors. My experience is with people editing existant text. There is overlap, possibly more than I acknowledge. Either way, a part of the task is working with broken documents. Broken documents, as Sean calls them, are the bread and butter of the editor. "A work in progress is structurally broken by definition" as Sean put it. I've quickly rejected editors that don't allow work on a broken document (invalid to the specified DTD) but I've never taken it a step further and sat down to think about solutions to this problem.

Sean presents the idea that presentational markup to a quite loose Schema may be appropriate for the editor to dump his or her ideas onto the screen. Even more attractive to me is the idea of using colour to inform the editor that the markup is right. Could be green headings and blue paragraphs. If I see two headings in succession, something is wrong. Quite appropriate in that environment. His realisation of this is taking advantage of the XML export from Open Office, or even Microsoft Office. Utilise the styles to reflect markup semantics of blocks and inlines, ignoring structure. That is said to appear once the content is available. It is certainly more in the domain of the engineer than the editor. Exporting the XML from the Word Processor provides a means of access to the author or editors output. Next is the turn of the ant. Using microtransforms, staged validation and conversion to the same document content takes place, but structured and more aligned to downstream processing. Early validation is simply to the applicable business rules. Schematron is Seans choice here. Tiny steps enable simpler tasks to be completed, just as the ant moves whole trees a bit at a time. The resultant output will be to a different schema for use in other XML processing pipelines. It's the editorial environment, schemas and output transforms and validation that intrigue me.

Another point that arose was this idea of structure, or at least depth of structure, should be questionned. In another thread I'm asking if I really need the <ol> element around a series of <li> elements which define a list. I know that I can transform such a file to add it if needed, so why add it. Containing structures could be questionned in the same manner. Do I really need nested sections? People seem to deal in sections, but the reality is some form of heading and some content. If I can process such a sequence, and pick out sections, I've achieved what the engineer wants, whilst leaving the author to think in the way they do naturally. Perhaps empty <break class="subsection"/> class of entries in a file might be sufficient? I'm sure the authoring environment could provide something along those lines if needed. I took this further, and wondered what docbook might be like, with only the content holding block level elements and inlines. Could it work well enough?

The last challenge Sean threw at me, and I was happy to catch, was the idea of the appropriate schema. This matches well with DSDL's idea of variant validation. Again using docbook, there are probably 12 block level elements that I use enough to remember. Why not put those together using the Relax NG interleave pattern (& for those who remember it from SGML). Basically an unordered selection. This would meet the needs of the author, more interested in content than sequence, and may be enough to keep the back office engineers happy, if and only if, an appropriate structure for later use can be generated. I've been considering things like metadata. Does it really matter if one of the metadata elements is midway through the book (since that was when the author remembered it was need by the business rules)? It isn't magic to collect all the metadata elements into an appropriate collection and add a wrapper element. I'm not wholly convinced, but the logic is certainly well worth investigating.

Either way, I'm sure I'll be doing more thinking and playing in this area. Thanks Sean.