On Wed, 2005-01-19 at 13:04, Julian Foad wrote:
> Branko Čibej wrote:
> > I think the rule of thumb should be that any data whose set of values we
> > can't know in advance should be in an element, not an attribute, for the
> > simple reason that attribute contents have more restrictions.
I think your premise is false here. I think you can represent the same
contents in either, although the set of characters which need to be
quoted are slightly different.
> "name": Currently our files can only have one name, but we have talked about
> hard links which is a way of giving a file more than one name. Even if we
> don't think we will ever implement hard links, or want to represent them this
> way in XML, the theoretical possibility is an indication that the file name
> should be represented as an element, not an attribute.
That's, uh, a little far out there. I am quite confident that if we
implement hard links it will not involve giving entries within a
directory more than one name (how would that apply to hard links that
aren't within a single directory?). And if we did, having the cdata
change structure like that would seem pretty traumatic to programs which
parse the "svn ls" output.
So from my point of view, either all fields of an entry should be
attributes or all should be sub-elements, for consistency. (That is, I
don't see anything distinguishing any of the entry fields from each
other, so treating them differently in an XML representation is bogus.)
(Also, I hate XML, partly because it contains redundant concepts like
attributes and cdata content for nodes of its tree. And while XML may
be better-specified than columnar output, it is not particularly
shell-script-friendly. So this whole effort strikes me as misguided.
But you can ignore me on this little sub-tirade, because svn has already
chosen to use XML in various places and experience all sorts of
resulting pain for no benefit, and I'm sure it will continue to do so.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 20 18:11:53 2005