[rfc-i] Resetting this format debate a bit
dhc at dcrocker.net
Mon Mar 26 23:33:38 PDT 2012
On 3/27/2012 3:57 AM, Larry Masinter wrote:
> 1. Whatever we do, we should adopt it step by step with review
> 2. There are multiple communities to be served
> -- let's be careful about trading off improvements for one community
> by making things terribly worse for others
> -- I think it's best to think of the "workflow": who does what when
> and how often
> Each of these communities have different needs, and the document formats
> and work processes chosen should support those needs.
Here's where your note gets dangerous.
It's not that I disagree with your statements, it's that a reader could easily
interpret this as inviting a clean-slate exercise, as if we did not already have
40 years of a service that has worked spectacularly well and an installed base
that needs to be protected.
Now, earlier text in your note can serve well to protect against the excesses of
a clean-slate view, but as I say, a reader could miss that, by this point in
> It's possible and easily demonstrated that the formats used at various
> steps can be different.
It's possible and easily demonstrated that formats used at various steps do not
/have to be/ different.
> Others prefer to read them on mobile devices.
The recent popularity of smaller-format display imposes, I think, a new and
compelling requirement that (finally) /demands/ a re-flowable and non-paginated
format. Not (necessarily) as the "primary" presentation format but as an
"officially-supported" one, certainly. And it makes it worth at least
considering changes to the primary format.
> It *might* be possible to satisfy the needs of readers and reviewers
> with a single format and transformation tools, but doing so is difficult;
> consider multiple formats instead.
> When there are multiple editions (formats) of a document,
> only one should be authoritative.
> We should keep the ASCII text requirement while we develop
> the optional alternate form and regularly produce alternates which
> _could_ serve as the authoritative copy.
I think it at least worth considering careful modification to the base, primary
text format, to make it cover the two essential deficiencies that are causing
serious problems, as opposed to merely being unpleasant:
1. Display on smaller formats
2. Support for international characters
That's why I reacted to Julian's comment about MIME text flowed and charset.
And possibly we should consider a long-standing limitation that we've had to
hack around in special cases:
3. Inclusion of true graphics, in addition to ASCII art.
Please note the "in addition to".
Permit these 3 changes. Remove page headers and footers (but put tags at the
beginning of the file to define them. Define tagging for diagrams and allow it
to also cite external, graphics-form diagrams.
In its raw, unprocessed form, this would continue to be directly readable by
most text display devices, as long as they wrap long lines. The processing to
produce a paginated form (and include the graphics form of diagrams) would be
> The notion of a "file format" is complicated.
I suspect we should stop using that term. It gives no indication of the role of
the document. So we don't know whether it's for editing, archive or display.
(I'm still not clear on the need for different formats for editing vs. archive...)
> Much of our opportunity for miscommunication is because of
> an incomplete vocabulary for talking about formats& publication
> ASCII text (fixed line, paged)
> Publication form
> UTF8 text (same but allow UTF8, with some restrictions TBD)
> Publication form
> Authoring form
> XML: Xml2rfc format (with various evolutions, present and proposed)
> Authoring form, possible intermediate publishing form
> HTML (with various restrictions or profiles, style sheets)
> Publishing format, potentially authoring format
> ePub (actually zip-packaged HTML + images etc.)
> publishing format but contains authoring format
This looks like a good exercise to pursue.
More information about the rfc-interest