In <v0410480cb30cad8df531(_at_)129(_dot_)46(_dot_)159(_dot_)50> Randall Gellens
<randy(_at_)qualcomm(_dot_)com> writes:
At 1:59 PM +0000 3/5/99, Charles Lindsey wrote:
The original version of the draft permitted either ">" or "> "; a
subsequent version used "> " only, and now we are at ">" only.
Actually, you could allow either by letting the dequote/destuff cycle
iterate until exhaustion.
Since this is a new format, I think there are several advantages to
picking one canonical quote indicate and sticking to it. Allowing
options, or making the quote indicator an additional C-T parameter,
adds complexity with very little benefit.
Indeed. The first quote character is under the control of the person who
generates the flowed format, so you _could_ insist on ">" as the only
supported possibility. However, the real problem is texts that come with a
variety of quoting standards, having lines beginning with ">|:" for 3
depths of quotation. Trouble is that many mailers allow you to choose your
quote character, and some people cannot resist the tmeptation to take full
advantage of all bells and whistles provided :-( . OTOH, I see no obvious
solution to that problem.
Yes, it is a slim proposal, that solves mainly one problem. That is
the goal. I think it is very important to have something that is
very simple and can be quickly implemented. Anything more complex
will be harder to get consensus on, and take longer to get it right
and then implemented and deployed. So, I take your comment as
evidence that this is on the right track :-).
No, I still think it is too slim. Consider the range of possibilities that
might be provided:
1. Automatic re-wrapping of flowed lines. This is what is in your present
proposal.
2. Automatic rewrapping of indented lines.
People like to indent portions of their_
text so as to set it off from the_
surrounding text.
This could be rewrapped as:
People like to indent portions_
of their text so as to set
it off from the surrounding_
text.
(observe my use of "_" to indicate a trailing space). This is a bit like
HTML <blockquote>, but more flexible. Note that you almost have a facility
like this insofar as it works with lines set off by ">>>>" in your
present proposal.
3. Automatic rewrapping of exdented lines.
o People like to insert "bullet" symbols_
to indicate important entry points in_
their indented texts.
o In addition, they do similar things using_
numbers or letters (e.g. "(i)" or "a)",_
but I won't bother to show an example of
that.
Which would rewrap to:
o People like to insert "bullet"_
symbols to indicate important_
entry points in their indented_
texts.
o In addition, they do similar_
things using numbers or letters_
(e.g. "(i)" or "a)", but I won't_
bother to show an example of that.
4. Automatic bulleting or numbering of such indents (HTML <ul> or <ol>, or
even <dt>).
5. Centred text.
6. Headers of various levels
For display in larger fonts, or underlined with "---", "===", etc
according to level.
7. Bold/italic/underlining
And so on and so forth. If you do all those things (which I do not
suggest) then you have more-or-less arrived at Proletext.
The question is, how far to go? To my taste, the minumum that is worth
dowing is everything down to "2.", or perhaps "3.". Anything less is too
feeble to warrant introducing a new notation at all. Moreover, it should
be fairly easy to implement down to that level (though your space-stuffing
convention would need to be rethought). Not that implementation difficulty
should be a prime concern. If you are going to have to write programs to
do the job anyway, then writing a more complex program is not that much
extra overhead, and what I am suggesting is hardly rocket science.
I did look at the proletext proposal, and it is interesting. If
Format=Flowed is a success, I think it would be worthwhile to then
consider advancing proletext or something like it, as an additional
format type. But I think we should get F=F deployed first.
Indeed so. It is somewhat bloated as it stands, but it could easily be
made into a reasonable text/proletext standard if a little restraint was
exercised.
And finally, I am concerned about the lack of mention of TAB characters.
If it is specifically your intention that they do not could as "SP",
either for flowing or for stuffing, then you should explicitly say so, to
remove all doubt. And BTW the ABNF accoring to the final RFC is "SPACE",
not "SP".
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5