I just *knew* it was a mistake to "Leave this thread for later ..."
On 3 Jul 2009, at 18:04, Pete Resnick wrote:
On 7/3/09 at 10:16 AM +0200, Iljitsch van Beijnum wrote:
On 3 jul 2009, at 0:35, Pete Resnick wrote:
A much better solution would be HTML, if it's sufficiently
constrained.
Or, gee, we could generalize to a very constrained XML format
XML isn't a display format.
And how is this responsive to what I said? Applications of XML
(e.g., XHTML, xml2rfc with associated XSL files) provide perfectly
good display info that are currently in use by all sorts of display
platforms.
The choice of a particular markup language is irrelevant to the
overall issue: We need to have text and semantic markup, instead of
text with spaces and control characters to do page formatting as our
canonical format.
Hmm. Generalisation is good. Semantic markup is also good. But
ASCII has a good standing and a thoroughly good reason for being, and
probably continuing to be, a canonical format. We are at nobody's
mercy.
Now, I'm not for disputing the usefulness of XML or whatever other
format becomes popular. For HTML, for example, my screen reader has
keystrokes to jump to the next heading, or to list them for me to
select. I would want whatever we choose as the alternative markup
stored in the same repository, and to have the same chances of being
used as the ASCII by those who need preprocessed output, for whatever
purpose, on whatever device. I think this is somewhat optimistic,
though; either it creates more work for people who have quite enough
to do already just writing this stuff, else it precludes many existing
and perfectly good historical documents whose chance of conversion to
other formats now are somewhat limited by, for example, wishwash in
the current format variations.
On the other hand, as a writer I am not exactly enamoured by the
choices available. I just want to write. I'm blind; without my £5000
(sorry, l5000 :-) ) braille display on hand, and without brltty on
Linux, I cannot feel my way around the document; get the indentations
right, the line count right, the line width right. And even if I
could, it's very tiresome. xml2rfc does peculiar things all of its
own; even as a Tcl lover I'm not happy with its weird tendency to add
extra whitespace where it shouldn't be, or to make bold assumptions
about the author's ecstatic desire to write perfect XML, or the
somewhat less semantic HTML it generates, or ... I just want to
write, straight long lines, one a paragraph, with YAML-style section
delimiters, no boilerplate. All that pretty-printing is someone
else's problem, I just want to put an idea into a starting-point
draft. So I'd be much gratified if somebody could, or could give me
the encouragement to, write such a scheme up and then code it,
probably in Tcl.
As Dave put it, the current RFC format is "unfriendly,
unnecessary, possibly unethical and just plain wrong." I'd remove
the "possibly."
Please elaborate; this statement goes far beyond the inconvenience
of having fixed line and page breaks and the lack of non-7-bit-
ASCII characters.
You bet it goes further: The current format is a horror to anyone
who has to "read" the document on anything that does not visually
display 80 columns of fixed-width text. Try "reading" the text on a
small handheld device. Try doing so with a text-to-speech
application. Try magnifying it using apps meant for folks with
limited vision. We have the ability to create text in a format that
is easily interpreted by all of these devices and presented to the
user with no loss of information. Using a page-layout format for our
standards when page layout is completely unnecessary is at a minimum
"unfriendly" to folks who want to use such devices, and (given that
it is unnecessary to use page-layout) it is downright unethical and
wrong to make it harder for folks who must use such devices.
Wo! Brave assumptions!
For me, ASCII is *why* I read IETF standards, almost in preference to
other organisations. Clean, one-spec-a-file, consistent naming, can
be further preprocessed if desired (as above: to an extent), 7-bit for
display using all known braille codes on all braille displays. Truly,
as I've said, ASCII is a splendid lowest-common-denominator choice of
format. About the only hindrance for text-to-speech and braille alike
is the headers and footers; they make no sense even on common textmode
terminals, interrupt the perfect flow of speech for no reason, and are
just annoyingly redundant. Remove those, and I think we have a
perfect ASCII representation.
Not being able to use characters in documents outside of the US-
ASCII set is inconvenient (when they are part of the data stream of
a protocol you wish to describe) and unfriendly (when the personal
information about contributors cannot be properly provided). I'll
leave off unethical there; it's still wrong.
Hmm, transition to UTF-8? Readily available tool to remap UTF-8
common glyphs to flat ASCII representations?
I wonder what people think about the need (or lack of need) to have
graphical images.
Images are *way* down the list of needs.
Correct. Box drawings are accessible with a bit of imagination, but
they're not worth the bytes they take up; if a spec doesn't (or can't)
adequately express itself in beautiful English, it should go straight
back into community circulation till it does. Technical unambiguity
is key. Anything done to detract from it, including pretty pictures,
isn't any good for anything standard. It follows that reduction to
algorithmic building blocks is as achievable using text or pseudocode
as any amount of flow charts or whatever the current eye-catcher is.
(I did mention I'm blind, but if you're not convinced, consider that
drawings of any kind are generally a nuisance to me, so simply
understanding a specification could be difficult to people with visual
impairment or text display requirements different than monospace for
whom the graphic has no meaning. I need my braille display [bar
backslash dash slash ... won't do it for me] and then, with one line
of cells and only 32 of them, somehow have to understand it.
Sometimes can, sometimes can't, often not any the wiser.)
Getting rid of a page-layout format as our authoritative form is
primary. Using characters that do not occur in English is next down
the list. Everything else is extra.
I have no conviction. I'll let others try to spell it out. I don't
imagine any big changes soon, though.
Cheers,
Sabahattin
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf