Re: revision strategies [was RE: [Moderator Action] Re: Progress on SVG book]

On Tue, 14 Apr 2009 23:14:33 -0400
"Dailey, David P." <david.dailey@sru.edu> wrote:

>  
> Jeff wrote:
> 
> I don't necessarily think the book should be stuffed into a CMS (like
> Drupal), I think raw HTML+CSS+SVG is just fine.  However, if it was
> put into a version control system like Subversion, people could
> download it from the repository, edit the document and then send you
> patches.  You (or others you delegate) would review the patches and
> approve them or not and fold those patches into your copy and then
> commit the changes to the repository.
> 
> I think this could become pretty painless with the right tools (I use
> the command line, myself though).
> 
> This would allow more than document text suggestions but things like
> typos, styling, inserting links, etc.
> 
> -------------
>  
> Sounds good to me. I had not heard of Subversion, and  so read about
> it a bit on Wikipedia. It doesn't necessarily sound trivial to get
> started,  but if that's the easiest way to go for this sort of
> project then let's do it! There is also Google Docs (which of course

I forget that most of this community is not software developers. We
could possibly host the book on one of the open software Subversion
servers out there. (Google code, SourceForge, etc.) It wouldn't require
separate maintenance or hosting and the commit rights are decided by
the owner of the project.

> now has SVG) but I gather there is a limit to the size of a given
> document and the book is hovering at about 750K of HTML right now. I
> rather get the idea that versioning is not its strong suit, and for
> version control, Subversion looks a lot better, though I suspect the
> interface for Google Docs is easier to enter from street level.
> Another approach: Etherpad, appears a little too concurrent and
> chatty. I'm fairly adaptable, though I might not have much time to
> learn anything new before July, unless it's real easy. So whatever
> will do the job and whatever most people are comfortable with is cool
> with me. Until we do get something in place, (assuming that whatver
> might take more than a week or two to get going) I'd suggest sorta
> like what Ruud did recently for all simple corrections: lists sorta
> like this: [ 1. /original text/revised text/ 2. /more text/more new
> text/ . . . n.  /old stuff/new stuff/ ]
>  
> that way I can find the stuff that needs to be changed. 

Maybe possible to automate that. That format is fairly simple to code
against.

> Alternatively, (again assuming that setting up Subversion won't
> happen immediately), we could have folks from here name  one or two
> chapters that they'd concentrate on, as another way to avoid
> duplication of effort. As you can see I'm sort of working in my mind
> on both short and long term approaches, with a short term interest in
> laying my current flurry of activity to rest, for a time to
> concentrate on other projects like writing a paper or two for SVG
> Open. BTW, I was thinking of maybe offering a talk just about the
> status of the book and of whatever collaborative mechanisms for it
> that we might design and implement between now and SVG Open. Might
> that make sense to folks? And for new sections, I'd recommend that
> people volunteer to write any new section, so we don't get multiple
> people writing the same section. Right now, Shaun Roe has volunteered
> for an XSLT (/AJAX) section, but all of those topics contained in the
> Afterword are in need of volunteers. Preferred format until we come
> up with something else would be very simple HTML : (limited pretty
> much to <p> , <img> , <pre><code> and <table>) without CSS, unless
> you can figure out the styles I've been using which is (alas) not
> necessarily obvious. Please review that list of topics to see if a)
> there is a topic or two you might volunteer for or b) if there is a
> topic missing from the book that really ought to be added to that
> list. As I mentioned in a previous email I've also not put any live
> SVG in the document, because of not wanting to crash IE which chokes
> when more than 100 or so separate SVG's are included. Hence all the
> images are screen shots in either jpg or png format. Eventually it
> may make sense to fork the document so that IE users get PNG&JPG and
> others get SVG, but that is about 60 hours of work I'd guess (just
> finding all the original SVG files -- 200-300 of those -- , testing
> them, uploading them and then linking to them).  By then, maybe we'll

Thinking like a programmer again, there is probably some advantage in
automating this as well. We'd still need eyeballs to verify that they
look right, but finding, organizing, and uploading may be possible.

> have new solutions that make ASV obsolete, so forking may be a
> non-issue?? That also brings up another issue: how best to point from
> the book to more current content in planetSVG ? There are places in
> which the book will be out of date. Maybe using chunks of it to seed
> wiki topics and then have the original chunks have pointers to the
> subsequent and live derivations? I'm not sure quite what other models
> there are for what we're trying to do here. The recent rather crazy
> debate about the licensure of HTML5 comes to mind and the possible
> inappropriateness of GNU or other licenses to stuff which is not
> software but text comes to mind. Of course, once the infusion of real

Possibly worth looking into Creative Commons licenses. I use them for
much of the text I write. They are similar in intent to the open source
licenses, but geared to "media" instead of "software".

> SVG into the document were done, then one would want to make all the
> source listings be auto-generated through JavaScript from the live
> SVGdocument, and that starts making everything a bit more fragile. I
> believe the SVG IG also sorta agreed back in the summer that that was
> a bit too much adventure for now. As I write this email I am
> discovering that I should probably be writing such notes in the
> planetSVG Blog, or in the SVG IG wiki or something, since I'm finding
> myself being a bit redundant. Oh well, after more than 30 years of
> writing e-mail I guess it is a hard habit to break. While I'm
> thinking of it: a big thanks to Ruud for having given just the right
> encouragement to get me busy working on this thing again! While
> finding myself very anxious to end the tedium of editing and revision
> (maybe 100 hours of just dealing with repercussions of Word - HTML
> problems) , I'm finding this next phase of collaboration that we're
> entering to be a fun and exciting one to think about. cheers David

I haven't had a chance to look much at the book, but I had a lot of
experience modifying lots of HTML in code a few years ago. What we
found then was that there were a number of cases that we could just
convert with code. (The mind-numbing "find /this/ change to /that/"
changes are often easy to automate.) Others, we could flag with code
(You know this construct is in there, but wrong. However, some
intelligence will be needed to resolve them.)

If I can get some free time this weekend, I'll take a look at the doc
to see if there's anything like that I see.

G. Wade
-- 
Who knows what email lurks in the hearts of men?

Received on Wednesday, 15 April 2009 12:25:45 UTC