If you're designing an XML representation of some type of data, and you want a key-
<sometagorother foo=bar />
Now occasionally I can understand that you might want to layer your own key-
<set key="foo" value="bar" />
because this approach gives you the ability to add extra attributes alongside each key/value pair, which might be useful for all sorts of vaguely sensible reasons: expiry dates, permissions, conditionalisation, you name it. Also it doesn't require you to specify the full set of possible keys in the DTD, which is obviously useful.
However, when I see a third layer of key-
<method name="SetVariable">
<arg key="name" value="foo" />
<arg key="value" value="bar" />
</method>
… I really do start to wonder whether someone's brain has been EATEN BY PARASITIC XML MEMES OF DEATH.
would make some sense. A little. But even then it's less than ideal.
I was going to do an XXML ("eXtensible XML Markup Lanuagage") spoof which has various layers of unnecessary nesting once, but I think that XSLT beat me to it.
<xsl:if test="$pain > $painthreshold">
OWMAKEITSTOP
<xsl:else/>
Subtract 1d20 from SAN and write another line of XSL
</if>
...and then I get to code data import tools at $ORKPLACE that have to generate XSL on the fly to apply to the 50MB+(!) XML files some idiot provider has decided to send our way because the equivalent 200kB of CSV just isn't cool enough these days.
Meanwhile, large companies begin to seriously suggest XML-processing FPGAs as the answer to all this lunacy, which seems somewhat akin to attempting to help a drowning swimmer using a wave machine.
Then again, XML does have one huge advantage: it's not EDIFACT.
However, if it starts looking like your problem will be tricky (or hideously long-winded) to solve in XSLT, it's probably best to cut your losses and just code something yourself with a DOM or a SAX parser.