--On Tuesday, 20 June, 2006 14:01 -0400 Bill Fenner
<fenner(_at_)gmail(_dot_)com> wrote:
On 6/20/06, Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> 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 _____?
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf