The scenario that has inspired the design of the identifier is one where the Conzilla user is using components from several places simultaneously. Realistic locations include: local harddisc, a database on the company LAN (the MOF case), and different sources on the Internet. One could imagine that the company database actually exports several components for use over the Internet, by different users using different browsers. This is already enough to describe several important characteristics of the identifiers:
One component must have only one identity, i.e., if there are several methods of accessing the component, the identifier cannot depend on the method used. Consider a component located on the company database, that can be accessed both from inside the LAN and over the Internet. It is probable that you could want to access the database directly when inside the LAN, but use a web server for outside access. Still, other components referring to the component must use the same identity, as they do not know if they will be used inside or outside the LAN.
The format of the identifier must be useful in several different environments, which means that it cannot depend on, e.g., the programming language.
As the example above shows, some sort of resolving mechanism may be necessary for certain components. We really do not want to build this mechanism into the specification, so we instead want the identifier to allow future expansions in this direction.