[rfc-i] RFC editing tools
Joe Hildebrand (jhildebr)
jhildebr at cisco.com
Thu Dec 6 23:30:29 PST 2012
On 12/6/12 11:20 AM, "Ted Lemon" <mellon at fugue.com> wrote:
>On Dec 6, 2012, at 1:26 AM, "Joe Hildebrand (jhildebr)"
><jhildebr at cisco.com> wrote:
>> As is carefully-crafted HTML. Perhaps even more so, because there will
>> a larger corpus for these archaeologists to work from.
>HTML isn't regular,
I said "carefully crafted HTML", which can be defined and tooled to be
>doesn't support typesetting,
Neither does the lineprinter format.
>and has a lot of domain-specific functionality that's not germane to
Again, don't use all of it. Define a small subset.
>And it looks exactly like XML to the untrained eye.
When I bring up a self-contained HTML page in a browser, it looks good.
XML, not so much. To a view-source person, they look the same to even a
trained eye, as long as you're careful about tooling to create well-formed
documents. MANY more people are already familiar with the HTML schema
than the XML2RFC schema, however.
Again, we've been over exactly this ground on this list in the past, sorry
to folks that have been following along the whole time.
>So I don't think there's any reason to prefer HTML over XML as the
>representation, although I think HTML is a fine presentation target.
I think it depends on who the target market is for people who are going to
write specs. If it's the market is the existing group of people that
already write XML2RFC, then we're good. If we want to expand that group
outside of the currently nearly-saturated market, we can do better.
>That said, I would definitely agree that it would be good to use HTML tag
>names where appropriate in the XML, instead of inventing incompatible tag
>names, because as you say, this would make it easier to reverse engineer.
>In that sense, xml2rfc may not be the ideal input format‹it definitely
>has some clunky bits.
*All* of the tag names for the XML should come from the HTML set, and we
More information about the rfc-interest