-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 27 January 2003 18:35, cmpilato@collab.net wrote:
The reason for the change is really simple. XML is a bit pickier
about what can be in its attribute data, such that we would need
special handling for characters (like tabs) that can't exist in those
fields. The CDATA allows a wider range of characters. So, using the
example of a file with a tab in its name, as an attribute that need to
be stored as name=filename, whereas using CDATA we can use the
regular name, tab and all. Both fields still require escaping of ''
and '', which my code is also handling.
If you care for my opinion, I disagree with this:
* Conceptually, the name of an entry is an attribute of the entry. That's
why I think it should remain an attribute of the entry element.
* Making the name CDATA essentially prohibits adding children to the
entry element in the future. Who knows what those could be, but why
eliminate that option? (Yes, technically there is no restriction on
CDATA+children together, but it's ugly as hell, and whitespace from
pretty-printing becomes a big issue.)
* Would newlines in filenames still need to be encoded? They're legal
under UNIX, and work fine in XML, although they ruin any pretty-printing.
But what about carriage returns in filenames? XML's newline normalization
still requires them to be escaped.
* Code-wise, it is hardly more complicated to encode tabs as in
addition to and .
I'm 'make check'ing now, though my hand tests leave me no reason to
doubt the integrity of this change. I'm basically seeking feedback
from the community on whether or not I should commit the change to our
tree.
So I guess it raises more issues than it solves, and it doesn't *really*
solve anything, since there was no real problem previously. Does anyone
have any problems with my arguments?
If you still want to have the name as CDATA, then I would advocate the
addition of a name element instead:
entry ...
namefoo/name
/entry
This keeps the conceptual name-is-an-attribute model clear, and keeps the
body of entry open for future additions.
Oh yeah, while we're on the topic of entry names: would you care to clean
up the svn:this_dir hack? Perhaps if changed to a name element, the
lack of such an element could mean the current dir?
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+Nf6QhDAgUT1yirARAvAkAJ0dUu8b76lquDyT0GXheZqabTYDVwCeLWfW
pYyxWI5+Od5uVBq2VWKg0JA=
=oJFR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:20:58 2006