Iljitsch van Beijnum schrieb:
I think the mistake is to make the output format normative. If we make
the input format normative and publish that we're out of the woods:
obviously the input format is editable, and if it's sufficiently (but
not overly) well-defined output formats can be generated as desired.
+1
I'm very partial to xml2rfc,
I'm sorry to be so negative, but I hate it. The stupid thing can't even
handle my name properly so I have to live with what it does or edit the
result manually.
I think in this case you're confusing the format (as defined in RFC2629
+ RFC2629bis docs) with one particular implementation.
Having a well-defined base format makes it possible to select from a
variety of processors, and that is a good thing.
The problem with xml2rfc is that tries to be too smart by encoding
semantics. In theory this is the right thing to do, because you can then
do stuff like search for a specific author without catching
acknowledgment sections or find certain versions of the legalese. But
the problem is that this requires tools that either don't exist at all,
or aren't in wide use, so in practice it's actually harder to work with
the XML source than with the resulting draft/RFC format.
I'm not sure I understand how it's harder. May it depends which tools
one is familiar with. As a regular user of XSLT I find it extremely easy
to extract information out of RFC2629 formatted documents (such as
common patterns in index entries, or references).
XML2RFC once made me miss a draft deadline by choking on some XML I
wrote without saying why or where, leaving me with an impossible
debugging task. Formatting drafts in vi may take longer on average than
working with xml2rfc but it's more deterministic.
AFAIK, XML2RFC diagnostics have been enhanced a lot lately. And, if it's
an XML wellformedness/validity issue, running the document through a
standard XML processor should help, too.
Best regards, Julian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf