[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?
hallam at gmail.com
Tue Jul 10 05:30:36 PDT 2012
On Tue, Jul 10, 2012 at 12:29 AM, "Martin J. Dürst"
<duerst at it.aoyama.ac.jp> wrote:
> On 2012/07/08 0:02, Phillip Hallam-Baker wrote:
>> The XML2RFC format is not a good document format. The designer seems
>> to have decided to do things their way without any good reason not to
>> follow the HTML approach. So things that are easy in HTML, like lists
>> require reference to manuals. Why they chose to use<t> instead of<p>
>> and so on? Its like the inventor was deliberately trying to make the
>> thing different and hard.
> I talked to Marshall Rose, the creator of XML2RFC, I think it was at IETF 54
> in Yokohama (2002, that would just be 10 years ago). To summarize, the
> issues we all know about XML2RFC were definitely not introduced
> deliberately. Marshall had a great idea (use a widely deployed structure
> format for RFC production) and a lot of energy to do the implementation, but
> didn't know that apparently minor structure details (elements vs.
> attributes, additional nesting elements or not,...) can make a big
> difference for general usability.
> In his defense, one has to say that this isn't something that is called out
> in the specs; one has to learn by trial and error, with a lot of experience,
> when details are arbitrary and when they matter.
If you think the XML specs are bad... try SGML!
The relationship of SGML to the Web was never a happy one. XML started
as an attempt to remove as much cruft from the SGML spec as possible
while being backwards compatible. There are many features of XML whose
only purpose is to preserve backwards compatibility with SGML. And
there are many SGML features that are stupid.It is not so much a spec
as the documentation of someone's code.
>From time to time, Tim BL has suggested rather more drastic action
like getting rid of attributes altogether, doing an XML 2.0 that would
drop backwards compatibility but that hasn't happened.
>> That said, XML2RFC exists and is somewhat tailored to IETF documents
>> so it makes a reasonable interchange format, albeit a rather tedious
>> one and it is a fixed point that is not going to change over time
>> unless IETF requirements change.
> I think that if we end up using XML2RFC as a main piece of the puzzle
> (definitely something that would make sense), then we should invest some
> time to fix the most annoying issues.
I think we could defer that to a phase 2. The core of this problem is
to have the RFC editor process XML2RFC files and not convert
everything to nroff.
More information about the rfc-interest