Re: RFC archival format, was: Re: More liberal draft formatting standards required

[Doug Otis <[e-mail]>]

On Jul 13, 2009, at 7:58 PM, Doug Ewell wrote:
> Why on Earth would someone use Visual Basic within Word to write a  
> utility to convert Microsoft Word ***XML*** documents to an IETF- 
> acceptable format, when there are much better tools for processing  
> XML?

For a third-party application to interpret the changing Word document  
format, even in XML form, would require extensive and ongoing  
support.  This support would go well beyond what is currently needed  
to interpret the simpler xml2rfc structures.  Using Word input files  
alone is likely to represent an effort few could afford to support.

>  Why would someone not specifically write such a utility to ignore  
> or reject any Word document containing executable code?

Use of the bundled program language that operates at an object level  
can hide underlying format changes and avoid the related support  
effort.  Using the bundled programming language likely represents the  
_only_ practical method for directly utilizing Word input files, as  
was suggested.  IMHO, this was a logical conclusion.

> This, on the other hand, from Iljitsch van Beijnum <iljitsch at  
> muada dot com>:
>
>> This solves the problem that converting anything else into XML2RFC  
>> a reverse lossy process: XML2RFC needs more than what other formats  
>> can supply so automatic conversion (from, for instance, Word) is  
>> impossible.
>
> is a genuinely useful and productive counterargument against the  
> whole "word2rfc" concept.

Disagree.  The goal would be to generate RFC and ID documents.   
Requiring XML2RFC intermediaries negates the benefit of using Word.   
Beyond security concerns related to relying upon the bundled program  
language, not having this feature supported in OSX or Unix represents  
yet another concern.  Iljitsch view of XML2RFC intermediaries is not  
practical, but Word2rfc is not impossible when the bundled program  
language is used.  It can be done, but it would not be wise.


On Jul 13, 2009, at 1:10 PM, Julian Reschke wrote:
> The "experimental" version (http://xml.resource.org/ 
> experimental.html) is as stable as predecessor versions; the main  
> reason it hasn't been released is that the authors (IMHO) expected  
> more boilerplate changes to occur.
>
> And what exactly do you mean by "cryptic entries"?

There was little documentation for what would satisfy the nit checker  
a few months ago.  It was a challenge to know what was needed for the  
rfc structure.  The needed ipr parameter appeared rather cryptic.

> I think the right approach is to either help maintaining the TCL  
> code, or to rewrite xml2rfc in a different language.


To support the generation of MHTML, as some have suggested, the  
logical intermediary format seems to be XSLT (for defining xml2rfc  
constructs).

http://tools.ietf.org/html/rfc2557
http://people.dsv.su.se/~jpalme/ietf/mhtml.html

IMHO, pre-processors with roff might offer simpler and cleaner inputs,  
especially for the vision impaired.  A post process could then  
generate simpler MHTML formats.

-Doug