Programmers Are Interesting

Another great article from Sean McGrath: The mysteries of flexible software. Bang on the money.
I don’t know how many times I’ve encounted software (and yes, some of my own devising) that has all sorts of wonderful flexibility but in all the wrong places. Time spent factoring applications into layer cakes, introducing endless layers of abstraction may have some benefits, but exactly how often do you go through an application and rip out the entire persistence layer? And when you do, what’s the biggest hurdle: changing the code, or the data migration and testing involved to guarantee that you’ve not broken any of the data integrity? Exactly how often do you swap in and out XML parsers and XSLT engines?
I’ve been a keen advocate of design patterns for some time, but it’s easy to get carried away: achieving a particular design pattern (or set of patterns) becomes a requirement in itself and that in all likelihood isn’t going to affect the success of a product. The “Just Do It” aspect to XP is one obvious reaction to that experience. Renewed interest in more flexible, easy to author languages like Python is perhaps another.
Abstraction ought to be a defense mechanism. If a particular area of code or functionality is continually under change, then introduce some abstraction to help manage that change. Trust your ability to refactor. Don’t over architect too early.

The Info URI Scheme, Why?

I’ve been skimming through the info URI scheme RFC. From the Cover Pages we learn that the scheme “was developed within the library and publishing communities to expedite the referencing by URIs of information assets that have identifiers in public namespaces but have no representation within the URI allocation.“.
We also learn that “The motivation behind developing the info URI scheme is “to allow legacy identification systems to become part of the Web global information architecture so that the information assets they identify can be referenced by Web-based description technologies such as XLink, RDF, or Topic Maps. The scheme is concerned with ‘information assets’, not ‘digital assets’ per se, so the information assets may be variously digital, physical or conceptual.”“.
I’m trying to get my head around why it’s necessary to have a new URI scheme for this purpose — why not use a URN or an HTTP URI? For further discussion on that we have to look at “Section 7 Rationale” of the RFC.
One main reason seems to be passed on a desire to avoid any expectation of dereferencing semantics. Info scheme URIs cannot be dereferenced, they are for identification only. So the reason for not using an HTTP URI is because they can be dereferenced; one reason for not using a URN is because they’re encouraged to have a mapping to a dereferencable form.
Another reason for not using a URN is persistence of the identifier. A URN is supposed to be a stable identifier for a resource, but an info URI has no claims to stability. To be precise: “The “info” URI scheme is neutral with respect to identifier persistence
Unfortunately I’m still none the wiser to the actual benefits here. It seems that the info scheme gives me a non-deferencable, and in all likelihood non-stable identifier for a resource. Um, doesn’t that give us the worst possible scenario?
Being able to dereference a URI is an important quality IMO; and thats one reason I like RDDL. If I can do a GET request and get the resource, or some metadata then that resource is bound into the web infrastructure. If the location isn’t stable then following HTTP 3XX codes can lead me to the correct location. Redirection is one of the client-server co-ordination mechanisms that’s built into the guts of the web, why not use it?
More discussion on info URIs here.
I’ve not encounted a URI discussion that doesn’t have all sorts of hidden complexities so no doubt I’m missing something. Anyone else see any strong benefits of having a new scheme here?

The Fifth Sentence

Passing on a meme I caught from Norman Walsh. The fifth sentence on page 23 of The Diamond Age by Neal Stephenson is:

But while Lord Finkle-McGraw was not the sort to express feelings promiscuously, he gave the impression of being nearly satisfied with the way the conversation was going.

This isn’t the book I’m reading, that’s Foucault’s Pendulum, this was just on my desk in work as I’ve recently lent it to a colleague.

XML Processing Model

The W3C have posted a Note discussing requirements for an XML Processing Model. This is good news, there’s been a lot of desire to see this work progressing for some time now. Wonder whether XML Pipeline will serve as a possible basis for a specification? It seems to be a good match to the requirements.
It’ll be interesting to see how this ties in with the DSDL work which is essentially defining a validation oriented processing framework. Frustratingly there’s been little updates to the DSDL web site to see how far they’ve progressed. This xmlhack report seems to have the most recent summary of activities. Please update your site DSDL people!

Dashboard and Jabber

I’ve been thinking about writing some Jabber services or bots recently as we’ve been trialling a Jabber server at work as a replacement for the myriad different messaging services folk are now using.
I’ve been hunting round, unsuccessfully I might add, for something as easy to work with as PircBot a Java IRC Bot framework. Not that it has to be Java as I’ve been making baby steps towards learning Python.
Anyway whilst leafing through my copy of Programming Jabber I started thinking about Jabber’s extensibility and its use as an asychronous messaging component in a service framework. How might that be integrated with people-centric, desktop applications? And then I thought about Dashboard.
In the Dashboard architecture, cluepackets are used to send messages between front and back-end applications. Now what if there was a way to tunnely cluepackets through Jabber? Has someone explored this already?
There are some interesting possibilities here. Your front-end application may be talking to a backend on my desktop, e.g. whilst you’re browsing for new music a cluepacket may ultimately get routed to my local backend (RDF backed, naturally) which can respond with my reviews and recommendations.
Tie this in with buddy lists and you’ve got a neat way to mine a community (your community of friends and colleagues) for data without having to index it all in advance. For example it could be used to pull together calendar data so you can co-ordinate a trip with your friends.