Inclusion Lists for Hypercardus Clonus

[Eric Dean Tribble <tribble>]

No not so great a message at all.
The message was enjoyable and clarifying for me.

   Remember if we can come with doc types that work for
   most everyone then they can all share everything.
   I'm sure we can if we try.

1.  What do such document types look like?  How can they provide a
simple abstraction for simple cases and still provide the all the
power we want for hard problems?  This strikes me as equivalent to
providing Object types that work for most everyone so they can all use
just these object type.  The usual solution is to provide low-level
types and mechanisms for extending the space of types.  The Waldo
stuff extends this for doc-types to handle type recognition at the
reading end.

2. "most everyone" means not everyone.  This acknowledges a growing
(albeit slowly) diversity of document types defined by third parties.
I want our system to support that diversity and encourage use of our
system in unexpected ways.  Otherwise, we'll end up with a
disorganized chaos of document types.  This very much parallels
discussions of link-types.  We must have an extensible space of
link-types that we seed with a few good ones of our own.

dean
-----------------------------------------------------------------
I really appreciate the communication started by my "well I
can do this with just Inclusion Lists..." mailing.  It is
giving me a good feel for waldo-ness :-).  I
look forward to continued discussion as well as ravi's
presentation.

and now for something completely different...

In mulling over the Browser portion of a FE development environment,
I find myself considering a "natural" tuple, well actually a
triple.  There is:

	a datum -- the thing I want to inspect or manipulate
	a display format -- how it is presented to me
	a collection of manipulation methods -- what I can do with/to it

Consider:

	datum -- entry in the OED
	display format -- how to display text with "see also" links
	manipulation methods:
		translate to Sanskrit
		print hardcopy (easier for text than, say, contone image)
		find antonyms
		...others...

Another (more interesting) example:

	datum -- a display format
	display format -- how to display display formats
	manipulation methods:
		3D projection
		stereoscopic display
		...others...

I assume a separate(?) editor for actually changing
the data (thus, not a manipulation method).

This representation evolved from writing a description of the
Browser and Editor pieces of the dev. env. rather than an effort
to impart structure a priori.

Some considerations for y'all:

Am I locked into a silly way of thinking?

I posit that every front end will have some kind of browser.  Will
they all fall into this triple representation?  If so, should this
be a basic doctype or should it be a "conventional" inclusion
list" useful for browsers?

as always, comments appreciated
rick