[rfc-i] New proposal for "canonical and others"
Joel M. Halpern
jmh at joelhalpern.com
Sun Jun 17 07:27:47 PDT 2012
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.
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).
> Brian Carpenter
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest