[rfc-i] Graceful degradation is key, was: Re: draft-hildebrand-html-rfc

Martin Rex mrex at sap.com
Wed Jul 18 11:34:19 PDT 2012

Could we please stop the pointless parts of this discussion?

Try to get down to requirement that are *INDEPENDENT* from xml2rfc
does or could do.  xml2rfc contains lots of meta-data, and can be
extended to carry even more meta-data.

What meta-data is necessary to create a HTML-page that floats
is an entirely distinct question.  The requirements for a
submission format must be modeled on the minimum meta-information
that is necessary to create the desired output formats.

Similar for the graphics bikeshedding.  Any graphics must be optional.
So if another document author takes over a document (I-D or RFC), but
doesn't have support for some graphics format in his authoring tools,
he should be OK to leave out the graphics from his revisions of the
document.  But that only works if the original document is complete
without the graphics in the first place.

I also have strong doubts about graphics and accessibility.
ASCII arts are not better than real graphics, but the limited
capabilities it has should be a motivator to explain as much
as possible with text -- and the latter is "accessible".

Graphics, independent of whether it is bitmaps,SVG or ascii arts,
should not be critical to the document, but illustrative.  At least,
ASCII arts will reproduce in all environments that can show text
(except for environments with broken software, that fail badly when
trying to render ASCII texts, but that is clearly buggy app software,
and needs to be fixed at the app software level).

"Martin J. Dürst" wrote:
> Martin Rex wrote:
> > Could you simply accept that there are more active current uses
> > of the TXT version of RFC and I-Ds besides what _you_yourself_
> > are doing, and that there are I-D authoring tools in use that
> > are magnitudes easier to operate than xml2rfc,
> A magnitude is a factor of 10. "Magnitudes" should be at least two of 
> these, so a factor of 100. With all due respect, are you claiming that 
> editing with nroffedit is 100 times or more faster than any XML editing 
> tools?


If I want to pick up an abandonned I-D today, fix a few tincy places and
insert a new paragraph or section that shifts the whole page-breaking,
I can download the existing I-D as TXT, load it in NRoffEdit, and
convert it back into authoring format (that reproduces exactly as
the original) in 30 seconds.

So when submitting the updated I-D myself, it would only differ in
those places where it should from the previous/original when looked
at with rfcdiff on tools.ietf.org.

Similar for revisioning an RFC.

If you measure the time from the moment when you conceive to do that,
to end up with an XML2RFC authoring source, this will take you much
longer than an hour.

that is more than a 100x.


More information about the rfc-interest mailing list