Diffing with the SVG Primer

I started reading the primer today, got through chapter one and made a
few minor corrections here or there.  I'm really trying to get a sense
as to how a review process can proceed, ideally I'd like to give
reviewers the possibility of making changes themselves in the HTML doc
and then sending a diff (patch) to the editor/owner (whoever that will
be).

My CVS is a little rusty, but I did do a cvs diff and took a look at
what my changes show:

Here's an example:

Index: svgprimer.html
===================================================================
RCS file: /w3ccvs/WWW/Graphics/SVG/IG/resources/svgprimer.html,v
retrieving revision 1.4
diff -r1.4 svgprimer.html
627c627
<         If you ever close your eyes and see pictures that have never
been drawn or movies that have not yet been made, then SVG might be
for you. Just as typing or drawing or playing a musical instrument,
developing hypertexts or carving stone can help you to express a part
of what is inside you, so might SVG expand your expressive ability.
Think of SVG as an expressive medium. With it you can let your
readers' browser build your vector graphics, animate them, and let
your readers interact with and change the evolution of those graphics
dynamically. Users can draw over them, append to them, or use them to
plot user-selected sources of data. And you can do it in an
open-standards environment that is rapidly growing in popularity and
cross-browser acceptance. It is good for less fanciful endeavors, like
business and science, too. It is sort of like HTML, only better.
---
>         If you ever close your eyes and see pictures that have never been drawn or movies that have not yet been made, then SVG might be for you. Just as typing or drawing or playing a musical instrument, developing hypertexts or carving stone can help you to express a part of what is inside you, so might SVG expand your expressive ability. Think of SVG as an expressive medium. With it you can let your readers' browser build your vector graphics, animate them, and let your readers interact with and change the evolution of those graphics dynamically. Users can draw over them, append to them, or use them to plot user-selected sources of data. And you can do it in an open-standards environment that is rapidly growing in popularity and cross-browser acceptance. It is good for less fanciful endeavors, like business and science, too. It is sort of like HTML, only graphical.
...
1125c1125
<         <li>Special mention: KDE. Not a browser, but an desktop
environment for Linux, it should be mentioned that the K Desktop
environment (KDE) provides native SVG support at the level of the
operating system.
---
>         <li>Special mention: KDE. Not a browser, but a desktop environment for Linux, it should be mentioned that the K Desktop environment (KDE) provides native SVG support at the level of the operating system.
1233c1233
<         Accordingly, the family color "red" may be defined
alternately as "red", "#f00", "#ff0000", "rgb(255,0,0)", or as
"rgb(100%,0%,0%)".
---
>         Accordingly, the color "red" may be defined alternately as "red", "#f00", "#ff0000", "rgb(255,0,0)", or as "rgb(100%,0%,0%)".


As can be seen, for small paragraphs, it is quite easy to review in
plain text the suggested change.  On the other hand for large
paragraphs (like the first one in my snipped diff), it is quite hard).

Doug, can you share some details about the tools the W3C uses for
review, revision history browsing, etc?

Thanks,
Jeff

Received on Saturday, 6 February 2010 22:15:23 UTC