Yes, you're right on the money. They are like packages, not in terms of organization, but in terms of usage.
Think of namespaces as a way to enable use of similarly named tags in a single XML document. Let's suppose you own a retail book store and you are doing your sales analysis for this quarter. You have two XML documents that you received from two different sources - one from the sales department called sales.xml having a tag ( among many others ) named "quantity". The other XML is received from the inventory department called "inventory.xml" that also has a tag named "quantity"!
You have a program that consumes these XML documents
in a combined format and churns out the quarterly sales report. The key here is that the sales program consumes the merged document. But as you can see, when you merge the two documents, the sales program has no way to recognize which "quantity" tag represents the number of books sold.
In order to solve the problem, you use namespaces. The program(XSLT!) that you use to merge the XML document can create a namespace enabled tag such as < sales:quantity > for representing the quanityt from sales.xml. Similarly it can create another tag called < inventory:quantity > for representing the quanity tag from inventory.xml.
With the name collision resolved( now there are no similarly named tags with different meanings ) in the XML document, the sales analysis program can be sure where to look for the sales quantity.
Hope you get the picture. The problem namespaces solve is just not name collision, but name collision
with a semantic difference. It is okay to have similarly named tags in an XML document as long as they mean the same. When the similarly named tag can be interpreted in different ways,
you should start using namespaces.
Hope this helps.
