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.
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Tuesday, August
03, 2004 5:16 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] SPML 2.0
Relationships proposal...
Jeff,
It's great to have a straw man to focus on. I just have a few comments and
questions. It seems to me that the approach of extending core operations,
particularly for add, is driven mostly by the problem that we discussed at the
F2F, i.e. the need to have a PSO available when the relationship is created. Is
this really a valid constraint to place on ourselves? I'd like to revisit this
because I would prefer that we not use derived operations in general - my
preference would be for a relationship interface that is not so coupled to the
core operations. For example, I was imagining something similar to the Cos
Relationships model. In that world view, a relationship is simply a collection
of roles. I've attached a schema that reflects something like the same model.
If we were to follow in spirit of this approach, the schema would be
accompanied by an operational interface primarily consisting of operations
like:
Relationship create(Roles roles);
Relationship add(Relationship relationship, Role role);
Relationship remove(Relationship relationship, Role role);
Relationships remove(Role role);
Relationships getRelationships(PSOIdentifier pso, Role role);
Relationships getRelationships(PSOIdentifier pso);
Roles getRoles(PSOIdentifier pso);
...and so on, or something like it.
There are a couple of things in the proposal that reflect problems that I see
in the core schema:
1. Modifications. We still have not fully filled out the modification portions
of the schema.
2. Search. We talked before about being more specific in the definition of a
search syntax. I am still in favour of doing that. When I was suggesting a
subset of XPath though, I wasn't suggesting that we eliminate all of the XPath
expressions. In particular I think it would make sense to keep the boolean
expressions (and, or, !=, =, <=, <, >, >=). If we did opt for a
well-defined XPath-like syntax then it wouldn't make sense in my mind to
redefine these types of expressions here. This whole subject warrants more
discussion in my view.
By the way, there seems to be an error on line 138 of version 5 of the schema.
I think 'type="spml:ModifyRequestType"' should in fact be
'type="spml:ModificationType"'. Also, on line 189 the use of an
element and an any in the sequence is problematic. I changed the
"appliesTo" element to an attribute to get around this.
Gerry
(See attached file: relationship_example.xsd)
"Jeff
Bohren" <jbohren@opennetwork.com>
|
"Jeff
Bohren" <jbohren@opennetwork.com>
08/02/2004 09:36 PM
|
To:
<provision@lists.oasis-open.org>
cc:
Subject: [provision] SPML 2.0
Relationships proposal...
|
Attached is the first draft of my proposal for handling relationships. This
covers both containment and references. It supports references with attributes.
It also supports relationships (both kinds) as search criteria and also as
search results. I believe that this proposal meets all of the requirements
discussed so far.
This proposal is based on draft 5 of the SPML 2.0 schema.
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.
To
unsubscribe from this mailing list (and be removed from the roster of the OASIS
TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
#### ONT
Relationships Proposal v1.doc has been removed from this note on August 03, 2004 by Gearard Woods