Dear Friend, **Meaning** A namespace is a space or context in which names exist. Often the names are required to be unique. A folder on disk is a decent example of a namespace. Within a single folder, there can be only one file with a given name, but there's no harm in having files with identical names in different folders. Active Names are organized hierarchically into namespaces, analogous to domains in the Domain Naming System (DNS) and directories in a UNIX file system. Names within a namespace can be, in turn, namespaces (subdomains in DNS or subdirectories in UNIX); they can also be terminal leaves in the naming tree (machines in DNS, files in UNIX). Each namespace has a program associated with it that is responsible for interpreting that portion of the namespace; this program is free to interpret the names within the namespace in any fashion it wants. A root namespace interprets all names. Each namespace has an owner with the right to determine the program bound to the namespace. The client, by default, is the owner of root. This allows the client to install a program to mediate how its names will be translated. For example, a PDA could install a root program to take whatever is returned by lower level name spaces and compress any images to fit the screen size
What is a hierarchical namespace? A namespace, first of all, is a space or context in which names exist. Often the names are required to be unique. A folder on disk is a decent example of a namespace. Within a single folder, there can be only one file with a given name, but there's no harm in having files with identical names in different folders. When the things that can be named within a namespace can be other namespaces, you get a hierarchical namespace, or tree of namespaces. Again, folders are a decent example, since folders can contain other folders. The domain name system is a perfect example; web addresses, which are based on domain names, are also good. There are a few points I'd like to make about hierarchical namespaces. The components of a hierarchical name can be listed in two different orders, which I'll call descending and ascending. (I'm sure there are official names, but I don't know them … sorry.) In ascending order, one starts at the desired node and ascends, as in the domain name www.urticator.net; in descending order, one starts at the root node and descends, as in the Java class name net.urticator.someproject.SomeClass. Descending order is nice because it presents the names in the order needed for tree traversal, but ascending order is nice, too, because it often displays the most distinctive name first. The names in a hierarchical namespace may or may not be allowed to refer to things other than namespaces. A folder, for example, can contain both folders and files, but a domain name can contain nothing but more domain names. It's true there's information associated with each domain name, but it's not named information—it's more like the properties of a folder. The point I wanted to make, here, is that one can't add more components to a hierarchical name that refers to something other than a namespace. I particularly like to compare java.lang.reflect to java.lang.Integer. Sometimes, the named things exist independently of the tree of names, i.e., are referred to by names but don't in themselves have names (Words Are Not Reality, Nameless Code). If a single thing can have multiple names, that's a good clue. Such things may or may not have a preferred, canonical name—hosts, in the domain name system, do, but files, in a Unix file system with hard links, don't. If the namespaces themselves are allowed to have multiple names, as in Unix, the structure is no longer necessarily a tree, but it's usually reasonable to continue to think of it that way.