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
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf