Fog Creek Software
Discussion Board




XML Schema Design

What's the rule of thumb for when to make something a tag or an attribute of a tag?

John Topley (www.johntopley.com)
Wednesday, June 23, 2004

In general I make something a tag when there can be multiple instances of that tag within the parent element.  Attributes are only useful when you need only one of them.

Other than that, I can't think of any good reason to use one over the other.  Maybe someone else knows some other differences.

muppet is now from madebymonkeys.net
Wednesday, June 23, 2004

As an aside, John:  your website is absolutely beautiful.  I'm envious of your composition.

muppet is now from madebymonkeys.net
Wednesday, June 23, 2004

I've heard good arguments for only putting metadata in attributes, since it tends to be short and simple.  Once data becomes complicated or verbose, it becomes difficult to get it into an attribute (or it becomes less readable).

Caffeinated
Wednesday, June 23, 2004

There may be some design implications depending on your parsing model (DOM v SAX)

It seems to me SAX would be quicker with fewer nodes...i.e a recordset with a node per record and fields as attributes

I guess it all depends on what you need to do with the data.

Yo
Wednesday, June 23, 2004

If you're passing around XML to a web service you probably want to eliminate wasted characters to keep size down, changing:

<things>
  <thing>
    <one>foot</one>
    <two>hand</two>
    <three>ankle</three>
  </thing>
  <thing>
    <one>ear</one>
    <two>toe</two>
    <three>shin</three>
  </thing>
</things>

for:

<things>
  <thing one="foot" two="hand" three="ankle"/>
  <thing one="ear" two="toe" three="shin"/>
</things>

But if you've got lots of complex, nested data or large chunks of cdata or something, then attributes certainly make less sense. I'd concur with the "depends on what you're doing with the data" sentiment.

John C
Wednesday, June 23, 2004


I keep it simple and put ID's and IDREF into attributes.  Just about everything else becomes an element value.

KC
Wednesday, June 23, 2004

Thanks all for the advice. And "Muppet", thanks for your kind words about my website :-)

John Topley (www.johntopley.com)
Wednesday, June 23, 2004

out of lazyness i put in as much as possible into attributes.
(that is every thing that is not more than one, and that does not break down into more complex tags).

With the DOM it is easier to look up an attribute by name, than to traverse the list of child nodes and to find the relevant tag (or to fetch the set of subnodes that match the given name and then fetch the first one).

Michael Moser
Thursday, June 24, 2004

i meant everything that is an atomic entity (does not break down into pieces) and that occurs as 0 or one instances.

Michael Moser
Thursday, June 24, 2004

i like to think of attributes & elements as orthogonal. that is, everything is an element. except for metadata, or other data which somehow 'belongs' to a node in some way other than its child.

attributes are unordered; child nodes are not.

i tend to use selectsinglenode for everything.

id & idref sounds terrible.

the worst however is a format like apple's plist. if i remember right, it's something like

<prefs>
<name>name1</name>
<value>val1</value>
<name>name2</name>
<value>val2</value>
...
</prefs>

Er, XML is hierarchcal. It should either be prefs/pref/name and prefs/pref/value, or prefs/pref/@name and prefs/pref/@value. No matching by index please!

mb
Thursday, June 24, 2004

My thoughts are attributes should provide the
context to know how to handle what's inside, ie,
routing information. This is fuzzy in some cases, but
generally doable.

For example, i put the primary key and type info as attributes
so i can create the object  to handle what is inside and
so it can be immediately added to a container object.

son of parnas
Thursday, June 24, 2004

Nouns and verbs are elements, adjectives and adverbs are attributes. 

<sigh/>
Friday, June 25, 2004

*  Recent Topics

*  Fog Creek Home