Re: Climbing Clueful Mountain

Rohit Khare (khare@w3.org)
Fri, 04 Apr 1997 21:08:20 -0500


Mark Baker wrote:
>
> On Fri, 4 Apr 1997, Ron Resnick wrote:
> > (This is a big part of the
> > confusion here, I think- I'm quite against the whole notion of document-centric computing,
> > and compound documents as terminology. I think documents are *not* a good metaphor
> > for the daily activities networked bits are going to permeate in our lives. When
> > I go shopping or drive my car or have a beer, there are no "documents" involved.
> > But the networked bits will be in all these places, and more.
> > I think the Taligent "people places things" imagery, and the Orfali-coined
> > "shippable places" is much more apt).
>
> I had to bud in on this one point.

Well, I am not one given to metaphors of expectant contribution and
personal growth. I'm just going to butt right in...

> > You've got to learn to walk before you can run. Compound documents are
> a simple, appealing metaphor for the desktop that will ready the masses
> for shippable places. They're needed now for this reason, IMHO.

Compound documents are NOT training wheel technology -- they are deeply
and fundamentally correct abstrations for global coordination.

One of the critical insights of the Web (and Gopher, etc, before it to
varying degrees) is that _everything is a document_. A document can
capture the state of a computation nearly completely, pickle it for a
human, and re-present the same memes elsewhere. There is brilliance in
deconstructing "online services" from an operational,
draw-some-stuff-on-the-screen, take-input, repeat cycle to one with
explicit, declarative cutpoints: 'this IS the state of the app at this
point'. This technology has been taken all the way to the limit already,
with WinFrame and Broadway "documents" which gate fully interactive c/s
apps over the Web. And HTML is one particularly good format for this,
though there will be others.

Let's talk some more about why documents (persumably, in place of RPC).
DanC and I have had long arguments about where the distinction blurs. We
decided we *could* talk about more ephemeral "artifacts" (e.g. the
return vale "4" for "2+2") and longer-lived "entities" (web pages). As
far as I can argue, though, these are minor aspects of 'intent' -- where
do the bits-on-the-wire change? Well, in the RPC scenario, the bits
finally collapse into a stream of interdependent transactions and the
state of the system cannot be neatly extracted into a summary document.
RPC bits become defined on the wire by the whims of protocol-stub
compilers (IDL, RMI, etc). They lose explicit meta-information about
creator, modification date, cacheability, and most of all, they lose
ther name: artifacts can not be addressed de novo.

Entities always have names, even if they're short-lived radiated bits
emanating from an unknowable oracle (like a CGI script or a webcam).
Each page I see has a name, cache tags, etc. Most of all, pages aim to
explain one concept to one human being (we don't take well to "here are
twenty pieces of your response, you piece it together"). This increases
the *semantic* grain to being "a quantum of useful information to a
human".

So now we have two identifiable differences between artifacts and
entities... and I think I still argue that artifacts are unnecessary --
you can choose to view the results of a remote method invocation as a
really small "document". What you gain is fractal self-similarity (it's
documents all the way down) and you gain a limiting bounding factor on
complexity. Just as humans choose to communicate in sentences (at worst,
identifiable fragments) rather than in Morse code (a "bit channel"
instead of a "thought channel"), I think the minimum unit of
composability should be some recognizable, economically-identifiable
task ("record Seinfeld") instead of an operational recipe ("turn on the
tv; use IR remote to change channel to 7; send record() message;")

<Random trivia: there have been 345 billion OREOs manufactured to date>

-- was that sentence a document? It could be, I think it should be. We
can leverage so much now: I can cache this fact, annotate it with a
confidence rating, protect it, etc.

[at this point, adam will have to kick in to translate - I can't explain
it better right now. Probably the three glasses of Amaretto di Sanorro
I've had during this edit session...]

In short, I think documents-representing-task-state ARE how our pagers
and cars and yes, even diapers, will be composed and coordinated into
larger systems. (see d-o). Places are just another collection of links
in the form of a document...

I would like to tap Ernie's argument, too: that documents make an
appropriate, self-similar building block for the information universe
(no TM). My long-term battle is yanking the Internet service model up
from the minutae of IP packets to this level precisely because we can
only then apply document-semantics-enhancements like
payment-for-information value, security, store-and-forward routing (over
munchkin nets)...

> Budding out .. 8-)

But, but, but... sputter, but!

:)

RK