-- Data model --
1. Every tag and attribute is optionally namespaced by a URI. (Tags usually are, attributes usually are not.)
2. The meaning of a non-namespaced attribute is defined by the tag to which it's applied.
3. The meaning of a non-namespaced tag is defined by the application.
-- Serialization --
4. To save space in the textual representation of XML, namespaces are (necessarily) referenced by user-defined aliases.
5. To save even more space, a default namespace may be (and usually is) defined for use by tags (but not attributes).
6. Alias definitions live in opening tags, and are scoped to the tag itself and all its children. They are of the form xmlns:{alias}="{namespace}", or xmlns="{namespace}" for the default namespace.
7. Tag and attribute names are prefixed with an alias to indicate that they live in that namespace: {alias}:{tag/attribute name}
8. If a tag name is not prefixed with an alias, it lives in the default namespace (if any).
9. If an attribute name is not prefixed with an alias, it is not namespaced.
10. The aliases generally have no semantic meaning, but there are wacky exceptions (e.g. XML Schema).
EDIT, forgot: 11. The "xml" namespace is reserved and predefined as 'http://www.w3.org/XML/1998/namespace'.
Because XML puts the "type" of an object syntactically first, it supports this use case.
Secondly, when you need namespaces, they're a clean, simple solution to the core problem. When you don't need them, don't use them. Fortunately, unlike some of the DTD stuff which is hard to ignore correctly, it's really easy to not use namespaces. If the complexity comes from the problem, trying to solve it with a too-simple solution is not a virtue. You'll just reinvent the same thing, only worse, and with less library support.
For proof... see the endless poorly-supported attempts to do anything even remotely similar for JSON. The good news is that JSON is very simple. The bad news is that when it's too simple, you typically end up with a mess of poorly-designed stuff on top.
Given that you find three semantic rules to be "too complicated", I suspect you'll have a difficult time doing better.
[Edit: rephrase.]
But yes, it's an uphill battle if you don't have a namespace aware XML parser.
The thing that does _not_ work is not using namespaces to decide on the meaning of tags/attributes when processing XMPP :)
Unfortunately, this disqualifies a lot of the less maintained and/or less well-written parsers. It also sometimes disqualifies "bindings" to things like libxml2, when the bindings are written by someone who doesn't understand namespaces and end up wrecking them even though the underlying library supports them fine.
XML namespaces are strange to me. I think they're the simplest example of a standard I consider somewhat simple that to a first approximation nobody understands. It really goes to show that there aren't really all that many people who understand XML qua XML. There's a lot of people who understand "there's angle brackets and attributes and sometimes these entities" and not much more, but there's substantially more meat to correctly understanding XML. Unfortunately (and I mean this fully, not sarcastically or with preaching), to use and implement XMPP requires a somewhat more full understanding of XML than most people have. Namespaces are the biggest sticking point, but XMPP is also a bit quirky in that it tries to have an XML stream, which is sensible enough at the protocol level but often translates strangely up to the API level. (The optimum library for XMPP permits you to use a SAX-like parser for the stream opening, then presents a DOM-like view of each individual element, and there aren't very many libraries that allow both sides of that.)