Re: Inclusion Lists for Hypercardus Clonus

[Hugh Hoover <heh>]

...balkanization of data...

  I think it is important that different FE's be able to read other FE data,
but only as it is appropriate for them.  By using a standard inclusion list
to store 'Clonus' fields, this sets up all kinds of 'editors' for reading
essentially inappropriate parts of Clonus cards.  A good solution is to allow
any fe to access non-specialized parts of the card (the field data, for example)
but to not have them see specialized parts (like button specs) without special
knowledge (it won't mean anything otherwise).  A 'Clonus' card that uses
something similar to a inclusion list for parts that are not specific to the
the display and operation of the card.  Then, my "WizzBang Tech - dataglove
directed editor" can flick through cards, looking at the kind of stuff that
is generally recognizable (like text, graphics, sound) but since it doesn't
use the specialized 'Clonus' card waldos - it doesn't pay attention to button
specs.  If I really really really want to play in button specs, I can use an
editor that works at a low level and "edits" everything - just looking at the
basic structure of the doc and fetching parts.  (or I can use 'Clonus' or a
'Clonus' clone).
  I think marcs is very correct in stating that specialized information for
a particular application should NOT appear automatically when accessed from
a different application.
  An important thing to recognize about 'standard' data formats is that
your average application writer ALWAYS has a better idea about how it should
be stored and they generally WILL use something different. (ok, that's
overstating it a bit, but it WILL happen)  I think the best we can do is to
encourage designs that allow non-specialized information to be shared.  I also
think we should encourage the hiding of specialized information that would not
be USEFULLY interpreted by other applications.

--Hugh