XML's style

[howachen]

Consider the following 2 XML formats, which style you prefer?

1.

<Server>
<property name="host" value="192.168.11.2" />
<property name="database" value="test" />
<property name="user" value="user" />
<property name="password" value="password" />
</Server>

2.

<Server>
<host>192.168.11.2"</host>
<database>test</database>
<user>user</user>
<password>password</password>
</Server>

 

[Stefan Ram]

Consider the following 2 XML formats, which style you prefer?

<server host="192.168.11.2" database="test" user="user" password="password"/>

 

[howachen]

Stefan Ram 寫é“：

<server host="192.168.11.2" database="test" user="user" password="password"/>

of coz we can use attributes if the list just containing 4 settings...

this will cause a problem when the settings extends to say 20
settings...

 

[Stefan Ram]

of coz we can use attributes if the list just containing 4 settings...
this will cause a problem when the settings extends to say 20
settings...

Which problem?

 

[howachen]

Stefan Ram 寫é“：

Which problem?

sorry..this is not a problem...but a concern of style.

people tends to use elements instead of attributes....too many
attributes is no good?

 

[=?ISO-8859-1?Q?J=FCrgen_Kahrs?=]

<server host="192.168.11.2" database="test" user="user" password="password"/>

Me too. Attributes are definitely the right choice
in this case (distinct parameter names, each occurring
only once).

 

[Stefan Ram]

people tends to use elements instead of attributes....too many
attributes is no good?

Usually it is not good.

But too many attributes are a problem of the definition of the
entity »server« that is unrelated to the notation »XML«.

 

[howachen]

Stefan Ram 寫é“：

Usually it is not good.

But too many attributes are a problem of the definition of the
entity »server« that is unrelated to the notation »XML«.

a more generic case:

<Book>
<Title></Title>
<Author></Author>
<ISBN></ISBN>
<Description></Description>
<Price></Price>
.....
</Book>

should we also use attributes instead?

 

[Joe Kesselman]

people tends to use elements instead of attributes....too many
attributes is no good?

This is a FAQ. See past discussion. In general, use attributes when you
want to help refine the description of something, child elements when
you want to give the information it contains -- BUT remember that
attribute values are unstructured, and if at any point you're going to
want to have structured data it's going to have to be an element. Also
remember that attributes only allow a single instance per element; if
there will ever be more than one, that too pushes you toward elements.

Beyond that, it's very much a matter of taste. There's no limit on the
number of attributes, so if you really need 20 different qualifiers on
an element you can do it that way just as easily as via child elements.
Though any single datum with 20 fields is probably made up of several
sub-structures, and you should consider whether it's better
architecturally to break those out.

 

[Joe Kesselman]

Consider the following 2 XML formats, which style you prefer?

Of those two, the second. There are VERY few situations in which the
<property name=... value=...> is better than a named element.

 

[Stefan Ram]

<Description></Description>
should we also use attributes instead?

»Yes« for most of the cases. However, the »Description«
might be a problem, when it needs to contain XML-tags
itself. Then the rules of XML enforce it to be given
as a subelement. For uniformity, one then might decide
to give all other properties as subelements, too.

 

[howachen]

Stefan Ram 寫é“：

»Yes« for most of the cases. However, the »Description«
might be a problem, when it needs to contain XML-tags
itself. Then the rules of XML enforce it to be given
as a subelement. For uniformity, one then might decide
to give all other properties as subelements, too.

thanks!

 

[Stefan Ram]

This is a FAQ. See past discussion. In general, use attributes when you
want to help refine the description of something, child elements when
you want to give the information it contains -- BUT remember that
attribute values are unstructured, and if at any point you're going to
want to have structured data it's going to have to be an element. Also
remember that attributes only allow a single instance per element; if
there will ever be more than one, that too pushes you toward elements.

Unfortunately, this overwrites - or partly contradicts - the
first rule of thumb. Therefore, the situation is somewhat
confusing.

(For this reason, I have developed the notation »Unotal« with
a Java-implementation [released under the GPL], which allows
structured and repeated attributes.)

 

[Joe Kesselman]

Me too. Attributes are definitely the right choice
in this case (distinct parameter names, each occurring
only once).

.... with simple string values.

But those features mean the values *can* be attributes. It doesn't
necessarily mean attributes are better.

What would make me prefer attributes in this case is that those values
were inherent properties of the server description. In this case, they
aren't -- the network address is, but the database and user are really
attributes of the service or connection being made at that server. If
that's what you're trying describe, I'd be inclined to rename the server
element, or restructure it as an element which contains a <server> where
the latter describes only the server itself. (Probably just rename, but
that would depend on how this is actually being used.)

 

[Joe Kesselman]

Unfortunately, this overwrites - or partly contradicts - the
first rule of thumb. Therefore, the situation is somewhat
confusing.

That's why these are only rules of thumb. Understand the principles,
then do what makes sense for your case.

Some folks argue that XML attributes shouldn't be used at all, which
solves the problem but strikes me as a case of throwing the baby out
with the bathwater.