[rfc-i] Internet Draft Format

Joe Hildebrand jhildebr at cisco.com
Sat Mar 24 11:15:40 PDT 2012


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