XML attribute vs XML element

Question

At work we are being asked to create XML files to pass data to another offline application that will then create a second XML file to pass back in order to update some of ou

Answer 1

Both methods for storing object's properties are perfectly valid. You should depart from pragmatic considerations. Try answering following question:

1. Which representation leads to faster data parsing\generation?

2. Which representation leads to faster data transfer?

3. Does readability matter?

   ...

Answer 2

Some of the problems with attributes are:

• attributes cannot contain multiple values (child elements can)
• attributes are not easily expandable (for future changes)
• attributes cannot describe structures (child elements can)
• attributes are more difficult to manipulate by program code
• attribute values are not easy to test against a DTD

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.

Don't end up like this (this is not how XML should be used):

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

Source: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

Answer 3

I am always surprised by the results of these kinds of discussions. To me there is a very simple rule for deciding whether data belongs in an attribute or as content and that is whether the data has navigable sub-structure.

So for example, non-markup text always belongs in attributes. Always.

Lists belong in sub-structure or content. Text which may over time include embedded structured sub-content belong in content. (In my experience there is relatively little of this - text with markup - when using XML for data storage or exchange.)

XML schema written this way is concise.

Whenever I see cases like <car><make>Ford</make><color>Red</color></car>, I think to myself "gee did the author think that there were going to be sub-elements within the make element?" <car make="Ford" color="Red" /> is significantly more readable, there's no question about how whitespace would be handled etc.

Given just but the whitespace handling rules, I believe this was the clear intent of the XML designers.

Answer 4

Use elements for data and attributes for meta data (data about the element's data).

If an element is showing up as a predicate in your select strings, you have a good sign that it should be an attribute. Likewise if an attribute never is used as a predicate, then maybe it is not useful meta data.

Remember that XML is supposed to be machine readable not human readable and for large documents XML compresses very well.

Answer 5

It may depend on your usage. XML that is used to represent stuctured data generated from a database may work well with ultimately field values being placed as attributes.

However XML used as a message transport would often be better using more elements.

For example lets say we had this XML as proposed in the answer:-

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

Now we want to send the ITEM element to a device to print he barcode however there is a choice of encoding types. How do we represent the encoding type required? Suddenly we realise, somewhat belatedly, that the barcode wasn't a single automic value but rather it may be qualified with the encoding required when printed.

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

The point is unless you building some kind of XSD or DTD along with a namespace to fix the structure in stone, you may be best served leaving your options open.

IMO XML is at its most useful when it can be flexed without breaking existing code using it.

Answer 6

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