Naming System Boundaries

The What's in a Name? lesson explains in detail how to use a composite name to express a name that spans multiple naming systems. This section explains how a service provider determine which components of the composite name to process and which to pass on. In effect, the service provider needs to determine the naming system boundary that separates its components from those of its (downstream) neighbor.
Strong and Weak Separation

The example shown in the What's in a Name? lesson has the following composite name:
cn=homedir,cn=Jon Ruiz,ou=People/tutorial/report.txt
This composite name has three components:
cn=homedir,cn=Jon Ruiz,ou=People
tutorial
report.txt
The first component belongs to the LDAP naming system, while the second two components belong to the (Unix) file system. As you see from this example, there can be multiple components from the same naming system (tutorial and report.txt are both from the file system), but one component cannot span more than one naming system. So, the correspondence between the composite name component separator--the slash character (/)--and naming system boundaries might not be one-to-one. We categorize service providers into those that treat the composite name component separator as a naming system boundary (strong separation), and those that don't (weak separation):

A provider that supports strong separation treats the composite name component separator as a naming system boundary. When processing a composite name, it will consume the leading component of the name and leave the rest of the components for other naming systems.
A context that supports weak separation might not necessarily treat the composite name component separator as a naming system boundary. When processing a composite name, it will consume as many leading components as appropriate for the underlying naming system.

The primary factor for determining whether a context supports strong or weak separation is the syntax of the underlying naming system. If the underlying naming system has a flat namespace or if it has a hierarchical namespace with a compound name component separator that does not conflict with the composite name component separator, the corresponding service provider will support strong separation. Otherwise, the service provider most likely will support weak separation. Of course, the service provider can get around the syntax conflict issue and support strong separation by requiring that any compound name component separator be escaped or quoted. This might be inconvenient for users of that provider--having to use quotes and escapes--but it might be the only way by which some service providers can support federation. (See below.)
Examples of service providers that support strong separation are service providers for the LDAP, the Windows file system, and the RMI registry. The LDAP naming system is hierarchical and has a comma character (,) as its compound name component separator. The Windows file system is hierarchical and has a backslash character (\) as the compound name component separator. Neither of these compound name component seperators conflicts with the composite name component seperator. The RMI registry namespace is a flat namespace. Examples of service provider that support weak separation are service providers for the COS naming service and the Unix file system.
Conditions for Supporting Weak Separation
Weak separation is convenient. It makes composite names look cleaner (less quotes or escapes required). Users have to be less cognizant of naming system boundaries. However, not all providers can support weak separation. There are some restrictions that may force a provider to support strong separation.
If the namespace syntax is hierarchical and uses a forward slash character (/) as its separator but names are arranged right to left, it cannot use weak separation. The conflicting direction prevents any sensible determination of naming system boundaries.
If the naming system is terminal, (that is, components from that naming system can appear only at the end of a composite name), the service provider can support weak separation. For example, suppose a spreadsheet application's namespace has a syntax that's left-to-right and uses the forward slash character as the component separator. Suppose also that it names spreadsheet cells that will always be terminal. That is, you won't name things relative to a spreadsheet cell. In this case, the service provider for the spreadsheet naming system can support weak separation. Given a composite name, it will consume all of its components.
If the naming system is nonterminal but the service provider can determine the naming system boundary syntactically, the provider can support weak separation. Such a service provider would use a syntactic rule to determine how many components from a composite name to consume. For instance, the compound name components from the naming system might have a distinguishing characteristic that allows the provider to select the components. As a specific example, a DCE X.500 name looks like:
c=us/o=wiz/ou=people
A provider for this naming system can support weak federation by looking for components that has a key/value pair separated by an equal character. Note however that such a provider will have restrictions on what types of naming systems can be federated directly beyond its naming system. In the above example, you cannot federate a naming system that has names that consist of key/value pairs separated by an equal character.
If the naming system is nonterminal but the service provider can determine the the naming system boundary dynamically, the provider can support weak separation. The underlying naming system must be able to return residual unresolved components of names. To determine which components to consume, the provider resolves the entire composite names and based on the result of resolution, use any residual to determine what is not in its naming system.

Federation