has anyone proved by demonstration that this is possible?
It doesn't have to be part of the rules...
I don't think translating any Word style that kind of looks like an I-D
is likely to be feasible.
A slightly different question is whether we can come up with a Word
template that makes this feasible or at least minimizes the manual
conversion labor at the end. I don't see why asking authors for another
30 minute of XML tweaking after 3 years of document editing is
excessive. The IETF is not a vanity press, and the authors serve the
community, not the other way around.
- 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.
You can't have two authoritative versions..........
As long as the text has been known to have been generated from the XML,
this is not fundamentally different from the PDF versions of ASCII that
have been mentioned on this list. Nominally, the XML would be
authoritative if available, but for all practical purposes, the ASCII
would be sufficient as a working document. I don't see that this is a
real, practical problem.
- 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.
How would the translation know when U+ is appropriate...?
This is probably a side issue, but the assumption would be that you'd
only be allowed to put in UTF-8 if indeed the U+ notation can be
substituted there.
- 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 suspect that there are dragons here too.... but I've never tried to do
anything with SVG, so I don't know the tools for it....
I'm sure we can find reasons not to try anything new. We could take an
attitude that experiments might help us decide whether these are real
problems. I'm not very good at anticipating all the problems - and
comparing any problems to the positive effects that change might bring.
Just nibbling at the details.... the big question is whether this will
be felt as help or hindrance to the people who do the real work...
One example of the cost of doing business in the old way: I know that
the current system of only having ASCII available is a pain in the neck
when you try to write the "bis" version, requiring manual conversion and
hoping that nothing got lost in the manual translation. Often, we have
to back-port AUTHOR48 changes into the author-available XML-RFC (if that
can be located after a few years) when it's time to work on the "bis"
version. This is tedious and error-prone.
Henning
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf