[rfc-i] issue: canonical formats
John R Levine
johnl at taugh.com
Fri Jun 1 07:14:51 PDT 2012
> While this makes a lot of sense, one could also imagine that along
> with a canonical source format, there is also a canonical rendering
> engine, which produces a canonical display format. ...
No, no, that's exactly what I DON'T want. We want lots of different
rendering engines to produce whatever display formats work on the devices
that people use, regular HTML, HTML with extra goop for indexes, PDF on US
letter paper, PDF on A4 paper, epub, mobi, docx, and even legacy line
printer. But none of those output formats is any more canonical than any
other. The input format is definitive.
One specific thing that means is that if someone finds a bug in a
converter, it's OK to re-render existing documents, but the source version
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
> On Thu, May 31, 2012 at 10:36 PM, John Levine <johnl at taugh.com> wrote:
>> As I read the wiki page, I see notes about a canonical source version
>> and a canonical display version. I would like to suggest that there
>> be only one canonical version, and whatever it is, it should be a
>> source versiont has structure and metadata at roughly the level that
>> xml2rfc does.
More information about the rfc-interest