Apr 212009
 

One of my cur­rent pro­jects is as Course Dir­ect­or for the revamped XML Sum­mer School in Oxford, Eng­land. John Chel­som asked me to help out and I was only too happy to say yes; I have many fond memor­ies from pre­vi­ous years. It will be more a late-sum­mer school this year, being from Septem­ber 20–25, but that does free up more of the sum­mer prop­er for oth­er things, not to men­tion giv­ing us more time to fig­ure out the sched­ule and speakers. 

Anoth­er advant­age of late sum­mer for the XML Sum­mer School is that it does­n’t clash with Bal­is­age in Mon­tréal, Canada, which is on August 11–14 (with the sym­posi­um on pro­cessing XML effi­ciently on the 10th). Papers for that are due on April 24, so you don’t have much time to get them in if you’re plan­ning on speak­ing. Any markup-related top­ic is wel­come, as long as it is of suf­fi­cient qual­ity and depth.

It’s inter­est­ing com­par­ing the two — Bal­is­age is a geek’s con­fer­ence, unapo­lo­get­ic­ally aimed at people who are think deeply about the issues, even if they’re not apply­ing them at work. The XML Sum­mer School is more like train­ing, aimed at less expert prac­ti­tion­ers of and new­comers to XML, and more likely to be atten­ded by people who want to go back to work the next week and apply what they’ve learned dir­ectly. A few of the speak­ers are the same, of course, and the dis­cus­sions over din­ner tend to veer in some of the same directions. 

And, of course, both con­fer­ences are on Twit­ter; Bal­is­age at http://twitter.com/Balisage and the XML Sum­mer School at http://twitter.com/xmlsummerschool.

Mar 182009
 

I’ve nev­er been to one of the really big con­fer­ences with thou­sands of people; I’ve heard the energy can be amaz­ing, and there is always some­thing inter­est­ing going on. I tend to find myself at smal­ler con­fer­ences where you have a chance to see people again whom you saw in the last talk, and can ask a ques­tion of a speak­er in a quieter moment than the imme­di­ate post-talk rush. 

Which is a way of remind­ing those inter­ested in the finer details of markup tech­no­lo­gies (XML, SGML, and oth­er related tech­no­lo­gies), that sub­mis­sions for one of my favour­ite small con­fer­ences, Bal­is­age, are due in a little over a month (April 24th, to be pre­cise). I’ve signed up to be a peer review­er, though I haven’t been act­ive enough in markup research and tech­no­lo­gies recently to sub­mit a paper myself.

If you are writ­ing a paper, I have some requests to make my life as a peer review­er easi­er (and make it more likely that I recom­mend your talk be accep­ted). Please explain what it’s all about clearly, defin­ing terms that may not be famil­i­ar to every­one, and above all, explain why it’s inter­est­ing! Too many papers I’ve seen assume that out­siders will magic­ally under­stand what’s valu­able; usu­ally a poor assump­tion. Spell-check the whole paper, and get someone else to proof it look­ing for gram­mat­ic­al errors, sen­tences that ramble on for too long, and phrases that make no sense. The tone should be pro­fes­sion­al but not bor­ing, as I will be mak­ing assump­tions as to wheth­er you can give a good talk based on the paper you sub­mit (it’s a blind review, so I won’t know who you are when I review your paper). And do fol­low the guidelines; they’re there for good reasons.

And the most import­ant thing, fail­ure to observe which res­ul­ted in my recom­mend­ing talks not be accep­ted last year des­pite poten­tially inter­est­ing top­ics: make sure the paper is long enough! A brief sum­mary with details to be filled in later is not suf­fi­cient to let the peer review­er know wheth­er there is real sub­stance that can stand up to 45 minutes of present­a­tion and discussion.

/* ]]> */