On 14 jul 2009, at 11:20, Doug Otis wrote:
For a third-party application to interpret the changing Word document format, even in XML form, would require extensive and ongoing support.
In principle, yes. In practice this would probably not be a huge deal compared to what needs to happen to conform to new ideas from the lawyers. Obviously Microsoft didn't come up with an XML file format and then push it through standardization to do all of that again a few years from now. We can expect the format to be extended, but the basic stuff will probably remain the same for a long time. (And we only need the REALLY basic stuff here!)
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.
Directly from .docx files?
Requiring XML2RFC intermediaries negates the benefit of using Word.
I disagree. If it were possible to generate XML2RFC format from Word format that would be extremely useful, because that way people who can work with Word can generate XML2RFC that can then be used by people who work in that format, including the RFC editor. But as I've said before, the semantic markup in XML2RFC makes it impossible to create a working XML2RFC file from an input that doesn't have the same semantic markup. Although tagging semantics can probably be a bit more pleasant in a WYSIWYG tool than in XML source, it still has all the documentation and version breaking issues that XML2RFC has, so that doesn't really buy us much.
Iljitsch view of XML2RFC intermediaries is not practical, but Word2rfc is not impossible when the bundled program language is used.
I was talking about a new intermediate format. What I'm thinking of is a constrained HTML. HTML can be used both as input and output in word processors and text editors with only minimal extra steps, if any. A lot of those generate atrocious HTML, but this can easily be fixed by removing everything that doesn't conform to the constraints.
Converting from XML2RFC format to HTML would be lossy, so converting in the other direction would entail some manual work. But for the basic text in the middle a 1-to-1 mapping would be possible, which would help a lot.
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf