[rfc-i] Internet Draft Format

Phillip Hallam-Baker hallam at gmail.com
Sat Mar 24 12:39:40 PDT 2012


Umm, if the idea is that we still have to use the XML2RFC format then yes it is.

I can't see any justification for the peculiar and unmemorable design
choices in that particular schema unless the goal was to have the
functionality of HTML in something that made it imposible to use HTML
editing tools.


On Sat, Mar 24, 2012 at 2:39 PM, Tim Bray <tbray at textuality.com> wrote:
> 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
>>



-- 
Website: http://hallambaker.com/


More information about the rfc-interest mailing list