[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Groups - 2.0-Relationships.pdf uploaded
Gary and Doron, to better explain: PML can FULLY provision Connections as follows: <xsd:extension base="spml:SpmlRequest"> <xsd:sequence> <xsd:element name="identifier" type="spml:Identifier" minOccurs="0" maxOccurs="1"/> <xsd:element name="identifier2" type="spml:Identifier" minOccurs="0" maxOccurs="1"/> <xsd:element name="attributes" type="spml:Attributes" /> I added a line for identifier2 in my copy of spml 1.0 xsd. It is an optional identifier, so the request may have a Pair of identifiers. That means any SpmlRequest can have 2 Identifiers. And everything else remains the same, we keep the basic set of SPML commands. When the RA-PSP exchange occurs for a pair of identifiers like (user1, group1) - objectclass can be Connection and an attribute/value in the Attributes sequence can be connectionType=RACFGroupMembership. Thus we cover every functionality needed to provision Connections. That means we do not need connect and modify-connection commands: Connect is done via spmlAdd (id1,id2) Modify connection is likewise spmlUpd(id1, id2) Similarly Disconnect will be done by spmlDel(id1,id2) SchemaExchange I think is typed in spml 1.0 by the objectClass. The objectClass determines the set of Attributes (the schema). To cover Connection, the Schema Exchange must also have objectClass=Connection, and an attribute ConnectionType=RACFGroupMembership, if it is desired to have this granularity of SchemaExchange. The main point is Identifiers pair as an option of every SPML request. And solve all issues while keeping simplicity - to have full coverage of "provisioning a connection". That is - give SPML implementations the power to provision Connections while containing this power in the SPML commands (with two identifiers) - and not in any complex data model. My point Gary is not to limit (id1, id2) to objectClass=Connection. In other words - avoid a fixed affinity between the presence of Two identifiers and some fixed concept (connection) in the Data Model. Its just two identifiers in the SPML verb/command, that will allow full semantics of provisioning Connections - by minimal change in the Verbs (spml commands) - change to support from now TWO identifiers. I hope I clarified the basic idea of identifiers pair. Sorry - I am not up to date of spml 2.0, and hope that referring to spml 1.0 - just to explain this particular idea - is OK. Shmuel Koller Bank Leumi --- Gary P Cole <Gary.P.Cole@Sun.COM> wrote: > Shmuel, > > Thank you very much for your suggestions. I > appreciate you contributing > new ideas to this discussion. My questions and > comments are inline below. > > Shmuel Koller wrote: > > >Minor requirement point - I think for completness > of > >this particular discussion - SPML search needs > also > >to support Retrieval of "connection attributes" in > >addition connect and modify-connection. So we need > >schema attributes for connection once again as per > >Gary concern Third step below. > > > > > 1) I suggested that we do not necessarily need a > verb to > 'modify-connection' if the 'connect' verb is > understood to modify any > existing connection between the specified objects. > What is your opinion? > > 2) I suggested that we _would_ need some kind of > schema for a complex > connectionType (and I asked Doron whether he agreed > with that > assessment). If am secretly hoping that there is > some way to avoid > having to expose schema for complex connection > types, since this adds > overhead to the implementation, but I do not see how > we could do that. > > To be perfectly plain about my bias, I do not want > to add support for > complex relationship types if this complicates > support for simple > relationship types. > > > >The solution is I think between Long Island and > >current discussion. Support Primary Identifier and > >Secondary identifier (order is important, to the > PSP > >implementation). > > > >This will keep SPML simple - as all provisioning > basic > >commands will apply to connections, via > specification > >of a Pair of Identifiers, also Schema exchange. > > > How would schema exchange apply to identifier pairs? > Are you suggesting > that a pair of types is also a type, so that > {Type1,Type2} could have > its own schema? > > > > > > >That done - it does not limit the semantics of the > >Identifier Pair to mean "connection" but anything > that > >the PSP wishes, and again - the identifier orders > >order can matter or not to the implementation. > > > > > This is an interesting possibility, but I'm not sure > that I find that > degree of freedom to be attractive. One of our > goals for SPML 2.0 is to > make the protocol better reflect the domain of > provisioning. I think I > like the idea of an identifier pair better if an > identifier pair > *always* refers to a connection. > > >With SPML 1.0 and its verb "simplicity yet powerful > >for provisioning" - that was a choice - to > implement > >the Connection pair of identifier as "string > >concatenation" > >into one SPML identifier. I think its worth to let > >SPML express an Identifiers Tupple (or at least > pair) > >and keep its command set simple - while enriching > the > >data model (to FULLY express provisioning of > >connections, but not represent them). > > > >I think the pair of identifiers can be considered > as > >much stateless and non-persistent as one identifier > - > >for this matter. Its just a "key" for the SPML > >provisioning command. And - at the same time it > >provides full coverage for provisioning > connections, > >where (if and only if implementation wishes so): > >spmladd(id1,id2) - means connect > >spmldel(id1,id2) - means disconnect > >spmlget(id1,null) - as if just id1 > >spmlget(id1) - will cascade to delete connection > >(depends on implementation) > > > > > I think you meant "spmldel(id1) - will cascade to > delete connection", right? > > Again, I think that this idea is interesting and > powerful, but I'm > concerned that it may be overly abstract. I think > that I prefer to have > explicit 'connect' and 'disconnect' operations. > > We've done a fair amount of work (after a great deal > of discussion) to > separate the verbs proposed for SPML 2.0 into > separate core and optional > interfaces. This allows each provider (and indeed > each target) to > declare which operations it supports. This > suggestion would take us > back in the other direction, making it more > difficult to determine which > "flavors" of an operation a provider supports. > > >The SPML opportunity here to stay simple and > powerfull > >is that ConnctionType is an Attribute of (id1,id2) > > > > > > I would like to better understand this suggestion. > I can imagine that a > connectionType might be represented as an attribute > of (Type1,Type2) in > the schema, but I do not see how a connection > *type* could be an > attribute of two *instances*. That's probably not > what you meant. What > did you mean? > > Thanks, > > Gary > > > 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. > > __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]