On Jul 12, 2009, at 4:42 PM, Doug Ewell wrote:
This thread has been headed down the wrong path from the outset, as
soon as Tony Hain wrote on July 1:
An alternative would be for some xml expert to fix xml2rfc to parse
through the xml output of Word. If that happened, then the
configuration options described in RFC 3285 would allow for wysiwyg
editing, and I would update 3285 to reflect the xml output process.
I realize that is a vendor specific option, but it happens to be a
widely available one.
I modified that, along the course of the thread, to suggest that a
separate "word2rfc" tool might be a more sensible option.
To the extent the .doc format is "highly flexible" -- which isn't
really true anyway; it's been rather stable since 1997, and the new
XML-based format is called .docx -- I can see that as an obstacle
for someone writing such a conversion tool. But I challenge anyone
to find the slightest suggestion in this thread that we should
publish IETF documents directly in Word format. Let's at least argue
the same point, folks.
These concerns took your concept to a logical conclusion. Notice the
definition for "sttbListNames" in:
http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx
Logically, rather than modifying TCL xml2rfc code to interpret xml2rfc
structures embedded within Word structures, Visual Basic would
represent a more likely tool, since it is already supported by the
Word application. To view this support, double click a control in
Design Mode, and see Word open a Visual Basic editor. Visual Basic
provides access to ActiveX routines, where in 2007, additional content
based routines along with custom XML storage for its binary format had
been added. Although placing controls directly into a Word document
is not the norm (prints as a graphic), these controls can generate
RFC compliant outputs, and even bibliographic XML fragments to assist
in the generation of the bibliographic sections. No TCL code would be
needed. A less risky alternative to that of Word might be to use
Java with Open Office.
From the IETF perspective, in addition to the ASCII text files being
used as the archived form, xml2rfc files are retained to generate
alternative presentations and as input for generation process. The
concern related to the use of the Word input format, which has changed
in 97, 00, 02, 03, 07, and is likely again in 10, remains that of
security. Changes are not always apparent, and even format
documentation can not be relied upon when details related to active
components are ill defined. The security concern is in regard to the
embedded program language, especially when the program is to be relied
upon as the means to generate IETF compliant outputs. The Internet is
not a safe place, where a practice of embedding programs that can
cause harm into what could have been innocuous text should be
considered a bad practice. Currently, collaboration between
individuals might be accomplished by sharing xml2rfc input files,
which are also retained with the plain text RFC output. Reliance
upon Word input files as a replacement for xml2rfc files will
invariably lead to a bad practice of depending upon potentially
harmful embedded programs.
Use of xml2rfc conversions has uncovered some odd quirks. The tool
does not cache bibliographic database selections. Either this works
on-line, or the entire database needs to be local. Not to diminish
the service offered by Carl Malamud, occasional sporadic connections
to the xml.resource.org servers can be a cause of angst for authors
who have not obtained the entire tarred xml bibliographic database.
Lately, the dependability of the xml2rfc approach has become less
reliable when dealing with cryptic entries and beta TCL needed to
generate I-D boilerplate language as required by nit checker.
This makes one wonder whether there could be a better way. A hybrid
approach might offer the similar features found in xml2rfc with the
simpler the inputs supported by 'roff. This would not exclude the use
of Word, but would not depend upon any of Word's content automations.
Perhaps a bit of Perl could provide the pre and post processors to
handle something that resembles the xml2rfc front section. While roff
is not perfect, it has been more stable than other WISIWYG word
processors and, when used in conjunction with separate pre/post
processors, can generate the desired alternative outputs.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf