XFN Composite Names
This appendix describes XFN composite names in detail.
Syntax
The standard string form for XFN composite names is the concatenation of the components of a composite name from left to right, with the XFN component separator character (/) separating each component. Components can be quoted using either double-quote ("") or single-quote ('') pairs. You can use a backslash character (\) to escape the XFN component separator or quote characters if the intention is for these characters not to behave as separators or quotes. Note that quotation marks and escape characters are interpreted as such only when they appear in places that need quotes or escapes. For example, a quote appearing in an unquoted component is not interpreted as a quote.
XFN defines an abstract data type, FN_composite_name_t, for representing the structural form of a composite name. XFN also defines the syntax of how component string names are composed into an XFN composite name and the corresponding rules for converting an XFN composite name to its structural form from its string form, and vice versa. The XFN client interface includes operations that perform these conversions.
Table A-1 contains some examples of how the string form of XFN composite names are decomposed into components according to the syntax of XFN composite names. See also "Composite Name Encoding" for more information.
Table A-1 String and Structural Forms of XFN Composite Names
String form | Components in FN_composite_name_t |
|---|---|
a | a |
a/b/c | a, b, c |
a/ | a, "" |
/a | "", a |
a// | a, "", "" |
a//b | a, "", b |
"" | "" |
/ | "", "" |
// | "", "", "" |
"a/b/c"/d | a/b/c, d |
"a.b.c"/d | a.b.c, d |
a.b.c/d | a.b.c, d |
a"b/c | a"b, c |
a'b/c | a'b, c |
"a/b/c | illegal name |
\"a/b/c | "a, b, c |
a\b\c/d | a\b\c, d |
a\b\/c | a\b/c |
"a\"b"/c | a"b, c |
'"a/b/c"' | "a/b/c" |
'a\/b'/c | a\/b, c |
a\\b/c | a\b, c |
a/\"b |
Composite Name and Naming System Boundaries
There might not be a one-to-one correspondence between component separators and naming system boundaries if a composite name contains names from naming systems that use the same character as the XFN component separator to separate their atomic names. Consequently, a component of a composite name might represent an atomic name from a hierarchical naming system that uses the XFN component separator or a compound name. Strong separation and weak separation refer to how a context considers the XFN component separator as a naming system boundary.
Strong Separation
An XFN context that treats the XFN component separator as a naming system boundary supports strong separation. An XFN component separator that appears within a component to be resolved by the context must be escaped or quoted.
Support for strong separation is a property of a context. A context that supports strong separation expects to receive the name that it is going to resolve entirely in one component of the composite name structure. When a composite name is supplied to such a context, it consumes the leading component of the name; any remaining components are left to be resolved by subordinate naming systems.
An XFN context with a name syntax that is either flat or hierarchical, and does not use the XFN component separator as its atomic separator, supports strong separation. Examples of naming systems that support strong separation are DNS and NIS+, both of which have right-to-left dot-separated names. The following are examples of names with DNS and NIS+ components, respectively.
.../wiz.com/orgunit/ppt orgunit/accountspayable.finance/user/jsmith |
Weak Separation
An XFN context that does not always treat the XFN component separator as a naming system boundary supports weak separation. This arises when the component naming system associated with the context uses the same character as the XFN component separator as its atomic component separator. The context allows its atomic separator to appear unescaped and unquoted in its compound names when they occur in composite names. This means that an XFN component separator might not necessarily signify a naming system boundary.
Support for weak separation is a property of a context. A context that supports weak separation expects to receive its atomic names in separate components of the composite name structure. When a composite name is supplied to a context that supports weak separation, the context consumes the leading components of the name (and treats them as atomic components); any remaining components are resolved by subordinate naming systems. The number of components consumed is determined either syntactically or dynamically.
CDS names and X.500 names are examples of names that use the XFN component separator as their atomic name separator. X.500 supports weak separation using a syntactic method (by scanning for typed names) while CDS supports weak separation by determining the naming system boundary dynamically.
The following example shows a composite name with an X.500 component.
.../c=us/o=wiz.com/orgunit/ppt |
Note - An XFN context that supports weak separation using only syntax-specific discovery of its naming system boundary might not always be federated with arbitrary subordinate naming systems. If the subordinate naming system has a naming syntax that is indistinguishable from that of the superior naming system, the superior naming system is not able to identify the naming system boundary.
Naming systems that use the same character as the XFN component separator as their atomic separator, and which cannot support weak separation because it cannot use a syntactic or dynamic method to determine the naming system boundary, must provide context implementations that support strong separation. This means that occurrences of atomic separators must be quoted or escaped when they appear in compound names within composite names.
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.