On Jul 1, 2009, at 10:58 AM, Tony Hain wrote:
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.
Reasons for wanting more than just plain text documents is to permit
inclusion of charts, graphs, and tables, for a visual society. A safe
way to provide this type of output using stable open-source code would
be with roff preprocessors, like eqn, pic, tbl.
Word's closed code is continuously changing. Availability of this
closed application depends upon OS compatibility and version
regressions. Both are moving targets. In addition, Word formats
permit inclusion of potentially destructive scripts within highly
flexible and obfuscating structures. troff normally outputs .ps and
is supported by various utilities like X viewers in open source. Unix
based OSs like OSX and Linux still support this document format, where
grohtml can generate HTML output. The disadvantage of using the roff
approach has been a lack of IETF boilerplate pre-processors. Merging
XML structures could be combined with powerful roff presentation
utilities to generate IETF documents.
In many respects, roff offers simpler and proven stable formats. The
present xml2rfc utilities do not offer wysiwyg. Combining custom pre-
processors and visualization utilities, the roff suite offers greater
security, stability and versatility for all OSes and media
presentations types, along with iterative wysiwyg modes of operation.
There would be little difference using roff tools from using xml2rfc,
however the results could show a marked visual improvement. A desire
for security might even foster a resurgence in roff tools to leverage
proven and stable document generation.
Everything old is new again.
Ietf mailing list