> Consider the cost of migrating from the current idioms to your
> proposed idioms: all that software has to get fixed (no big deal), we
> have to hammer out the spec, all those HTML introductions, books,
> tutorials, references, test suites, ... and finally: all those PEOPLE
> have to learn the new idiom. (Studies show it takes 3x as long
> to learn something if you know already know it in a contradicting
> form as if you're learning it fresh. "Can't teach an old dog new
> tricks," I guess.)
If I understand Dan's comments correctly, and extend them to their
logical (perhaps extreme :-) conclusion, then we should make _NO_
changes in HTML because it will be a change that people will have to
learn. Better not introduce style sheets then, that is certainly a new
idiom to learn ;-). Better reject the entire new Version 2 of HTML,
that certainly has new idioms for people to learn ;-) Obviously
I do not believe that Dan is lobbying for no changes of any kind.
So we read on.
> And for all that hassle, what do they get? As far as I can tell,
> exactly the same expressive power as they already had.
> Sorry, I just don't think it's worth the bother.
> Dan
This final comment is, IMHO, the real issue. Is there something
sufficiently of value in the new idiom that is worth the effort to
learn? To find the answer (or at least a concensus) to that question
is why I posted the proposal to the list.
Personally, I believe that you get CONSIDERABLY more expressive power
than you currently have. For me as a document composer, the ability to
have control over the list ITEM heading is worth the bother. Plus,
having a general purpose autonumbering scheme is, for me, WELL worth
the bother. Others have mentioned the expanding outline capability.
That is not of interest to me, but is an expressive power that we do
not already have at the control of the document composer, and which
this proposal provides. For them (see message from
simonb@ctt.bellcore.com sent on Thu Aug 3 06:28:10 1995) it is worth
the bother. And further, the bother (or hassle) is not (IMHO) that
great, nor is the idiom that different. But that is only _my_
opinion. Dan has now expressed his, and I am concerned because I
value his opinion highly. But he is also only one person.
How about anyone else?
Larry Masinter <masinter@parc.xerox.com> wrote on Wed Aug 2 16:36:23 1995
> I was looking for a problem statement or a cost/benefit analysis in
> your proposal: benefit to authors and readers, developers of software;
> cost to authors, readers, developers of software.
I am only an author, so I cannot presume to express what is either the
cost or benefit to these other categories. That is why I posted the
proposal to the net. I think Dan is saying that he does not perceive a
benefit and the cost is a hassle, so it fails his cost/benefit analysis.
I say again, how about anyone else's cost/benefit analysis?
Michael