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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf