[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] RE: Batch Lookup (was "Re: ReadOnlyProfile")
A correction to my orignal e-mail below: "...authoritative sources of data that have existing processes in place for Attribute Management and as such Updates/Deletes etc are *NOT* permitted" [via the SPML interface] Yes, this would be the minima needed to support conformance to the profile. If you support more, that would be a good differentiator for the implementation. As to support for logical operators beyond 'AND' and the set of matching-operators, this is where I need a bit of help.. Ideally I would like to have support for AND/OR/NOT combined with (=)/(>)/(<)/(>=)/(<=) applied to a specific subset of case-insensitive attributes, but I don't have a sense of how expensive the operations are to implement. Would appreciate some feedback on that point. Regards, - Anil ________________________________________ From: Gary Cole [gary.cole@oracle.com] Sent: Monday, April 04, 2011 6:03 PM To: John, Anil Cc: Smith, Thomas C.; OASIS PSTC Subject: Re: [provision] RE: Batch Lookup (was "Re: ReadOnlyProfile") Thanks! I think I begin to understand. Let me play it back to you to be sure I have it right. The goal is to simplify search() and constrain it so that, rather than being open-ended, search becomes simpler to implement and to test. The first dimension to constrain is that of supported logical operators: AND would be the only operator. Another dimension to constrain would be the set of queryable attributes: here a provider would need a way to advertise the subset of attributes on which it supports search. Do I have that right? If so, let me ask a few more questions. You didn't mention constraining the set of matching-operators; would you want to limit/require certain of these? I assume that you'd want equals (=). Would you also want greater-than (>), less-than (<), greater-than-or-equal-to (>=), less-than-or-equal-to (<=)? What about startsWith, endsWith, contains? Could you get by with just equals and startsWith? (The operators endsWith and contains tend to be rather expensive and inefficient.) For matching-operators on alphabetic values, there's the further issue of case-sensitivity. Would you be prefer to specify case-insensitive matching or case-sensitive matching? Would this be specifying (in effect) minima? That is, you would not object if a provider supported more in the way of search than you require, as long as the specified behavior is supported in a standard way, right? On Apr 4, 2011, at 9:01 AM, John, Anil wrote: My perspective on this is being driven by the need to implement an batch/occasionally-connected interface to an Attribute Provider (AP) that uses SPML as the interface specification. The motivator for the “Read Only” portion is that AP is fronting authoritative sources of data that have existing processes in place for Attribute Management and as such Updates/Deletes etc are permitted. The assumption in this case is that the “Attribute Contract” that is supported by the AP is known and fixed.. i.e. There is a finite set of attributes that are exposed via this interface and are advertised via the listTargets operations At the same time, one of the items that came out of the Burton Group discussions around SPML was that implementing a provider that that supported all permutations of the ‘and’ or ‘or’ and ‘not’ operators combined with all attributes was non-trivial which seems to have ended with little to no support and *no way to verify what support existed* in individual products. So, what I’d like to see in this read only profile is a way to provide a mechanism that limits Search using a combination of specific operators and attributes. i.e. I will allow queries that allow only specific operators combined with specific clauses. E.g. Allow only ‘and’ operations on attributes X, Y and Z. The two use cases that are expected to be enabled by this are: 1) Ability to query the AP to retrieve attributes of multiple users all in one shot, potentially for provisioning use cases 2) Ability to do a one way synch from the AP to a local system.. i.e. The AP will always be the master system that will overwrite the local store The key here is to make sure that the profile itself is constrained enough that it is implementable and testable. I am not sure if I answered your question to the level of detail you are looking for but I am hoping that there is general interest in such a capability. Regards, - Anil From: Gary Cole [mailto:gary.cole@oracle.com] Sent: Tuesday, March 29, 2011 2:44 PM To: John, Anil Cc: Smith, Thomas C.; OASIS PSTC Subject: Re: [provision] RE: Batch Lookup (was "Re: ReadOnlyProfile") In what ways would you constrain search? Would these constraints be minima, maxima or both? A provider constrains the set of object-classes for which the provider supports search in the listTargetsResponse. Search as specified in SPMLv2 is at heart a subset of LDAP search: - scope: 'pso', 'oneLevel' or 'subTree' - operators: 'and', 'or', and 'not' - clauses: dependent on profile or provider, but examples show <attribute-name> = <attribute-value>. The DSML profile looks especially LDAP-like, since DSML is basically LDAP wrapped in a bunch of XML tags. Nothing in the specification of the base protocol nor the DSML profile requires a provider to support fancier search than it wishes to provide. The provider simply returns an error if: • The provider cannot evaluate an instance of {QueryClauseType} that the instance of {SearchQueryType} contains. • The open content of the instance of {SearchQueryType} is too complex for the provider to evaluate. In short, it's entirely up to the provider how fancy to get with search(). We figured that market-pressures would incent each implementer to support search appropriately in its provider. For example, SIM supported search on every type of object. OIM 9.x supports DSML search for users. Gary On Mar 29, 2011, at 8:39 AM, John, Anil wrote: Gary, Search gives you by default the equivalent of a batch lookup. So it does, and a constrained-search profile would meet the functionality we are looking for (based on your description below). Our perspective was shaped in a lot of ways by the reluctance of product implementations to implement anything beyond the basic operations on a SPML provider. Search is an optional capability (and so is batch, but thought that it would be easier to make a case for it). I would be interested to get the perspective of folks who are product implementors to see what would be "easier" to implement for them going forward. At the end of the road, we are looking for something that will exist in real-life within products and not just as shelf-ware. Regards, - Anil ________________________________________ From: Gary Cole [gary.cole@oracle.com<mailto:gary.cole@oracle.com>] Sent: Tuesday, March 29, 2011 9:20 AM To: John, Anil Cc: Smith, Thomas C.; OASIS PSTC Subject: Batch Lookup (was "Re: ReadOnlyProfile") Anil, On Mar 29, 2011, at 7:43 AM, John, Anil wrote: We also need to re-read the specs to see if there is overlap between lookup() and search on what we need to accomplish. Remind me again please what you need to accomplish. I may be able to help. For instance, I may be able to clarify something about your requirements for "SPML Operations on an Attribute Service". You originally thought that you needed "batch pull" capabilities because SAML Attribute Query could not answer the following questions: * "Give me the unique id's of all users with Attribute X" * "For all users (whose unique id's I just got), give me listing of attributes for each (in one shot)" SPML's Search Capability (section 3.6.7.1 of the main spec) gives you all of that in one shot. You can request one search() and in that request use the 'returnData' attribute to specify how much information you want back for each matching object: nothing, identifier-only, data (which would include all schema-defined attributes) or everything, which would add capability-specific data to schema-defined data. Another parameter allows you to specify which capabilities interest you. In your case, you would specify "returnData='data'", so that you would get all of the attributes. Or you could take the default, which is 'everything'. Unless you have capability-specific data, 'everything' is equivalent to 'data'. A client can also specify a maximum limit on the number of matching objects to return. The Provider may send all of the matching objects in a single SearchResult, or the provider may break the results into chunks that the requestor can iterate. Logically, it's still part of a single search result, although a series of iterate() requests may be necessary to return all matching objects. So, please help me to understand what a batch operation would add to this? Search gives you by default the equivalent of a batch lookup. Gary --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]