OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [provision] SPML 2.0 Relationships proposal...

My understanding was that the reason we wanted creation of containment relationships at the same time as the PSO was to address problems with things like groupOfNames or groupOfUniqueNames, that require a member to be specified. At least that was the discussion I remember from the F2F. I don't necessarily think that this is reason enough to shape the whole relationship approach though. I'm not sure what other resources make containment immutable. Perhaps an example would be persuasive.

I think the terminology I used in my suggestion is causing some misunderstandings. In the COS Relationship interface, a relationship is defined as a collection of roles. These are not roles in the sense used in the provisioning world, they are the roles that objects play in a given relationship. "Contained" is a role, for example, and "Contains" is a role. A Containment relationship is comprised of these roles. It sounds like you didn't get a chance to look at the schema I sent out, which should make this clear, but maybe a name change would help if it's still confusing. There are, in my mind, very few restrictions placed on users of the relationship model I suggested and certainly all of your examples can be easily accommodated. I think it might be more extensible even.

The argument for doing a create of an object and its relationship in a single operation is a good one. Perhaps the use of a relationship operation in a batch would satisfy us both. Fundamentally, I'm just not keen on the idea of extending core requests such as add, modify, and search to incorporate different kinds of relationships. It seems inconsistent to me to use one operation when you want to just add an item, and another when you want to add it and and do something else. And search seems very convoluted. I'm not sure it's a good pattern to propagate in future capabilities either. What I'd prefer would be that there is a single, consitent way to manipulate objects and a capability providing a single consistent way to manage relationships. Overloading a basic set of operations might seem simpler but I don't think it always leads to the appropriate interface for a given application.

Inactive hide details for "Jeff Bohren" <jbohren@opennetwork.com>"Jeff Bohren" <jbohren@opennetwork.com>

          "Jeff Bohren" <jbohren@opennetwork.com>

          08/03/2004 08:05 PM

To: <provision@lists.oasis-open.org>
Subject: RE: [provision] SPML 2.0 Relationships proposal...

You are correct that there is no hard requirement that you be able to create a reference on a PSO when you create it. However this is often a hard requirement for containment. In many resources the containment of a PSO is immutable once the PSO is created.

I do not agree with using role relationships explicitly. While role is one commonly used kind of reference relationship, it is only one of many. For instance PSO representing a computing resource might be “owned” by a PSO for a user. There could be a reference to a core identity PSO to all of the PSOs representing its provisioned accounts. A mainframe account PSO could have references to the PSOs representing terminals that the user can log in from. Expressing reference relationships in terms of roles is just far too restrictive.

To me setting and removing relationships on an existing PSO is a kind of modification. I don’t see any reason why you should not be able to add a reference and an attribute to a PSO in the same request. I also don’t see why you should not be able to create a PSO with both attributes and relationships. If you know all of the information about a PSO at creation time, then why shouldn’t it be one request? That seems much simpler to me. As in my previous email, I see the operations as:

Add (id, data)
Add (container, id, data)
Add (container, id, data, references)
Modify (id, data)
Modify (id, data, references)
Move (id, container)

Why make it more complicated that this?

I was not assuming that we don’t use full XPath expressiveness. The problem I was trying to solve is how to create a search query that combines the XPath expressions needed to select based on the PSO data with the expressions needed to select based on the PSO reference information. If you can suggest a way to do that with only XPath, I would be open to it.

I agree we still have more work to do on the modify request. I will also take a look the modification type problem.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc

Try the industry's only 100% .NET-enabled identity management software. Download your free copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval.

                  "Jeff Bohren" <jbohren@opennetwork.com>

                  08/02/2004 09:36 PM

To: <provision@lists.oasis-open.org>
Subject: [provision] SPML 2.0 Relationships proposal...

GIF image

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]