Re: [provision] FW: [provision-comment] Review comments to SPMLv2

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Bohren, Jeff wrote:

>I am forwarding these comments from the public comment list.
>
>Jeff Bohren
>
>-----Original Message-----
>From: rudolf.woehrl@siemens.com [mailto:rudolf.woehrl@siemens.com] 
>Sent: Monday, January 09, 2006 3:29 AM
>To: provision-comment@lists.oasis-open.org
>Subject: [provision-comment] Review comments to SPMLv2
>
>In the following you find my comments to the core spec and - very few - to the DSML profile.
>
>1. Review Items for SPML core spec
>
>L297 (target): states that "Exactly one target must contain each object (PSO)", while 
>L32 states that "Every object is contained by exactly one target".  Contradiction?
>  
>
I believe that both say the same thing--I know that I *intended* both to 
say the same thing. 
Is the second statement clearer?

>L365: "listTargets" operation mandatory. This prohibits generic providers (such as LDAP, JDBC) from being deployed as SPMLv2 providers. Instead this requires instance specific implementations. Although they could return a schema, they cannot return a list of targets without instance specific customization. Alternative: listTargets optional and allow listTargetsResponse out of band.
>  
>
I see the attractiveness of skipping listTargets in the simple case, but 
I thought that a minimal listTargets operation was pretty simple.
Since targetID is optional when there is only one target, making 
listTargets optional seems do-able,
but we were trying to keep clear-cut that the core operations were 
mandatory.
I guess I need to understand better the hardship of a minimal 
listTargets operation.

>L406ff error code: additional codes "ATTRIBUTE_OR_VALUE_EXISTS" and "NO_SUCH_ATTRIBUTE". Although mostly relevant for DSML-like systems, nevertheless helpful.
>  
>
Sure, these sound useful, (but these are probably just) nice-to-have.

>L719 ID: optional for DSML & XSD profiles. Reason: an add may specify the parent (ie. Container) for the new entry, but NOT the id.
>  
>
This sounds consistent with our intention (to allow the caller to 
specify the ID, but also to allow the provider to generate and return 
the ID).
Do we currently specify ID as required?  Not sure of the specific 
implications.

>L937 "SPML operations handle capability-specific data separately from schema-defined data": capability data not part of schema? If so, would require manipulation of schema before returning it by the provider. This makes life for providers a bit harder.
>  
>
(We struggled with this throughout the SPML 2.0 design effort.)  The 
schema *may* contain data elements that duplicate capability-specific 
data, but the syntax for capability-specific data must be independent of 
the syntax for schema-defined data, since the schema is arbitrary.

>L1013: allow also to explicitly control capability data in responses. Analogous to L3385 (IncludeDataForCapability). Motivation: scaling problems for references, e.g. groups with a large number of members.
>  
>
What exactly is desired here?  Are we talking about being able to select 
which types of references are returned?

>L1868 Modify: modification of parts of capability specific data. Especially: attributes of references like start/end (i.e. complex references). The schema only allows to modify the capability record as a whole (e.g. reference data element). Obviously, the proposed solution for this is to define extra "linking" objects (cf. L3068).
>  
>
Correct.  That design is a compromise, but I think that the compromise 
is reasonable.  The simple way is to completely replace the reference 
data element.  A more flexible way is to use linking objects.

>L2968 "no more than one reference": in case of parameterized references several references of the same kind, but with different parameters may be allowed. Think of role parameters: e.g. person A is sales rep for customer B from January, sales rep for customer C from March. I suppose this would also be modeled by explicit relationship objects as described in L3068ff.
>  
>
Yes.  Modeling a more complex (e.g., time-qualified) relationship would 
be a good reason to use explicit relationship objects.

>L3281 Search: There is no option for querying a set of objects without implementing the search capability, which in turn requires the iterator feature. That is: either no search or search AND iterator. Although "paged search" is highly recommended, some targets only realize an iterator-less search and thus cannot be supported reasonable effort. Maybe an option such as "acceptIterativeResults" could help?
>  
>
I believe we said (but I'm not sure--we may have left implicit) that a 
provider could implement search without the iterator by returning all of 
the search results in the initial search response.  If it seems 
important, we could mention this explicitly.  This would be similar to 
the way we discuss certain implementation considerations (e.g., the 
timeout for results of asynchronous operations) in the upfront, 
non-normative section that introduces each operation.

>L4120 Update Kind: an object may have been updated by a modification and a capability at the same time. The proposed mechanism would require at least 2 pso elements: one for the modification and one for the capabilities. Allowing the wasUpdatedByCapability string independent of the UpdateKind would allow to reduce result elements.
>The UpdatesResult neither provides the modifications themselves nor current data. Our customers often require a kind of delta search: return all modified, added  and if possible also deleted - objects since the last search, which is indicated by a timestamp or some token. The result set contains the same data as the normal search response. Have you discussed such a feature?
>  
>
We did talk about this, but decided to keep it simple.  The current data 
for each modified object can be obtained through the lookup operation.  
Modification data--e.g., "diffs" or "before-data" or "after-data"--could 
be useful but imposes a burden on the provider to maintain modification 
history for each object.

Defining what data we expect to get back--and, if modification data are 
optional, where the data go--may be the biggest challenge in expanding 
the specification of this capability.