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...

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.

(See attached file: relationship_example.xsd)

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

          "Jeff Bohren" <jbohren@opennetwork.com>

          08/02/2004 09:36 PM

To: <provision@lists.oasis-open.org>
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

GIF image


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