I'm in a session on enterprise information integration. First up is Bob Glushko, who's talking about document engineering. He's writing a book, it's late, and here's why. Even though he used a comprehensive Microsoft Word stylesheet to ensure maximal control over the content, a lot of stuff didn't survive the transition to Quark. Crazy, huh? Here's a guy who's capable of writing directly in XML and transforming to HTML -- that's how he built the slideshow he's showing us -- and his book is stuck in a publishing bottleneck. In the short run this may be a Bob Glushko problem, but really, it's an MIT Press and Quark problem.
The gist of the talk is that data and documents live along a continuum, but we approach them from two different perspectives. We tend to deal with data in a top-down process-oriented way, and with documents in a bottom-up user-oriented way, and these traditions have got to meet in the middle. I violently agree.
Next up is Roy Fielding, chief scientist with Day Software where, he says, he's working to recapitulate principles of web architecture in the realm of enterprise applications. The problem: siloed applications that manage their own content repositories and present their own APIs. The proposed solution: JSR 170, which specifies a standard API that Java apps can use to access diverse APIs and repositories. The incubator for the reference implementation is called Apache Jackrabbit.
There's skepticism in the room. Universal repository initiatives have come and gone, people are saying, and the benefits are clear, but will infrastructure vendors -- Oracle being the most obvious litmus test -- really get behind this one? Fielding's bet is that they will, in part because of the open source nature of the initiative.
Not every content management system runs on the Java Virtual Machine, of course. What about non-Java systems? Another way into the API is WebDAV which, Fielding says, maps nicely to JSR 170.
Former URL: http://weblog.infoworld.com/udell/2005/04/11.html#a1212