Subject: Re: xml2rfc improvements (was: Re: Image attachments to ASCII RFCs)

From: "Bill Fenner" <[email-masked]>
Date: Tue, 20 Jun 2006 14:01:27 -0400

On 6/20/06, Ned Freed <[email-masked]> wrote:
> [jck:]
> > ... I like a feature of those system
> > that you didn't mention (the ability to insert comments whose
> > appearance in the output can easily turned on and off.  <cref>
> > and some processing options comes close, but isn't quite the
> > same).
>
> IMO this is something that needs to be added to xml2rfc. It is very common to
> have text of various sorts in drafts that has no business being in the final
> RFC, and the current mechanisms for controlling this are a bit primitive.
>
> Consider this a vote for some added functionality in xml2rfc to cover
> this case.

Can you be more specific about what the requirements are?  The xml2rfc
maintainers are (rightly, IMO) reluctant to add features
speculatively.  cref exists for this purpose, but doesn't fit your
needs because _____?

Thanks,
  Bill

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Jun 2006 14:50:36 -0400

--On Tuesday, 20 June, 2006 14:01 -0400 Bill Fenner
<[email-masked]> wrote:

>> > that you didn't mention (the ability to insert comments
>> > whose appearance in the output can easily turned on and
>> > off.  <cref> and some processing options comes close, but
>> > isn't quite the same).
>> 
>> IMO this is something that needs to be added to xml2rfc. It
>> is very common to have text of various sorts in drafts that
>> has no business being in the final RFC, and the current
>> mechanisms for controlling this are a bit primitive.
>> 
>> Consider this a vote for some added functionality in xml2rfc
>> to cover this case.
> 
> speculatively.  cref exists for this purpose, but doesn't fit
> your needs because _____?

Ned's "text of various sorts" is, for me, the key to answering
your question.  cref is a huge help relative to where we were
before, but experience indicates that the following are
different:

	(1) Change tracking, as in "what was done to this
	paragraph, when and why"
	
	(2) Revision and external comment tracking, as in "who
	suggested changes to this section and what were they".
	
	(3) Editor internal tracking, as in notes the editor
	writes to him or herself.  Usually these can be
	accomplished by standard <!-- ... --> comments but, for
	those of us who are far enough into the old fogey range
	to need to do serious editing and revising on paper,
	being able to expose those notes is a huge help.
	
	(4) WG or other consensus group tracking as in "this
	issue needs to be resolved before we move forward".

With the understanding that this is not a proposal, just an
illustration of what I'm talking about, something like

    <cref type="change" year="2006" month="Apr" day
"1">...</cref>

and a processing directive (or set of them) that would select
types to be displayed and, for the first category at least,
starting and ending dates to be displayed (so that one could
isolate version change notes to a particular version or produce
only changes generated in the most recent version) would go a
long way here.  It would even give us at least one capability in
the tracking area that Word, IMO, botched.

But, in any event, that is, IMO, the issue.

As a more general observation, the whole XML2RFC family of tools
seem to have been designed and optimized for producing RFCs.  To
the extent to which I have complaints personally (and I have few
-- I'm generally quite happy with it) it is because, while the
RFC Editor produces RFCs, most of us spend most of our time
producing and revising I-Ds.  It is much better now than it was
when the project got started, but, IMO, the places where it
comes up short are in tools for working collaboratively, and
developing and tracking changes, on a document that is a work in
progress rather that one at the last pre-publication stages.

     john

---

From: Dave Cridland <[email-masked]>
Date: Tue, 20 Jun 2006 20:06:06 +0100

> progress rather that one at the last pre-publication stages.

I use a version control system (specifically subversion) and tools 
such as meld - http://meld.sf.net/ - for handling that case. What 
changes is meld's job using a diff between revisions, why is from the 
log entry.

Between them, I find them a sufficiently close fit that I'm not 
looking for anything better.

I specifically don't think that trying to emulate version control 
features in a document format is worth spending effort on.

Of course, if I could convince everyone I co-edit/co-author with to 
use the version control system, I'd be even happier, but it works 
okay even if I proxy their changes in.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Jun 2006 19:48:21 -0400

> features in a document format is worth spending effort on.

+1

(However I could imagine that it would be helpful to have aa structured comment
construct, such as adding date/time attributes, so the comment could explain
what follows and when it was made.  The diff mechanism will then display this.)

d/

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Jun 2006 23:07:55 -0400

--On Tuesday, 20 June, 2006 19:48 -0400 Dave Crocker
<[email-masked]> wrote:

>> I specifically don't think that trying to emulate version
>> control features in a document format is worth spending
>> effort on.
> 
> +1
> 
> (However I could imagine that it would be helpful to have aa
> structured comment construct, such as adding date/time
> attributes, so the comment could explain what follows and when
> it was made.  The diff mechanism will then display this.)

I think that is more or less what I was suggesting, along with
variations on that theme.  I have never thought of that as
either a variation on, or replacement for, version control
approaches.

     john