Re: Parseable output: --xml option for more commands

(Re: choosing between an XML attribute and an XML element.)

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.

It's very difficult to write a rule of thumb for this. The set of string
values that can be represented in an attribute and in an element is identical.
  Therefore we must focus on the other restrictions, like:

+ An attribute cannot appear more than once.
+ An attribute cannot have internal structure defined with XML mark-up.

So, if we have an element representing a file-system item, and need to choose
representations for its properties (kind, name, ...), then:

"kind": It is inconceivable for the item to have more than one kind ("dir" or
"file" or "symlink" or ...), and although we will probably invent new values
for this field in the future, they will be simple keywords - we can't imagine
wanting them to be structured. Thus "kind" can be an attribute.

"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.

> By this rule, the date, size, type and revision number can be
> attributes, but file name and author cannot.

I don't disagree with your your example.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 19 19:07:04 2005