Inclusion Lists for Hypercardus Clonus

[Marc Stiegler <marcs>]

A while ago, rick put out a message stoutly defending his ability 
to implement Hypercardus Clonus with just text and inclusion 
list documents.

You're quite right, rick. You CAN implement good ole 
Clonus that way. The only question is costs versus benefits.

The best news in doing Clonus with just inclusion lists and text 
passages is that you don't have to learn much about Xanadu. This 
is probably compelling for the first-time developer; whether 
it is compelling for others depends on more factors. One of those 
factors which I will address another day is the quality of the 
documentation, the amount of assistance we can give developers 
as they scrabble up the slope to the pinnacle of Xanadu expertise.

Another benefit of an inclusion list/passage based Clonus is 
that you can kinda look at the CloneCards with any other frontend 
that can read inclusion lists and passages, such as the infoFactory.

But this second benefit is actually more of a cost: you can kinda 
look at the CloneCards with other things that really won't understand 
them. My suspicion is that, for the ordinary user on an ordinary 
day, we didn't do him any favors, letting him pick up a field&button 
doc as an inclusion list.

If this IS doing him a favor, great, implement it this way. I 
can imagine using the InfoFactory as a CloneCard editor--but 
it would be a very raw editor, i.e., no syntax or semantic support, 
the kind of thing Unix people would love, but which would be 
suicidal for occasional users.

Anyway, if you agree that it's not wonderful to look at CloneCards 
with the InfoFactory, then you probably want to give it a different 
work type even if the structure remains the same. 

And if you're going to give it a new work type, you might as 
well ask, are there any ways I could build Clonus in Xanadu that 
would make it faster, or more compact, or easier to understand 
and maintain? As a simple example, the Card class document has, 
as the first 2 entries in its inclusion list, the background 
graphic and the background field&button document. Since those 
2 fields always show up there, would it make more sense to put 
them in pigeonholes in the work's main unordered orgl? This would 
be slightly easier to understand for the new programmer, because 
it maps the structure onto the purpose more clearly.

Ravi has other, stronger examples of things you can do with Xanadu 
that would make Clonus easier and/or better, for the developer 
who got more deeply into Xanadu objects. I'd be quite interested 
to know if you consider the merits of using deeper Xanadu features 
good enough to pay for the extra learning required. 

So if you don't mind, I'll put a meeting  on my meeting list 
for you (rick) and ravi to discuss those items.

--marcs