Category Archives: markup

Balisage 2013

My paper was accepted for this year’s edition of Balisage, the markup conference held in Montréal, Canada in August every year. I’m going to talk about profiling XML using an abstraction level to avoid the problems associated with using plain values.

I’m really, really excited and honoured. 

Balisage Impressions, At Long Last

I tend to write these “long time no post” posts from time to time. It’s a guilt thing, I suppose, and it’s how this post began life.

This time, though, I did have things to write about. There is the Balisage 2012 markup conference I attended two weeks ago, and it would be such a waste not to post something on it. I gave a paper there, my little something on how to implement XProc with more XML, and I even participated in MarkLogic’s demo jam with even more of the same. Great fun, that.

The most fun I had at Balisage had to do with listening to others give papers, however, with special mention having to go to Wendell Piez‘s talk about how to process LMNL (non-XML) markup. LMNL is all about overlapping structures, the kind of thing that XML just won’t do, and it’s absolutely awesome. For some reason I’ve not given the overlap problem (or, for that matter, the related problem with discontinuous structures) much thought lately. I should have. LMNL, it seems to me, should be very useful for analysing dead languages such as Middle Egyptian where overlapping markup could be used to present alternative interpretations for grammar, pronunciation, and so on. There’s a paper begging to be written, right there. Next year, maybe.

It is good sometimes to remember that XML is not the answer to everything.

But there was more, a lot more. There were some excellent presenters, such as Steven Pemberton discussing abstraction errors (among others, in the C language), Norm Walsh with his compact XProc syntax proposal, and, of course, the undisputed king of keynotes, Michael Sperberg-McQueen, who, as Eric van der Vlist tweeted, “has a special gift to make each presenter feel clever in his closing keynotes.” And so many others.

And I really should mention Betty Harvey’s talk about implementing low-cost electronic documentation for a DoD contractor. In glorious SGML. I love history lessons, especially in my chosen field, and Betty’s was a stroll down memory lane.

Anyway, Balisage was fun and you really should have been there. Or maybe not if you aren’t into markup, but if so, why are you still reading this?

Balisage 2012

I’ll be presenting a paper at Balisage 2012 in Montréal, Canada, in August. For those of you who have no idea of what I’m talking about, Balisage is is a conference on markup, a sister conference to XML Prague, and, together with the latter, a markup geek’s wet dream. The conference is not just about XML (although quite naturally, XML takes up a lot of space), there are all kinds of topics related to markup theory and practice, including all those semantics you really can’t formalise using XML.

Balisage, along with XML Prague, is also a conference where the discussions that inevitably follow the presentations are actually on topic and intelligent. It’s a very humbling experience to stand before a crowd of experts that can and will spot any flaws you might have in your slides, suggest improvements you never thought of and generally offer valuable insights. It’s a forum for learning, whether you are a presenter or a part of the audience.

I’m really, really looking forward to August.

An Even-Simpler Markup Language?

in his blog, Norman Walsh writes about an even-simpler-than-Mixro-XML markup language, inspired in part by John Cowan’s XML Prague poster and by James Clark’s Micro XML ideas. His ideas are well worth a serious consideration–Norm’s ideas are always worth considering–but the purist in me cringes at the idea of allowing more than one root element. I have to say that I find the idea attractive but I’m not really big on change so maybe that is why I hesitate.

The pragmatist in me, on the other hand, also cringes at Norm’s not doing away with namespaces when he has the chance. in my experience they always create more problems than they solve, but on the other hand, my experience tends to be more about strictly controlled environments where the issues one usually wishes to solve using namespaces can be dealt with using other means.