[rfc-i] issue: canonical formats

[John R Levine]

> 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 
never changes.

Regards,
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.