…is pretentious and boring.
I mean, really? What were you thinking? That, after a dozen shows, anyone would still even pretend to like it?
Please, filmmakers: Don’t quit your day jobs. If you have them, that is.
The annual Göteborg Film Festival is almost upon us, with only two days left when I write this. 11 days of film and, for me, 11 days of clicking Play because it’s all digital now, with the exception of one (1) film.
I’ve written about the advent of digital film before, but also about the death of a profession, and while I briefly considered another stab at these two subjects, I quickly came to my senses; I feel that I’ve said pretty much everything I have to say on the subject. This year’s festival is merely a confirmation of those two blog posts, and there is little reason to reiterate any of it.
So I’ll write about the death of a cinema instead. More specifically, my cinema, the Draken, until recently the last surviving Cinerama theatre with its original appearance intact, until last summer mostly unchanged by both the ravages of time and pitiful small-screen multiplexes. It survived them both, although Svensk Filmindustri, Sweden’s only cinema owner of note, did have plans to convert the theatre into a double-screen abomination in the early seventies.
What it didn’t survive, in the end, was the long-planned “renovation” by its owner, Folkets hus, a k a Sweden’s working class movement. The original 1950s chandeliers were thrown away and holes cut into the marble walls to lead the way to toilets forced into the space under the auditorium. Light riggings were carelessly hung up in the auditorium itself and computer-controlled fluorescent lights with only nominal dimming capabilities were allowed to replace the old auditorium lighting.
And in the large upper foyer, the maritime-themed painting that used to be the pride of the cinema has now been replaced by a motorised conference screen. My cinema has now been reduced into a pathetic two-screen cinema. Or, rather, conference hall. Well done, Folkets hus.
Those closest to you are the ones that can hurt you the most.
…most of the ProX stuff is available at Github. Not the eXist web pages, yet, but that’s because I’m still experimenting with them and there’s some work left. There’s the Balisage demo, and there’s the basic ProXist stuff, with pipelines and XQueries and such, and there’s the authoring environment (with Relax NG schema, FO, etc), but no instructions on how to get any of it to run, yet.
I have a test app running locally, a little something that is about as simple as I can make it, but since I am not a web developer (I’m a markup geek), the HTML is awkward, the CSS nonexistent apart from the default eXist stuff, and the XQueries somewhat painful. I do think it’s going to be pretty cool, though, and look forward to presenting it at XML Prague.
I recently submitted the final version of my XML Prague whitepaper about my eXist implementation of ProX, called ProXist (with apologies for the tacky name). While I’m generally pleased with the paper, the actual demo implementation I am going to present at the conference is not quite finished yet and I wish I had another week to fill in the missing parts.
Most of the ProXist stuff works but there are still some dots to connect. For example, something that currently occupies the philosophical part of my brain has to do with how to run the ProX wrapper process, the one that configures the child process that actually does stuff to the input. ProX, so far, has been very much about automation and about things happening behind the scenes, and so I have aimed for as few end user steps as possible.
My Balisage ProX demo was a simple wrapper pipeline that did what it did in one go. Everything was fitted inside that pipeline: selecting the input, configuring the process that is to be applied to the input in an XForm, postprocessing the configured process and converting it to a script that will run the child process, running the child process, saving the results. Everything.
But the other day, while working on the eXist version and toying with its web application development IDE, it dawned on me that there doesn’t have to be a single unified wrapper process. If its components are presented on a web page and every one of them includes logic to check if the information from a required step is available or not (for example, a simple check to confirm that an input has been chosen before the process can be configured), they don’t have to be explicitly connected.
The web page that presents the components (mainly, selecting input and configuring the process to be applied on the input) then becomes an implicit wrapper. The user reads the page and the presentation order and the input checks are enough. There is no longer a need a unified wrapper process.
Now, you may think this is obvious, and I have to admit that it now seems obvious to me, too. But I sometimes find it to move from one mindset (for example, that automation bit I mentioned, above) to another (such as the situation at hand, the actual environment I implement things in) as easily as I would like. If this is because I’m getting older or if it’s who I am, I don’t know. In this particular case, I was so convinced that the unified wrapper was the way to go that it got in the way of a better solution.
At least I think it’s a better solution. If it isn’t, hopefully I can change my mind again and in time.
See you at XML Prague.
I’ve been working on an eXist-based implementation of my XProc abstraction layer, ProX, hoping to have something that runs before XML Prague, next month. It turns out that the paper I submitted on the subject has been accepted, so now I guess I just have to.
The ProX implementation should not be terribly complicated to finish, but until recently it risked to be rather hackish (is that a word?) because the XMLCalabash eXist module written by Jim Fuller was rather primitive: it would only support pointing out the pipeline to run and one, hard-coded output port. I foresaw a more or less complete rewrite of the ProX wrapper in XQuery.
Luckily, Jim very graciously agreed to rewrite his module into something more immediately usable. I received the first updated module to test in December and the most recent update just a few days ago. He also found a bug in Calabash’s URI handling and sent a first fix to me along with the updated module. There are still things to do but for me, Christmas came really early this year.
Oh, and I’m calling the implementation, and the paper, ProXist. Sorry about that.
Title says it all. Happy new year, everybody!
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.
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.
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.
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.