Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Attributes V's Elements

Status
Not open for further replies.

rbutterwood

Programmer
Dec 7, 2005
3
US
What are the downside of using attributes over extra elements. Several books state that it is purely down to the designer's personal preference on using attributes or elements.

Personally I think that attributes are nicer as it doesn't bloat the xml.

Here are two examples with and without attributes. Which is best?

With Attributes
<RequestBatch ConsumerKey="..." Password="..." Language="..." DateTime="..." SerialID="...">
<Request RequestID="..." Company="..." SerialID="...">
...
</Request>
</RequestBatch>

Without Attributes
<RequestBatch>
<Authentication>
<ConsumerKey>...</ConsumerKey>
<Password>...</Password>
<Language>...</Language>
<DateTime>...</DateTime>
</Authentication>
<Request>
<RequestHeader>
<RequestID>...</RequestID>
<Company>...</Company>
<SerialID>...</SerialID>
</RequestHeader>
...
</Request>
</RequestBatch>
 
There are some reasons why you may choose one over the other.

1. You may want multiple instances of the data, which would work as multiple sub elements, but would not work as multiple attributes with the same name.

2. Attributes are exactly that - they are attributed to the entity they're attached to, and relate directly to that entity - for example:

<address type="home">
<line idx="1">.....</line>
<line idx="2">........</line>
<city>etc...</city>
</address>

An address is most likely to only be of one type - and this attribute defines an address objects top level property. Sub-Entities here are the parts of the address - and are objects in their own rights.

3. Size Matters.. You're right in your comment about size of the structure - doing everything in elements only creates a huge amount of unnecessary overhead, aswell as complicating things.

4. Having every bit of data as attributes is also bad - it would get very complicated very quickly and likely to make maintenance and development a nightmare.

5. Content Type is also important - having CDATA type stuff in an attribute isn't going to work too well..! Lots of descriptive text would make attribute use very difficult.

As you've noticed there is no hard and fast rule - it is very subjective, but the key is not to get carried away with either method and to try and think about the data as objects with relationships - each entity with properties of its own, and sub level entities that themselves can have their own properties.

In your examples above I would say the first one is nearer the truth, but without knowing the data structure it would be difficult to tell - if for example there could be more than one Language involved, the first example would not work.

Finally, you also need to think about extensibility (well, kinda appropriate..!) - as requirements change, so do the supporting data structures; use of mainly attributes or only elements could be preclusive to an easy change, as most changes here will need to be reflected in higher level code.

Hope that helps.

A smile is worth a thousand kind words. So smile, it's easy! :)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top