[rfc-i] New proposal for "canonical and others"

My understanding of the canonical format issue is that it can not be 
addressed by an abstraction.
Assuming that there are multiple formats (this seems unfortunate but 
inevitable,) then even if they are generated by tooling there will be 
times when they differ.  Based on experience in other contexts when that 
happens, it is very helpful if there is a well define "right answer" 
even before folks get around to fixing the problem.  Defining one form 
of the document (and similarly one representation of the information 
within the document when one uses tables, code, and text to describe the 
same thing) as canonical provides this coverage.

Yours,
Joel

On 6/17/2012 5:10 AM, Brian E Carpenter wrote:
> Trying to up-level this discussion yet again, I believe that we
> haven't yet either clearly distinguished the hypothetical "canonical"
> format from the hypothetical "archival" format, or clearly
> established the requirements for each of them.
>
> If the requirements came out to be identical, that would be
> excellent, but it seems unlikely to be the case.
>
> In the end, the canonical format may turn out to be an
> abstraction, and the real-world requirement is something that
> is functionally equivalent to the canonical format. By contrast,
> the archival format MUST [RFC2119] be some kind of physical
> analogue or digital representation that can be filed away in a
> library or museum.
>
> Down level again, draft-hoffman-rfcformat-canon-others-02 seems
> to assume that XML is a stable format, unlike HTML. I'm not so sure
> about that; we might have to regress another level and say that
> our format is defined in SGML (even if, in practice, it is based
> on a specific version of some dialect of SGML such as a current
> version of XML or HTML).
>
> Regards
>     Brian Carpenter
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>