In a post from quite a while back, I talk about eXtensible State Machines, a way to reduce a web application to an XML document. The original implementation was a stand-alone web application environment/framework written in Perl. The web has evolved since that initial work. We now have web 2.0, Ruby on Rails, and content management systems that are easy to extend (e.g., Radiant).
I was looking around the web for references about EAD, an XML vocabulary mentioned in a Digital Humanities Working Group meeting Monday. I could see cases where people would want to have documents marked up with both TEI and EAD.
"What publishing can learn from the iPhone" points in a direction I've been thinking about for a while: we need to lessen our tie to notebooks and desktops when interacting with data.
Part of this equation is Google Gears which allows offline interaction with web applications. When I'm in the store and want to know if I have a particular book in my library, or what that wine was that I enjoyed the previous week but can't quite remember exactly which one it was, I want to have access to the information I need so I can make a well-informed decision. I want to be able to update my catalog at the point of purchase instead of trying to remember to do so later after I get home. Maybe I'm in another city, or traveling. The closer in time I can make all the tasks that go together, the more likely I am to do all of them. Managing data syncing and allowing client-side storage of data enables this.
Something that web developers have been looking for, but haven't been able to do, is now possible with Google Gears. Namely, accessing a file from JavaScript. It still isn't possible to access an arbitrary file, but with Gears, you can access the contents of a file that the user has selected in a file input element.
The right way . . . is to separate the meaning of a program from the implementation details.Saying less about implementation should also make programs more flexible. Specifications change while a program is being written, and this is not only inevitable, but desirable.---Paul Graham, "The Hundred-Year Language"
Traditional programming languages divide a program into two parts: comments and code. The comments describe the goal of the code while the code describes how those goals are met. Bugs arise when the two don't agree. Most programmers would rather do one or the other, but not both. Doing both seems a waste of time because too much information is being duplicated in a way that can introduce mistakes. One of the primary goals of the Gestinanna project was to collapse the comments and code into a single descriptive document that would both describe the program and be the program.
One of the problems in web application design is the disconnect between traditional programming languages and the statelessness of the web. There are ways to work around this, storing session information in hidden fields, setting cookies and tracking session information there or on the server. There are languages designed for the web such as PHP and ASP. Traditional languages are made to work with the web: Java and Perl being two big examples. But none of these capture the nature of the client/server model fundamental to web applications. All of them require some reinvention of the wheel each time an application is built.