I use the following guidelines in my schema design with regards to attributes vs. elements:
- Use elements for long running text (usually those of string or
normalizedString types)
- Do not use an attribute if there is grouping of two values (e.g.
eventStartDate and eventEndDate) for an element. In the previous example,
there should be a new element for "event" which may contain the startDate and
endDate attributes.
- Business Date, DateTime and numbers (e.g. counts, amount and rate) should be
elements.
- Non-business time elements such as last updated, expires on should be
attributes.
- Non-business numbers such as hash codes and indices should be attributes.* Use elements if the type will be complex.
- Use attributes if the value is a simple type and does not repeat.
- xml:id and xml:lang must be attributes referencing the XML schema
- Prefer attributes when technically possible.
The preference for attributes is it provides the following:
- unique (the attribute cannot appear multiple times)
- order does not matter
- the above properties are inheritable (this is something that the "all" content model does not support in the current schema language)
- bonus is they are less verbose and use up less bandwidth, but that's not really a reason to prefer attributes over elements.
I added when technically possible because there are times where the use of attributes are not possible. For example, attribute set choices. For example use (startDate and endDate) xor (startTS and endTS) is not possible with the current schema language
If XML Schema starts allowing the "all" content model to be restricted or extended then I would probably drop it