I relived an intense past discussion while reading Uche Ogbuji’s nice introduction to XML elements and attributes design. We had discussed exactly the same issue, with the exact same examples of date and name to justify our decisions. What we ended up with was a lot different than what any of us had devised, because our examples were comletely out of context. What we realized at the end of the day was that the XML schema has to be first context specific and then compliant with principles. Not to say that the principles are not important, but they do not yield good results unless you have applied your own constraints and specifications first.
I think the biggest disadvantage of XML is that it is very easy to either under- or over-engineer it. The reason maybe that we try to put too heavy a load of expectations on it. We want it to be human-readable, but easily serializable, and easy to export/import from our RDBMS, and compact. Prioritizind might help here. Also, it is important to consider certain side-effects of the design, like parsing ease and speed. Copied and borrowed XML schemas never work, the closer they are to the context, the more they feel right.