xml-dev - Re: Attributes VS Elements

[Rick JELLIFFE <ricko@geotempo.com>]

> Newsha Makooi wrote:
> 
> Should you avoid using attributes?
> 
> Here are some of the problems using attributes:

I am not sure these are so clear.
 
> -attributes can not contain multiple values (elements can)

An attribute can contain multiple values if they are tokens
(e.g. NMTOKEN) or references to other elements (e.g. IDREFS)
and you are using a DTD or schema or private semantics to
let your system know how to interpret the tokens.

> -attributes are not easily expandable (for future changes)

I don't understand this one.

> -attributes can not describe structures (child elements can)

Attributes can describe structures (e.g. xsi:type="html:li"), 
and they can can link to them (IDREF or ENTITY) but they cannot 
contain subelements directly in markup. 

I think the word "describe" is not quite the correct word here.

> -attributes are more difficult to manipulate by program code

This depends on your programming language. I would say the reverse:
because attribute values are either simple or token lists, and
are quite small, they are easier to manipulate by program
code than, in particular, mixed content. E.g  for XPath
to say x/text() rather than x/@y

> -attribute values are not easy to test against a DTD

Element values cannot be tested in DTDs. So I don't understand this one.

> -If you use attributes as containers for data, you end up with
> documents that are difficult to read and maintain. Try to use elements
> to describe data. Use attributes only to provide information that is
> not relevant to the data.

I think the word "describe" is not quite the correct word here. 
Also the word "relevant" looks not quite right: attribute information 
must be in some way relevant
to the element or its data otherwise what is it doing there?  

Martin Duerst has said it well when he says that attributes should
only be used for formal data (i.e. atomic token(s) which conform
to some grammar) rather than informal/freeform data.  But even this
is primarily for internationalization reasons (in particular, to
allow bidirectionality elements, which are needed for middle-eastern
languages) that may not be compelling in particular cases.


Rick Jelliffe