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: FW: [provision-comment] Review comments to SPMLv2



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?

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.

L406ff error code: additional codes "ATTRIBUTE_OR_VALUE_EXISTS" and "NO_SUCH_ATTRIBUTE". Although mostly relevant for DSML-like systems, nevertheless helpful.

L719 ID: optional for DSML & XSD profiles. Reason: an add may specify the parent (ie. Container) for the new entry, but NOT the id.

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.

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.

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

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.

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?

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?



2. Review items for DSML profile:

L201: the core spec requires that the add response contains the psoID.

L340: must probably read as "...then it is assumed all object classes ..."


Kind regards / Mit freundlichem Gruss
--
Rudi Wöhrl
Siemens AG
Communications
Identity and Access Management
COM ESY SEC DI          Phone:    +49(0)89-636-42554
Otto-Hahn-Ring 6       Fax:      +49(0)89-636-45860
D-81739 München        Mail:     rudolf.woehrl@siemens.com
Germany                Internet: www.siemens.com/directory
 

---------------------------------------------------------------------
To unsubscribe, e-mail: provision-comment-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: provision-comment-help@lists.oasis-open.org



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