Even a Paypal form is a web document. The customer wants to buy an iPod, so he goes onto eBay and through a PayPal form, quickly enters the correct information, and the result is that an iPod shows up at his or her door 2 weeks later. The clarity of the PayPal form, the speed, usability, functionality, and smoothness — all of this counts toward the perceived transaction. In this case, it’s a literal financial transaction too. But in many other instances the transaction is abstract.

But as far as “document” goes, my understanding is that it’s similar to the microformat — some type of XML model that gives best practices for a business practice. The XML is encoded into some type of form that structures the information against a schema. The structured information can be shared, reused, and syndicated. He mentioned the example of the calendar. Actually, the ical or vcal microformat (can’t remember which) is supposedly an XML structuring of calendar data that numerous calendar programs can interpret.

Well, this is my understanding. But I haven’t dug into his book or thought or researched this topic more.

I have to admit this one confused me a bit, and I’m still not sure if I understand what Glushko is getting at… My main hang-up is his definition of a document. Here’s Glushko in the introduction of his book:

“Documents organize business interactions and package the information needed to carry out transactions. The notion of documents as the inputs and outputs of business processes wherever they reside in the network is a technology-independent abstraction perfectly suited for the heterogeneous technology environment of the Internet.

“The essence of Document Engineering is the analysis and design methods that yield:
- Precise specifications or models for the information that business processes require.
- Rules by which related processes are coordinated, whether between different firms to create composite services or virtual enterprises or within a firm to streamline information flow between organizations.”

Being a technical writer designing, creating and maintaining technical documentation of software (and data-delivering platforms as it were), I find this too broad a definition to be useful.

His main definition points to what I know as “data” in “records” or “files” that can be delivered as “feeds” or imported via standard “protocols”, all of which are highly typified and standardized and require human intervention only in case of glitches.

Documents (and documentation by extension) in my world are less typified, they almost always require human intervention and are usually insufficiently specified, so the recipient frequently expected something else entirely.

So as a technical writer, I’m glad to be rather far removed from designing, creating and maintaining “documents” such as calendar events and syllabi. My marketable skills in IT are quite different: They only come in when different spheres need to be negotiated, connecting developers of software and customer care personnel to its users or vendors to prospects.

I actually think I’d take offense if someone asked me to define the “document” that’s the common denominator of 24 different types of calendar events…

Just my 2 cents, Kai.