W3C home > Mailing lists > Public > spec-prod@w3.org > April to June 2012

Re: [rfc-i] IETF RFC format <-> W3C pubrules

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Wed, 9 May 2012 09:33:22 -0400
Message-ID: <CAMm+Lwjq9OwkYXFeOX-yJzaD82VS2urEfGTnkz9xrmmji3Vp7Q@mail.gmail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, rfc-interest <rfc-interest@rfc-editor.org>, Paul Hoffman <paul.hoffman@vpnc.org>, spec-prod@w3.org
The secretariat can even pull the data from non XML documents.

HTML has exactly the same expressive power as the XML2RFC data format.
If you want to you can even use XML2RFC to generate your HTML source.

In fact one of the design constraints we might use is that it must be
possible to round trip from XML2RFC to HTML and back without losing

XML2RFC is not beyond reproach as a doc format. In fact I find it
pretty awful. There is really no reason that a <list> has to be in a
<t>. It is inconsistent with text sometimes turning up in attributes
and sometimes not.

To encode the same information in a HTML document the class= attribute
should be used. This then allows the stylesheet to be used to expose
(or hide) the relevant information. If you are using a good HTML
editor you can even edit and see the stylesheet changes automatically.

<p class="author"><span class="firstname">Phillip</span><span

<h1 class="abstract">Abstract</h1>

Since there is very little metadata in RFCs, I don't see much of a problem here.

On Wed, May 9, 2012 at 9:19 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> On 5/9/2012 9:11 AM, Julian Reschke wrote:
>>>> ...which means: little metadata or no metadata to rely on, right?
>>> I am not sure quite what you mean there.
>> A way to programatically extract all the information xml2rfc captures for
>> us, such as author names, WG information, "updates"/"obsoletes" information,
>> references, ABNF, copyright status, ...
> The RFC Editor publishes all of this metadata as an XML document that is
> independent of any RFC.  Why would we need to have this information inside
> the RFC itself?  And if we did, some information would still be lacking.
>  For example, if an RFC is updated or is made obsolete, the XML document
> published by the RFC Editor would contain that information, but an RFC
> document obviously cannot predict the future.
> I have a tool (not xml2rfc) that provides this metadata to me based on the
> aforementioned XML document.  I don't see a need to have it somehow bound to
> the format of the RFC itself.
> Paul

Website: http://hallambaker.com/
Received on Wednesday, 9 May 2012 13:33:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:19 UTC