[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-01-19 19:04:32 CET

(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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.