[rfc-i] graphics support

[Larry Masinter]

I don't think, in this particular case, your ASCII-art alternatives ARE more effective than they are misleading. In this particular case, the diagrams were meant as illustrations of SVG output (i.e., what a fragment of an SVG image would look like), and so an ASCII-art illustration kind of misses the whole point.

I do like the idea of encouraging, at least during a transition period, an ASCII-art equivalent of a diagram or illustration or example, in general. 


-----Original Message-----
From: Dave Crocker [mailto:dcrocker at gmail.com] 
Sent: Wednesday, April 18, 2012 3:37 PM
To: Larry Masinter
Cc: rfc-interest at rfc-editor.org; Heather Flanagan (RFC Series Editor)
Subject: Re: [rfc-i] graphics support



On 4/18/2012 12:05 AM, Larry Masinter wrote:
> Here's an example of a W3C document that uses illustrations where the illustrations are helpful.
>
> http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12
>
> I raise this example because we're trying to decide how an IETF document might normatively reference this, and moving some or all of the TAG document to "standards track" in an RFC might otherwise cause us to remove the examples.


 From the cited document:

> 1.1 Media Fragment URIs

|
|      xx
|      xx
|  xx  xx      xx
|  xx  xx      xx
|  xx  xx      xx
|  xx  xx  xx  xx
|  xx  xx  xx  xx
|  xx  xx  xx  xx  xx
|  xx  xx  xx  xx  xx
|  xx  xx  xx  xx  xx
-----------------------

and then

|
| +---------+
| |      xx |
| |      xx |
| |  xx  xx |      xx
| |  xx  xx |      xx
| |  xx  xx |      xx
| |  xx  xx |  xx  xx
| |  xx  xx |  xx  xx
| |  xx  xx |  xx  xx  xx
| |  xx  xx |  xx  xx  xx
| |  xx  xx |  xx  xx  xx
-------------------------------------

These took me about 10 minutes to produce.

Of course, these aren't as pretty as the graphic form in the document. 
But I'll claim that they are as effective.

There is a difference between necessary and nice.  Pretty diagrams are 
typically nice but not as necessary as this discussion thread suggests.

The issue is not words vs. graphics.  The issue is a core encoding form 
that is reliably usable over very long periods with minimal software 
requirements, in a world of continuing, massive change.

Again note that xml2rfc /already/ allows use of graphics as the 
/preferred/ form in PDF and HTML renderings.  That is, give it an ascii 
version and then also cite an external graphics form.

Works nicely, as John Levine cited:

    http://tools.ietf.org/html/rfc5598   figure 5

vs.

 
http://bbiw.net/specifications/draft-crocker-email-arch-11.html#rfc.figure.5


As we worry so much about competing with other standards groups, we 
really ought to consider how well they have fared in the game of 
accessibility, compared with the RFC series.  (I always cite my 
encounter with a young IT guy on Borneo in the 90s, who had read the 
RFCs well enough to recognize my name...)

Having access to the latest technologies and the highest bandwidth is 
addictive and distracting.  We tend to forget how things change and what 
it is like for others with considerably more limited resources.

d/
-- 
  Dave Crocker
  bbiw.net