XML2RFC submission (was Re: ASCII art)

(With some hesitation, but if we're discussing a specific proposal, I guess 
this is more than just cycling)

> I would find this problematic.  I often submit in the "final"
> form because I started in the "final" form.  I have no *roff
> or XML form to submit.
Well, this can go a few different ways:

- "the authors must submit XML2RFC or plain text", where what you submit is 
what's used as the canonical source, or
- We can assume that an author of any draft that genrates any interest can 
dragoon someone among the thousands of IETF participants to spin plain text 
as XML2RFC, at some point in time (note that we practice the reverse art 
today; anyone wanting to modify a specification will often start out with 
the plain text of an I-D or an RFC and reverse-engineer it into XML2RFC, or 
into nroff, or into MS-Word, so the burden is already "out there", and we're 
just talking about whether we inflict it on the original author, or on 
subsequent authors), or
- We can say that it's time to require XML2RFC for all drafts.

I wasn't there, at the time, but am interested in the early history of 
programming languages, and you read about a LOT of resistence to the use of 
high level languages by programmers who already knew assembler. At some 
point, most shops said, "it's time to change, for most programs, because 
high level languages are good enough in most cases, and are easier for 
maintainers to maintain", but that trend happened over something like a 
generation or two of programmers, and I'm sure there are still people who 
program in assembler today because that's what they know.
This discussion seems quite like that discussion.

Spencer

> --> -----Original Message-----
> --> From: ietf-bounces(_at_)ietf(_dot_)org 
> [mailto:ietf-bounces(_at_)ietf(_dot_)org]
> --> On Behalf Of Henning Schulzrinne
> --> Sent: Wednesday, November 23, 2005 9:58 AM
> --> To: Eliot Lear
> --> Cc: Dave Aronson (re IETF); ietf(_at_)ietf(_dot_)org
> --> Subject: Re: ASCII art
> -->
> --> Let me try a concrete proposal:
> -->
> --> - All document editors MUST submit XML format to the RFC editor.
> --> (Mostly) semantic markup makes a lot more sense than
> --> presentation mark-up as it makes it possible to translate
> --> the format into a variety of output formats. This format is
> --> the long-term archival format, as it seems highly unlikely
> --> that the world will suddenly forget how to interpret XML in
> --> any timeframe we care about. The schema/DTD is documented
> --> in ASCII, so if an alien invaders take over the (IETF)
> --> world, they can bootstrap, as long as they can figure out English.
> -->
> --> - Authors can use Word (or other formats), but must use a
> --> Word style that makes automatic translation to the 2629 XML
> --> possible. I don't know enough about Word internals to know
> --> if Word styles are sufficient to make this possible today,
> --> but with a bit of semantic mark-up (e.g., surround the
> --> abstract with tags), this shouldn't be too hard.
> -->
> --> - The XML version is made available to the public and is
> --> the authoritative version, in addition to the traditional
> --> ASCII version. The XML version can then be used to generate
> --> more readable and printable versions using XSLT or other
> --> tools. I suspect generating a PDF version wouldn't be hard,
> --> either. These presentation formats can then evolve as
> --> people care to write tools.
> -->
> --> - The XML format also allows the use of UTF-8, for use in
> --> examples, not as normative text. The translation to ASCII
> --> can automatically insert U+ or other appropriate elements.
> -->
> --> - SVG or a subset thereof is authorized for illustrative
> --> (non-normative) diagrams. The XML schema already supports
> --> the ability to link alternative renditions of graphics, so
> --> this requires minimal effort.
> -->
> --> I think this would actually put us ahead of standards
> --> organizations that use presentation-oriented document
> --> formats that are hard to transform into alternative
> --> renditions now or in the future. None of the above requires
> --> a major change in process, rules or procedures. The only
> --> 'tools' effort would be to create a suitable DOC template.
> --> Given that converting existing late-stage drafts may be
> --> onerous, this can be phased in over time.
> -->
> --> Henning
> -->
> --> _______________________________________________
> --> Ietf mailing list
> --> Ietf(_at_)ietf(_dot_)org
> --> https://www1.ietf.org/mailman/listinfo/ietf
> -->
>
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf 

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf