Document Engineering


At the InfoWorld SOA Executive Forum last week I met Bob Glushko who's on the faculty at Berkeley's School of Information, what they're calling the "i-school" (with no royalties to Apple, apparently). Bob's the director of the Center for Document Engineering. The mission of the CDE is to "invent, evaluate, and promote model-based technologies and methods that enable the automation of document-centric business processes and the implementation of business relationships as a network of document exchanges." As XML technologies have made documents machine-readable and automatically processed, the notion of engineering these documents has become more important.

Bob's also the author, along with Tim McGrath of Document Engineering : Analyzing and Designing Documents for Business Informatics and Web Services, a book I've had recommended to me by more than one person. I've ordered it and I'm anxious to read it.

When I spoke to Bob he mentioned that he'd just started blogging at Doc or Die. His latest entry references the SOA Forum and makes this statement about course-grained, doc-style vs. fine-grained, RPC-style Web services:

[T]he best argument for coarse document exchanges is that if you go that way you’ll be making a conscious design choice and almost certainly have invested some effort into designing the document models or evaluating standard document ones. The documents you exchange will more likely be ones that are easy to process because they’ll have unambiguous semantics and use robust code sets and identifiers. They’ll be easier to reuse across a range of related partners and services.
From Doc Or Die
Referenced Mon Mar 20 2006 15:15:45 GMT-0700 (MST)

RPC-style interfaces are almost invariably angle brackets around an interface designed for some other purpose.