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 our data. During the process we have been discussing with the team of the other application about the structure of the XML file.

The sample I came up with is essentially something like:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

The other team said that this was not industry standard and that attributes should only be used for meta data. They suggested:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

The reason I suggested the first is that the size of the file created is much smaller. There will be roughly 80000 items that will be in the file during transfer. Their suggestion in reality turns out to be three times larger than the one I suggested. I searched for the mysterious "Industry Standard" that was mentioned, but the closest I could find was that XML attributes should only be used for meta data, but said the debate was about what was actually meta data.

After the long winded explanation (sorry) how do you determine what is meta data, and when designing the structure of an XML document how should you decide when to use an attribute or an element?

Answer 1

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

Answer 2

Just a couple of corrections to some bad info:

@John Ballinger: Attributies can contain any character data. < > & " ' need to be escaped to &lt; &gt; &amp; &quot; and &apos; , respectively. If you use an XML library, it will take care of that for you.

Hell, an attribute can contain binary data such as an image, if you really want, just by base64-encoding it and making it a data: URL.

@feenster: Attributes can contain space-separated multiple items in the case of IDS or NAMES, which would include numbers. Nitpicky, but this can end up saving space.

Using attributes can keep XML competitive with JSON. See Fat Markup: Trimming the Fat Markup Myth one calorie at a time.

Answer 3

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 4

It's largely a matter of preference. I use Elements for grouping and attributes for data where possible as I see this as more compact than the alternative.

For example I prefer.....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
         <person name="Rory" surname="Becker" age="30" />
        <person name="Travis" surname="Illig" age="32" />
        <person name="Scott" surname="Hanselman" age="34" />
    </people>
</data>

...Instead of....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person>
            <name>Rory</name>
            <surname>Becker</surname>
            <age>30</age>
        </person>
        <person>
            <name>Travis</name>
            <surname>Illig</surname>
            <age>32</age>
        </person>
        <person>
            <name>Scott</name>
            <surname>Hanselman</surname>
            <age>34</age>
        </person>
    </people>
</data>

However if I have data which does not represent easily inside of say 20-30 characters or contains many quotes or other characters that need escaping then I'd say it's time to break out the elements... possibly with CData blocks.

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" >
            <comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
        </person>
        <person name="Travis" surname="Illig" age="32" >
            <comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
        </person>
        <person name="Scott" surname="Hanselman" age="34" >
            <comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
        </person>
    </people>
</data>

Answer 5

Attributes can easily become difficult to manage over time trust me. i always stay away from them personally. Elements are far more explicit and readable/usable by both parsers and users.

Only time i've ever used them was to define the file extension of an asset url:

<image type="gif">wank.jpg</image> ...etc etc

i guess if you know 100% the attribute will not need to be expanded you could use them, but how many times do you know that.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>

Answer 6

When in doubt, KISS -- why mix attributes and elements when you don't have a clear reason to use attributes. If you later decide to define an XSD, that will end up being cleaner as well. Then if you even later decide to generate a class structure from your XSD, that will be simpler as well.