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