[rfc-i] Internet Draft Format

Tim Bray tbray at textuality.com
Sat Mar 24 11:39:53 PDT 2012


For automated processing, if you have upstream XML that's going to be
a better candidate; but that's not controversial.

For the kind of markup you're proposing <p class="abstract"> is just
as good as <div, unless you want
<div class="abstract"><p>first para</p><p>...etc</p></div>

And I'm taking the trouble to walk through this to make the point that
agreeing on "IETF canonical HTML" is going to be a big long subtle
argument, and I’m not sure it’s worth having.   The 80/20 point on
improving the usability of RFCs is making the current HTML
canonical-where-available, and expanding the character repertoire
outside ASCII.

-Tim

2012/3/24 Joe Hildebrand <jhildebr at cisco.com>:
> My point on XML was just about tooling.  I apologize for making that sound
> like a strawman argument.
>
> Let's say for the sake of argument that the HTML *looks* fine when rendered.
>
> However, it would be very nice for Fred to be able to pull out the abstract
> easily, without having to count <p> tags or perform text-matching
> heuristics.
>
> So this:
>
> <h3>Abstract</h3>
> <p>This is the abstract.</p>
>
> Turns into:
>
> <h3>Abstract</h3>
> <div class="abstract">This is the abstract.</div>
>
> Or:
>
> <div class="section">
> <h3>Abstract</h3>
> <div class="abstract">This is the abstract.</div>
> </div>
>
> Or even:
>
> <section>
> <h3>Abstract</h3>
> <div class="abstract">This is the abstract.</div>
> </section>
>
> The point here is that the HTML isn't just dumb output, but has
> lightly-semantic signposts embedded in it to make post-processing easier.
>
> On 3/24/12 12:01 PM, "Tim Bray" <tbray at textuality.com> wrote:
>
>> What’s wrong with the current HTML output?  Looks OK to me on a
>> variety of screens and prints just fine.
>>
>> XML is not a viable delivery format... why raise that red herring?  At
>> the moment, the difficulty of editing XML and HTML is about equal,
>> unless there’s some tooling I don’t know about. -T
>>
>> On Sat, Mar 24, 2012 at 10:58 AM, Joe Hildebrand <jhildebr at cisco.com> wrote:
>>> As long as the HTML that is being generated is significantly better than
>>> what xml2rfc generates today, it doesn't matter to me how it is generated.
>>> I would suggest that *requiring* the use of XML as a precursor effectively
>>> makes the XML the delivery format, which I think we should probably avoid.
>>>
>>> There are those that hate editing XML; it would be nice to give those folks
>>> a path that might lead to different tooling for them one day.
>>>
>>> On 3/24/12 11:48 AM, "Tim Bray" <tbray at textuality.com> wrote:
>>>
>>>> FWIW, while in principle I wouldn¹t be opposed to the use of some some
>>>> sort of cut-down XHTML dialect as an authoring format, I question the
>>>> return on investment. It would require a lot of work to get to
>>>> consensus, and the xml2rfc tools are perfectly viable. ?Are there any
>>>> tools out there that would make editing easier than what we have now
>>>> for editing the upstream XML?
>>>>
>>>> HTML as a normative *delivery* format, however, seems like an
>>>> unadulterated good thing.
>>>>
>>>> ?-Tim
>>>>
>>>> On Sat, Mar 24, 2012 at 9:24 AM, Phillip Hallam-Baker <hallam at gmail.com>
>>>> wrote:
>>>>> Me too.
>>>>>
>>>>> I generally download the XML and generate HTML from that. It would be
>>>>> much easier if the site tools did this.
>>>>>
>>>>> If we are going to test out a new format it is going to require the
>>>>> ability to upload the HTML though as I don't want the new format to be
>>>>> limited to the capabilities of XML2RFC which is in turn limited by the
>>>>> plaintext format.
>>>>>
>>>>>
>>>>> Round tripping the source files is a key win that I would want to
>>>>> achieve. We can do that by extending XML2RFC of course.
>>>>>
>>>>>
>>>>> On Sat, Mar 24, 2012 at 6:12 AM, Julian Reschke <julian.reschke at gmx.de>
>>>>> wrote:
>>>>>> On 2012-03-24 11:02, Fred Baker wrote:
>>>>>>>
>>>>>>> Let me ask a relatively straightforward question along these lines that
>>>>>>> could be actionable within a finite timeframe.
>>>>>>>
>>>>>>> Right now, the Secretariat will post drafts in four formats: .txt, .xml,
>>>>>>> .ps, and .pdf. The XML files are primarily for the convenience of the RFC
>>>>>>> Editor and communication within a working group and among co-authors - if
>>>>>>> .txt and .xml are uploaded together, there is little question what XML
>>>>>>> file
>>>>>>> produced the .txt. .pdf and .ps are considered auxiliary; you may upload
>>>>>>> them, but they are not normative.
>>>>>>>
>>>>>>> It seems to me that the .html file produced by the xml2html XLS script
>>>>>>> could be uploaded in a similar manner, and treated in the same way we
>>>>>>> treat
>>>>>>> .pdf and .ps. What doing so would permit is experimentation with the
>>>>>>> format
>>>>>>> as a documentation convention, which would in turn let us experiment with
>>>>>>> community-provided tools etc. If the experiment works out, there are some
>>>>>>> further discussions we could have with tools-discuss and the IAOC.
>>>>>>>
>>>>>>> Am I crazy?
>>>>>>
>>>>>>
>>>>>> No :-) It's exactly what I've been asking for for some time now.
>>>>>>
>>>>>> Best regards, Julian
>>>>>>
>>>>>> _______________________________________________
>>>>>> rfc-interest mailing list
>>>>>> rfc-interest at rfc-editor.org
>>>>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Website: http://hallambaker.com/
>>>>> _______________________________________________
>>>>> rfc-interest mailing list
>>>>> rfc-interest at rfc-editor.org
>>>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>>>> _______________________________________________
>>>> rfc-interest mailing list
>>>> rfc-interest at rfc-editor.org
>>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>>>
>>> --
>>> Joe Hildebrand
>>>
>
> --
> Joe Hildebrand
>


More information about the rfc-interest mailing list