Composite Name Resolution

Composite name resolution combines resolution in each component naming system and resolution across federated naming system boundaries. There are several techniques for resolving an XFN composite name in the underlying federation of naming systems.

This section describes two implementation techniques for composite name resolution across a naming system boundary. One technique uses an explicit next naming system pointer (NNSP) to resolve across a naming system boundary, while the other uses an implicit NNSP.

An NNSP is the XFN reference of an XFN context in which composite name components from subordinate naming systems are to be resolved. NNSPs are entities that “tie” naming systems together into a federated system. NNSPs can be bound to names, in which case they are explicit NNSPs or junctions. NNSPs can also be nameless, in which case they are implicit NNSPs.

Explicit NNSPs: Junctions

A junction is an atomic name that is bound to an NNSP. It is a terminal name in the superior naming system. There is no limit to the number of junctions bound in a single context, except that imposed by the context. A context can reserve certain names for use as junctions or have other policies for selecting names for use as junctions. The conventions used for identifying junctions and their references are context-specific.

Composite name resolution involving junctions proceeds as follows, depending on whether the context supports strong or weak separation.

A context that supports strong separation and junctions consumes the first component of the composite name supplied to it. The last atomic name of the first component must be a junction. Any remaining components are resolved in the context named by the junction.

A context that supports weak separation and junctions resolves a composite name by consuming leading components until a junction is reached, at which point resolution of any remaining components is continued in the context resolved by the junction. Determination of whether a component is a junction can be done statically, using a syntactic policy, or dynamically during resolution.

Implicit NNSPs

When a context does not want to use part of its namespace for junctions, it uses implicit NNSPs for federating subordinate naming systems. An implicit NNSP is named using the XFN component separator. For example, the name wiz.com/ names the implicit NNSP of wiz.com. Each context can have one implicit NNSP.

Composite name resolution involving implicit NNSPs proceeds as follows, depending on whether the context supports strong or weak separation.

A context that supports strong separation and resolves composite names using an implicit NNSP consumes the first component of the composite name supplied to it. Any remaining components are resolved in the context pointed to by the implicit NNSP of the first component.

A context that supports weak separation and implicit NNSPs in its implementation needs to distinguish the use of the XFN component separator character as an XFN component separator or an atomic separator. This means that such a context needs to know when to exit the current (native) naming system and follow the NNSP. This can be achieved using a static, syntactic policy or a dynamic, resolution-based policy.

With the syntactic policy, a context syntactically discovers where the boundary between its naming system and the subordinate naming system files. This can impose certain restrictions on the syntax of subordinate naming systems. Subordinate naming systems must not permit, as valid top-level names, that are syntactically indistinguishable from names allowed in the superior naming system. For example, assume the superior naming system has a name syntax whose distinguishing feature is that each atomic part must have an equal sign (=). The superior naming system might impose as a policy that subordinate naming systems must not have top-level names with an equal sign in them. Resolution in the superior naming system continues until all leading components of the supplied composite name fitting the syntactic rule are consumed. Any remaining components are resolved in the context of the NNSP of the last component fitting the syntactic rule.

If a context is not able to syntactically differentiate between atomic components and composite name components, or does not want to impose any syntactic restrictions, it might be able to determine the naming system boundary at runtime, during resolution. The policy is to continue resolution in the current naming system until resolution fails, at which point the implicit NNSP associated with the last context at which resolution succeeded is used to continue the resolution. A conflict arises if the same atomic name is bound both in the last context and the context pointed to by the last context's implicit NNSP. In this case, the binding in the last context takes precedence. This way of supporting weak separation requires the context to have the capability of returning remaining unresolved parts of a given name.

Coexistence of Explicit and Implicit NNSPs

Naming systems that implement either technique can coexist in a federation. A naming system that supports composite name resolution using junctions can be federated with one that supports implicit NNSPs, and vice versa.

XFN Links

An XFN link affects name resolution in the following way. Suppose lname is a link bound to the atomic name aname in the context ctx. If at some point resolution of a composite name cname reaches the context ctx and the next atomic name is aname, resolution of aname results in the resolution of the link name lname. This is termed “following the link.” If the first component of the link lname is the atomic name “.”, the remaining components of lname are resolved relative to ctx; otherwise, lname is resolved from the initial context. The resolution of any remaining portion of the name cname proceeds from the reference that results by resolving lname.

The link name can itself cause resolution to resolve through other links. This gives rise to the possibility of a cycle of links whose resolution could not terminate normally. As a simple means to avoid such nonterminating resolutions, implementations can define limits on the number of XFN links that can may be resolved in any single operation invoked by the caller.