[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Containment in the Core? (was "Re: [provision] Relationship models")
Darran Rolls wrote: > 4 - To allow the following relationship types to be expressed: > 4.1 Containment at the point of PSO creation and as an optional > interface. A sample containment relationship would be between and > organization and its members CONTAINMENT AT CREATION We thought that we could express containment at the point of PSO creation by adding a 'parent' parameter to the 'create' operation; the target is the default parent. Another approach would be to define a 'createChild' operation within an optional interface. The provider would then advertise in the target capabilities the set of object types for which this operation is supported. ADDITIONAL CONTAINMENT OPERATIONS What else (that is, what other operations) would we need to support containment? I think we'd want to be able to: - setParent (rebind an object beneath a specified parent) - getParent (return the object beneath which the specified object is bound) - listChildren beneath a parent (oneLevel or allLevels) - ? getChildren beneath a parent (oneLevel or allLevels) - query based on containment (e.g., "hasParent" or "hasChild") relationships Note that if we support query based on containment, then we don't really need 'getParent', 'listChildren', or 'getChildren'. (However, we'd still need 'setParent'.) SUGGESTIONS It's probably too early to know whether we want to reflect containment in the core. However, we may be able to "cluster" the options and propose two alternatives. IF CONTAINMENT IS IN THE CORE If the core operations support containment, then I'd suggest we not add a bunch of new operations: - 'create' takes an optional 'parent' arg (default parent is the target) - 'search' recognizes two special attributes: 'hasParent' and 'hasChild' whose values are PSO IDs. NOTE: At this time, 'search' is not in the core. It is defined in an optional interface. IF CONTAINMENT IS AN OPTIONAL INTERFACE If containment is an optional interface, then I'd suggest that we make containment-related operations explicit: - 'createChild' // creates an object beneath a specified parent. - 'setParent' // moves/rebinds an object beneath a specified parent. - 'getParent' // returns the parent of a specified object. - 'listChildren' (oneLevel or allLevels) // returns the ids of objects bound beneath a specified parent. ? 'getChildren' (one Level or allLevels) // convenience method; not sure we want this. We must either add an explicit 'createChild' operation or enhance the core 'create' operation to add an optional 'parent' argument. (Otherwise, if 'create' binds objects directly beneath the target, a requestor would have to first create an OU under the target and then move the OU to its parent. This will probably cause name collisions, which the requestor would have to work around by creating, moving and then renaming. Kinda clunky.) It seems slightly asymmetric to enhance the core 'create' verb to specify containment and not to support querying for children or parents. (I could live with it, but it feels weird.) If containment is not part of the core, then it seems most consistent to have the optional interface define a 'createChild' operation. JUST TO TAKE A POSITION Unencumbered by knowledge, I'd say that I'd prefer to have containment be an optional interface. We want to keep the core operations as simple and generic as possible, and containment would require some complication (and may impose some semantics--e.g., with respect to naming). We also said that we wanted the core operations to apply to everything, and not every type of object will have a parent. Defining containment as an optional interface allows a provider to specify (via target capabilities) for which object types it supports containment. Gary
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]