oXygen Users Meetup

Immediately following TIC 2013, I'll be attending oXygen Users Meetup in Munich, Germany. I'm very much looking forward to this one. I've been using oXygen for years and it is now my XML tool of choice. Also, oXygen's is the most responsive team in the world, frequently solving your problems even before you knew you had them.

It'll be good to meet George & Co again.

Open-source ProX

I recently got the go-ahead from my boss at Condesign to open-source ProX, my XML processing XML and its first implementation. It sounds rather more than what it actually is - right now there's a wrapper pipeline, an XForm, some XSLT and an example DTD - but I happen to think ProX is pretty cool and potentially useful.

I'll make the stuff available at Github as soon as I have the time, of course with a proud announcement here. In the mean time, you can get an idea about what ProX is by reading my Balisage papers ProX: XML for interfacing with XML for processing XML (and an XForm to go with it) and Using XML to Implement XML.

TIC 2013

I co-presented a paper about the oXygen/eXist solution I've been involved in building for The Federation of Swedish Farmers – LRF – at the TIC 2013 conference in Stockholm, Sweden. My co-presenter was Anders Johannesson from LRF, who is a brilliant, brilliant presenter. He is knowledgeable, funny and supremely engaging, and I had loads of fun.

Modular XForms?

I just read Eric van der Vlist's excellent XML London paper, in which he discusses the (lack of) modularity in XForms, caused to no small degree by the XForms MVC architecture, and, more importantly, offers solutions and workarounds. I really should have been there.

Having dabbled with XForms myself lately, I'm now very much looking forward to his talk at Balisage and the International Symposium on Native XML User Interfaces in Montréal, later this year.

Not One But Two Papers Accepted

Both of my papers submitted to Balisage were accepted. I feel honoured and somewhat nervous.

My second paper is a progress report of sorts and about ProX, my XML processing XML. I think it's going to be very cool, especially because I will have an implementation to show. I finished the wrapper pipeline to run everything with just the other day, and one day very soon that wrapper will do things with a live ProX (my processing XML format) document, including some actual publishing.

As the Balisage blurb says, life is good.

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. 

Micro XML and Namespaces

Micro XML is an attempt by James Clark, John Cowan and Uche Ogbuji to simplify XML and get rid of all that extra baggage that currently surrounds it. DOCTYPE and PIs are both removed, UTF-8 is mandatory, draconian error handling is no longer a must, and--perhaps most controversially--namespaces are gone, too.

Uche Ogbuji held a brilliant talk about Micro XML at the recent XML Prague 2013 conference, so rather than reiterating his arguments, I suggest you watch the presentation once it's made available at the XML Prague website.

What I did want to comment about is this namespaces business. Of everything proposed in the Micro XML spec, the removal of namespaces is clearly the most controversial, as indicated by the many tweets following Uche's talk. But should you be upset? I mean, really?

I've done some fair bit of XML stuff involving namespaces lately (yes, I know, there's no way to avoid it, really). There's a Relax NG compact schema that I wrote that uses several, including a default "". There are conversions from external XSD-based XML to that Relax NG-based XML using XSLT 2.0, and there are conversions from the Relax NG schema to (an obviously not namespace-aware) DTD to satisfy the needs of an editor that does not know what Relax NG is. (And I can't bring myself to write XSDs; they are the spawn of Satan.) And there are XProc-based pipelines that glue these things together, and they obviously need to be aware of the namespaces in addition to the ones they use themselves.

Lots of namespaces, in other words. And I'm not exaggerating when I tell you that a vast majority of the problems I had and the weirdness I encountered had to do with namespaces.

Nothing coming out from the transformation? A forgotten implied default namespace in the source XML. Namespace declarations in the target XML messing up validation? That same default namespace. The wrong prefix for the XLink namespace in the target XML? No explicit namespace declaration in the source. An unwanted and disallowed XLink namespace declaration being complained about in the root element of an XML document in the process of being checked out from a repository? A web service helpfully adding a seemingly missing namespace declaration to a root element into content in a SOAP envelope, resulting in a document that could not be opened but that did not show any problems in the repository itself, only on its way out...

These are just a few select examples from my plight, and while I may have some of the details slightly wrong here, you probably get the idea. The list goes on.

And why is this all happening? Because someone at some point thought that wouldn't it be nice if you could share your XML with everyone on the globe with no risk of name collisions and clashing semantics? Wouldn't it be cool if the conflicting schemas could all be identified using a URI? We could have a throwaway name prefix attached to that URI and implement processing that could hide the prefix for the end user, simplifying things further...

Of course, that someone's idea of backwards compatibility was simply that to a DTD, the revolution would be hidden in an extra attribute and an element type name containing a colon.

The fact is that I have yet to be helped by namespaces when using XML from the other side of the globe. In fact, I have yet to encounter a situation where I need to process unknown XML where potential clashes in semantics can do harm without me spotting the problem well in advance and taking care of it. The fact is that I don't often need to use XML from the other side of the globe, out of the blue. It tends to happen in a context, in a controlled manner.

But when I do process that XML, knowing full well the source semantics and how they can map to my needs, it is always the namespaces that cause me grief.

Namespaces are among the least understood features of modern-day XML and among the most abused. The tools range from helpful to disastrous to completely ignorant or just plain wrong, and there are as many reasons for this as there are XML parser implementations out there. You know right from the start that you will have problems, so you'd better resupply the medicine cabinet well in advance or get ready for that headache.

So, Micro XML? Yes, please. Now?

I Did Some Code!

Yesterday evening, I had an itch that needed scratching.

I was lacking some convenience features in an XMetaL-based authoring environment I am finalising for a client. There is a structure in the DTD that I am presenting as a table using some CSS in the editor, which makes perfect sense since it's always going to be formatted that way when published. Presenting a structure as a table in XMetaL, however, means that XMetaL will hide the elements defined as table rows; it's a side effect of how tables are presented in the editor and most editors have similar problems.

But where HTML or CALS tables are supported by XMetaL's customisations for tables (with adding or deleting rows or cells), my custom structure isn't. It only looks like a table, it isn't one because the actual semantics are quite different when studied in detail, and so the standard table functionality is not available. I needed custom code for my table-like structure.

Under normal circumstances, I'd simply walk over to a colleague, describe my problem and let him do his magic. There is something slightly twisted and evil in any object-oriented programming, and I usually want no part of it. You have an "object" that, depending on things you very often can't see or would not fully fathom anyway, have special magical abilities you can use to solve your problem, which is all fine and well, but very often, you also have a seemingly similar "object" that doesn't have those magical abilities. It instead possesses different ones, and because you are but a learner and only borrowing the magic wand, you eventually leave it be.

It's evil.

But this time, I thought "how hard can it be?" and started writing, aided by other people's efforts, an XMetaL Programmer's Guide, and an Ouija board (no, not really; just Notepad ++). Soon, those magical objects appeared with their special abilities, and I started invoking magic using while loops and other features I know from scripting languages. Remember Mickey Mouse in Fantasia? That's me, thinking "how hard can it be?"

The difference was that the magic here is better protected. Mickey never had access to Ctrl+Z.

Two hours later, I had my little convenience functions. The sorcerer has yet to return, but I am confident that my code works. The broom does what it's told to do.

Procrastination Is An Art Form

And I'm perfecting it.

Profiling Workshop

I'm going to hold a workshop on product information profiling for Föreningen Teknisk Information's annual spring conference on March 13-14 in Gothenburg, Sweden. The link target, leading to the conference web page hosted by FTI, is mostly in Swedish (sorry about that), but now you know.

Eric Ericson Has Passed Away

Eric Ericson, world famous conductor and choir leader, has passed away at the age of 94. Some might remember him indirectly as he was responsible for arranging and conducting Ingmar Bergman's The Magic Flute. Me, I've come to appreciate his interpretations of Bach's oratorios, in particular the St Matthew Passion recording from 1994, arranged using contemporary instruments only.

He will be missed.

The Death of a Profession

The 36th edition (actually the 35th, but that's another story) of the Göteborg International Film Festival started yesterday. I've been running projectors for the festival since 1987 and since 1990 as the projectionist at the festival's main auditorium, the Draken.

This year (and to some extent, last) is different from every other year.

When I did my first year at the Draken, out of around 50 feature film prints most were in 35mm. Those that weren't--I'm guessing one or two, without bothering to check the actual figures--were in 16mm. One (1) had stereo sound. All of the others were in mono.

This changed rapidly. In only a few years, all prints, excepting, perhaps, an occasional third-world effort, had stereo soundtracks. By 2000, several used Dolby Digital, Dolby's six-channel digital sound.

And by 2010, all had Dolby Digital, excepting restored archive prints from bygone days, screened as parts of retrospectives and such.

When the digital sound arrived, we didn't really consider it to be a revolution. Better sound, sure, but revolution, no. The prints were still in 35mm, handled about the same as always by the projectionists and causing the people who carried them from one cinema to the next bad backs and strained muscles. 35mm prints are heavy and carrying them around for ten days will cause you grief.

Last year, though, they installed a digital projector in my projection booth. Most films were still in 35mm, but I also ran a dozen or so shows digitally, many of them shorts. I'd upload a digital file from a hard drive to the server housed with the projector, "program" the show by dragging and dropping film clips, including the feature film itself, to a flow chart-like user interface on a flat screen, and finally click on Play when given the go ahead signal from the ushers.

The 35mm prints, on the other hand, are (and have been, for the last several decades) assembled from the six or so reels they arrive on to (usually) two larger ones. Those are then threaded into large projectors and handled manually, with a "change-over" taking place in the middle of the screening, hopefully invisible to the patrons.

Times, they are a-changin'.

Last year was just a mere warning of things to come, though. This year, the festival will be halfway over when I finally get to run my first 35mm print, and I'm only expecting four or five more of them.

But worse in some (to me) ever-so-subtle way is that they no longer provide us with a 35mm festival vignette to be spliced onto the first reel before shows. There are still a few 35mm prints, yes, but there are very few labs left to make them. One of the festival techs mentioned to me that he'd given up the idea after some research.

We had no vignettes when I worked my first festival in 1987, either. That was because the festival could not afford to make them. Now, 26 years later, they'd probably be too expensive to make, again. It doesn't feel like a full circle to me, but I guess maybe it is.

Worst, however, is that with the death of the 35mm format follows the death of a century-old profession, that of the projectionist. We are being replaced by IT people, people who know their way around a computer. A colleague who's been in the business since 1970 has real trouble using his new equipment at another festival cinema. He knows how to run a show but doesn't realise that you can "click" on weird symbols on a screen to access functions he needs. A window to him is something you draw the blinds on during shows, a mouse a living thing and a menu something posh restaurants give you.

In only a year or two, we are not only no longer needed, what we do now can be done by IT people from home.

And that's more than a little sad.

Final XML Prague Paper

I need to submit my final XML Prague paper on Sunday at the very latest. Now, what I would like to know is how tricky this cloning business really is.

oXygen Customisation

I finally got around to doing an oXygen-based authoring environment for a client. Well, what I did is a DocBook variant, plus some bits and pieces that differ from the oXygen standard DocBook offering. Be as it may, it was among the easiest, most straight-forward customisations I've done, and I've done a few. I did receive a few pointers from George Bina from Syncro Soft, the makers of oXygen (thanks, George!), but I really am amazed by the ease with which this is done.

The authoring environment is integrated with eXist, the XML database, and that part was very easy. It's all there. I didn't have to do anything beyond creating a few collections, user groups and new users. It simply works, and yet I'm implementing the Release Candidate (of eXist) rather than a stable version.

Pretty damned cool.

No, I'm not associated with Syncro Soft or the eXist development, and I'm not paid by them in any way, quite the opposite, but I've always heard that you should give credit where credit is due.