tidy-bowl - BETA invitation!

[Paul W. Frields]

Greetings FDPers,

Tommy and I have been collaborating on a method to mitigate our problems
with multiple editors.  When FDP started, we envisioned a beautiful,
pristine world in which everyone used Emacs+psgml -- pipe down,
Tommy ;-D -- and collaborating writers and editors would not end up
reformatting each other's work, since they were using the same tools.
However, that expectation has proved somewhat unreasonable, especially
in light of (1) our goal to lower barriers for entry as far as possible,
and (2) the proliferation of XML editors out there.  As a result, the
FDP canon will, in all likelihood, no longer require people to use
specific tools, although a preference for Emacs+PSGML is likely to
linger, since the majority of the editors are using those tools.

An XML normalization engine (xmlformat) will reformat docs when they are
imported or committed to CVS.  It uses a configuration file which should
not complicate life for writers or editors using most tools of which
we're aware.  Because the normalization does not change the actual copy
of the file on your disk, you don't have to worry about how the
committed version might have different whitespace, margins, blocking,
etc. from your copy on disk.  You simply keep editing as usual.  Any
person checking out a file from CVS will get the normalized version,
which they can feel free to *reformat* locally.  Any such changes will
be "stripped" when commits are made.  Only the content matters.

CAVEAT:  Once you make a change to a .xml document where your local copy
is NOT normalized, when you use the "cvs diff" command, the diff will be
very long because of the normalization differences.  Sorry, folks, that
part's out of our hands; it was the price we paid to allow more tools
out there, and it seems worth it.  The diff that actually ends up going
to the fedora-docs-commits list from the CVS server *will* be sane.

If you must have a sane local diff, you can run "cvs up -C <file>" to
replace your non-normalized file with the normalized version from the
repository.  If you have uncommitted work in the file, commit it before
you run that command, or it will be lost.  The only drawback is that
your editor may want to reformat the file again when you next load it.
This will not affect CVS.

So now, THE INVITATION:

For now, the only module that is normalized is the xml-normalize/
module.  Please feel free to add files there and observe the results...
i.e. beat on the script.  If something breaks, please report problems to
the list, Tommy, or me.  Please check the log for a file before you
diddle with it, so as not to inconvenience another tester.  Thanks and
have fun!

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20050628/e9b64d9e/attachment.bin