X A B B C
Figure 6.7: A condensed graph with non-unique nodes.
6.2.2 Self Referencing Names
An important aspect of a naming architecture for condensed graphs is how these names are gener- ated. As every node in a condensed graph is potentially (indirectly) connected to every other node, then a single node’s name may potentially reference every other node in the graph. In the examples of node names provided up to this point in this dissertation, we have referred to other nodes simply by the name of their function tuple. We will see in Section 6.4 that this corresponds to “de facto” name reduction. If instead, we use the full name of the connected nodes, then the node’s name becomes infinite.
Example 6.4 In Figure 6.8, theRentCarnode has been defined in a self referential manner with one round of unfolding, that is, WebCom names of the input nodes are included in the node name. One of the inputs to theRentCarnode is theBuySeatnode. Consequently if this node’s name is constructed, then one of its outputs is theRentCarnode.
△
This increase in name complexity is not necessarily disadvantageous. With increased com- plexity in a name comes increased precision. For example, executingBcan be distinguished from executing B using input that came from C. Name complexity can be addressed when generating names for nodes. When a node is being named, reduction rules are applied to that name in order to simplify the name of the node.
6.3
A Naming Model for Condensed Graphs
SDSI-like local names provide an adequate means to refer to nodes in condensed graphs. In the im- plementation of the naming architecture for WebCom, s-expressions are used to provide the internal representation of node names. For the sake of compact exposition, rather than use s-expressions, we use haskell [98] in this dissertation to describe the naming model. Haskell provides a precise and concise way to specify WebCom names and reduction rules and provides a rigorous notation that can be type-checked and executed to confirm consistency.
(WebComName
(domain (ref: Hertz (ref: Cork)))
(graph (ref: eBookers (ref: Dublin (ref: Alice TravelAgentAp)))) (function (ref: Hertz (ref: Cork (ref: TravelAgentAp RentCar)))) (inputs
(input (WebComName
(domain (ref: Aerlingus Cork))
(graph (ref: eBookers (ref: Dublin (ref: Alice TravelAgentAp)))) (function (ref: Aerlingus (ref: EI220 (ref: Paris (ref: BuySeat))))) (inputs
(input (ref: eBookers (ref: Dublin (ref: Alice (ref: TravelAgentAp E))))) )
(outputs
(output (ref: Hilton (ref: Paris (ref: TravelAgentAp RentRoom)))) (output (ref: Hertz (ref: Paris (ref: TravelAgentAp RentCar) ))) (output (ref: eBookers (ref: Dublin (ref: Alice
(ref: TravelAgentAp Print)))) )
) ) (outputs
(output (ref: eBookers (ref: Dublin (ref: Alice (ref: TravelAgentAp Print))))) )
)
Figure 6.8: A recursive definition of theRentCarnode.
Figure 6.9 gives the haskell definition of a WebCom name. A name is aPnam(primitive name),
Snam(structured name) orLnam(linked name). There is also a zero-arity constructor function,
Empty, that represents an empty, or null, name. Primitive names are strings that cannot be reduced any further. Structured names consist of the familiar five-tuple, domain (dom), graph (grph), function (fun), inputs (ins) and outputs (ops). Each of these tuples can themselves contain completeNameobjects. As there can be multiple inputs and outputs, these tuples can hold lists of
Nameobjects.
The linked name constructor function (Lnam) is used to hold representations of SDSI-like local data Name =
Empty
| Pnam {pnam :: String} | Snam {dom :: Name,
grph :: Name, fun :: Name, ins :: ([Name]), ops :: ([Name])} | Lnam {lnam :: [String]} deriving (Eq, Show)
6.3 A Naming Model for Condensed Graphs 95
names. These local names form lists of linked names, for example:
(Lnam ["Hertz","Cork","RentCar"])
is equivalent to the s-expression:
(ref: Hertz (ref: Cork RentCar))
The definition of a linked name could have been given as a list of linkedNameobjects. However, while such a definition allows for a more expressive syntax, using linkedStringobjects allows for a clearer presentation, and avoids having lists of strings with embeddedPnamconstructors. For example, the name ofRentCarfrom above would instead be specified as:
(Lnam [(Pnam "Hertz"),(Pnam "Cork"),(Pnam "RentCar")])
Linked names consist of irreducible primitives and so are represented as a list of strings.
Example 6.5 Figure 6.10 gives a haskell representation of the name of theCarRentalnode from the Condensed Graph shown in Figure 6.3. In this case,Lnam(linked names) are used to represent
(Snam (Lnam ["Hertz","Cork"]) (Lnam ["eBookers","Dublin","Alice","TravelAgentAp"]) (Lnam ["Hertz","Cork","TravelAgentAp","RentCar"]) [(Lnam ["Aerlingus","EI220","Paris","TravelAgentAp","BuySeat"])] [(Lnam ["eBookers","Dublin","Alice","TravelAgentAp","Print"])] )
Figure 6.10: Representation of theRentCarnode
the linked local namespace of each of the components of the name. For example, the domain of the
node is Hertz’s Cork office. △
Haskell provides three basic derivations for each data type, equality (Eq), display (Show) and ordering (Ord). Eq defines how values are tested for equality; Showdefines how the value is represented on output; Ord defines how objects are ordered with respect to each other. For the moment, we will use the default definitions for bothEqandShowrelations, but will define theOrd
relation separately.
The default definition of the ordering relation (Ord) for theNamedata type does not operate as we require. The standardOrdrelation generated automatically by Haskell does not give us the level of control over name ordering that we desire. For example, we could not support a naming policy that does not want to consider differing domain tuples as causing two node names to be different. For this reason, we define our own ordering forNamein Figure 6.11.
In our ordering for names, the Empty name is the lowest name in the ordering; a structured name is less than another when the components of the former are each less than their respective
instance Ord Name where
Empty <= x = True
(Snam a b c d e) <= (Snam v w x y z) = (a <= v) && (b <= w) &&
(c <= x) && (d <= y) && (e <= z)
(Pnam p) <= (Pnam q) = p == q
(Lnam l) <= (Lnam m) = l <= m
x <= y = x == y
Figure 6.11: Definition of theOrdrelation.
components in the latter; primitive names are either disjoint, or are equal, and so are not ordered; one linked name is less than another when the former is a prefix of the latter. In practice, this relation is redefined based on the requirements of particular applications.
As WebCom names can be self referencing, evaluating this ordering may not terminate when one or more self referencing names are compared. Therefore, care must be taken to avoid this when writing names; one strategy is to design reduction rules that ensure finite names.