Re: new stuff in draft edits

Jim Whitehead wrote:
> 
>> We can get a reasonable diff (now that we have XML version of  both), 
>> see for instance <http://greenbytes.de/tech/webdav/draft- 
>> ietf-webdav-rfc2518bis-latest-from-rfc2518.diff.html>.  I guess  this 
>> is the format people should be reviewing.
> 
> 
> That's very nice! Are you planning on consistently producing this  page 
> (or is it created automatically)?

I can do that semi-automatically once the source on ietf.webdav.org 
actually is well-formed (and doesn't need manual fixes anymore before 
running it through an XML parser).

> Since it's easy to see the differences using this tool, it seems to  me 
> the concern about seeing changes from draft to daft is reduced. Is  this 
> true?

The drafts used to use a format where rfcdiff couldn't generate sensible 
diffs (hint: they were generated from Word). Now that readable diffs can 
be produce from both the revision and the original version this is less 
of a concern. I didn't think about generating a diff against rfc2518 
until today, but this makes a lot of sense.


>> Well, sounds like pre-generated HTML with change tracking (hyper- 
>> linked to an issues list) is a good thing. It's not like it's  
>> impossible to get that with XML (check the drafts I've been  editing, 
>> for instance <http://greenbytes.de/tech/webdav/draft-ietf- 
>> webdav-bind-12.html>).
> 
> 
> This also sounds like a plus. Is there some place that documents how  to 
> do this?

It's an extension to xml2rfc that uses extension elements for 
del/ins/replace. If somebody wants to use it I''ll be happy to (finally) 
write down documentation.

>> Right now we have the situation that feedback to previous drafts  
>> usually was ignored, thus the long backlog on issues we now have to  
>> go through. This definitively is frustrating, and please don't  blame 
>> people when they start considering how to invest their time  in a more 
>> efficient way.
> 
> 
> My feeling is the modification process is now back on track, and we  
> have a responsive document editor.
> 
>> IMHO, it's definitively not XML which is the problem. In the end,  we 
>> need to provide an ASCII version, and that works *much* better  using 
>> xml2rfc. Last time we produced a draft with Word (RFC3744)  it's 
>> formatting was so bad that we had to go through an additional  
>> edit/submission cycle to get it right.
>>
> 
> I agree that's a pain, and a big advantage of XML. But, if the lack  of 
> change awareness from draft to draft frustrates people so much we  never 
> create a final draft, the ability to convert to text isn't  super 
> important. But, perhaps it's easy to create a cron job that  
> automatically creates an HTML diff between revisions of 2518bis?  Also, 

Revisions between drafts that have been submitted are online at 
<http://tools.ietf.org/wg/webdav/draft-ietf-webdav-rfc2518bis/>.

> automatically converting the latest draft to HTML would also be  a plus.

Once the source document is fixed that'll be trivial.

> Making it easier to see the latest draft might improve participation.

Yep.

Received on Wednesday, 19 October 2005 21:36:30 UTC