Re: Inclusion Lists for Hypercardus Clonus

[Michael McClary <michael>]

> From: roger (Roger Gregory)
> 
> [] There will be hundreds of editors, and there is an immense
> value in keeping them able to read each others documents. I
> believe it would be a disaster if my fe can't quote part of a
> HC document and criticize or comment on it. 

I agree.

> From ravi Tue Feb 13 13:00:27 1990
> 
> We provide a base set of data types (waldo types) out of which a
> developer can build new types. Since our waldo type system is
> multi-valued along the dimensions of subclassing and wrapping, a
> different front end will be able to look at another's data structures
> at the very least in terms of the system primitive types that they
> both share. Once you try and modify it through an inappropriate tool,
> it loses it's special type, since there is no guarantee that you
> maintained the user-defined type invariants. (E.g. you can look at a
> Microsoft Word document with emacs, but if you try and modify it,
> you'll probably not be able to read it back into Word.)
> 
> The InfoFactory suffers the limitation that it doesn't even support
> looking at all of the primitive data types, particularly record types.
> Other frontends will be different. I can image the equivalent of a
> sector-editor for Xanadu that allows you to examine all the primitive
> data structures in a useful way, but you could only modify
> user-defined types if you knew the password to the endorsement used by
> the application to mark the orgl type.

You can look, but you can't touch.

With this approach:  A company might try to use the "can't touch"
system to keep competitors from being able to support his private
document types.  The immediate response would be for the competitors
to implement an automatic "vcopy the guts as THEIR equivalent type
on modification (after certifying type compliance)".  Thus, THEIR
editor could edit both types, but the ORIGINAL product could only
edit its own, until the equivalent operation were implemented.
(They could also license their standard, without involving us, or
 convince us to include their waldo in the backend at some later
 release, [with a new "Xanadu certified it" type.])

Alternative 1:  You can't see the data if you don't know the type.
("By default you don't see the data" has similar characteristics.)
Now if IBM writes a a doodah editor, all the existing editors can't
(or don't) even SEE the doodahs.  It becomes trivial, AND THE DEFAULT,
to build IBM printing-presses that print documents you can't read
without IBM glasses.  Licensing the technology gives you the hook for
writing documents that break true-blue editors but not your clone,
i.e. You can't license the right to build IBM-clone glasses without
getting a reciepe for building a printing press that makes booby-
trapped books that break REAL IBM glasses.  Thus, IBM won't license
the technology, and they have an excuse that holds up against
anti-trust suits, too.

Alternative 2:  You can look AND touch.  Then, what's the point?
Joe Random Vandal can hack up a frontend that publishes documents
that break any fancy editor on the market.

So "Look but must vcopy to touch" has the right incentive structure.

If an editor wishes, it should be ABLE to suppress automatic display
(and thus automatic time-wasting transmission) of data of unknown type.

If the examples in the FEBE spec emphasize protocol subsets that send
data of the expected types, plus notification of the presence of data
of unexpected types, the developers will often do the right thing.

What's the right thing?  Probably:

 - Always notifying users of the presence of data of unknown types.

 - Providing a user-hook for conformance-checking and attempting to
   view it as various known types.  (i.e., a temporary "cast")

 - Providing a user-hook for rechecking-and-view-attempting something
   that came up looking like garbage as if it were some other type.
   ("cast-and-redisplay")

 - Providing a user-hook for automatically confomance-checking-and-
   displaying future occurrences of new-type-"foofoo" data as
   existing-type-"foo" data.  ("remember cast")

 - Converting the data to the understood type when it is edited.

Seems to me it might be wise for the backend to provide a hook for
"claims to conform to standard 'foo'" which is publicly endorsable
for every "conforms to standard 'foo'" endorsement.  A frontend
developer could chose to display (after checking) foreign data that
claims to conform to his standards.  (He might also have his product 
automatically endorse data it found to be conforming, to accellerate
display in other sessions.)

(This has an interesting mapping back to authorship endorsements:
 Claiming you're quoting a person, or perhaps that you're correctly
 restating his opinions.)

	michael