Here are the comments received from the public review of the SPML 2.0 specification, along with responses from the TC:
Comment from: vannhu2000@yahoo.com
Name: Van NhuTitle: MrOrganization: RMITRegarding Specification: SPML V2 Hello to the list. I have some questions from my earlier days working on a SPML V2 implementation that I would really appreciate you answering. 1. Should we default these flags: CapabilityDataType.mustUnderstand, BulkDeleteRequestType.recursive, and SchemaEntityRefType.isContainer to “false”? For CapabilityDataType.mustUnderstand is not defined, false is assumed (see SPML 2.0 CD1 page 113). If BulkDeleteRequestType.recursive is not defined, false is assumed (see SPML 2.0 CD1 page 72). If SchemaEntityRefType.isContainer is not defined, false is assumed (see SPML 2.0 CD1 page 44). 2. Should we make the attributes: ValidatePasswordResponseType.valid and ActiveResponseType.active both mandatory to avoid unnecessary ambiguities? The request may fail for some reason. If that is the case the response should contain an error status, but not an indication of valid or active. 3. A single Add Request may result in multiple objects being created. For example, based on some provisioning roles/policies, certain end point accounts might get created for each new employee; or a PST might create missing container entries as needed when processing an Add Request. So, should we make the Add Response to return a list of PSOType objects so that auxiliary objects can be included in the response? There are two issues here: provisioning side-effects and containment. For provisioning side effects, other provisioning objects will not be returned in the addResponse. The returned PSO may contain references to side effect provisioned objects, but those objects will never be returned in the addResponse. For containment, there are two kinds. Implicit containment (as done in SPML 1.0) and explicit containment. For implicit containment, creation of the contain objects is out of the scope of this specification. For explicit containment, the containing object must exist prior to creation. 4. The spec says that the cancel request is for stopping the execution of an asynchronous operation, but I think it would be a good idea to also allow cancelling long running synchronous operations, as long as the RA supplies a request id in the initial synchronous request. If a client does not specify that a request is synchronous, the provider has the discretion of converting a synchronous request into an asynchronous. Explicitly canceling a synchronous request would require knowledge of, and an ability to affect, the underlying transport mechanism. 5. For better performance, it would be good if there is a standard way to retrieve only certain portions of the matching objects in the Search and Lookup requests. This is supported for search, but it is defined for a specific profile (see the DSML Profile and the XSD Profile). This is not supported for the lookup request, however the search request can always be used in place of the lookup request. This was a decision made by the TC to keep the lookup request as simple as possible. 6. It would be good if batch/bulk requests can be treated as atomic operations where the RA can specify that partial results must be rolled back for a failed transaction? The decision for a service to treat requests as atomic is up to that service provider. Additionally atomic transactions are being addressed by other standards at the web service level. Transaction semantics could also be defined in a custom capability. 7. Do you think that it would be useful to include in the spec a standard capability for renaming and moving a PSO to a different container in a hierarchical target? While this would be a useful capability, the consensus of the TC is that this will not be added to the SPML 2.0 specification. This will be added to the list of issues to be addressed at a later date. Thanks for your help.Van
Comment from: fred.cummins@eds.com
Name:Fred CumminsTitle: FellowOrganization: EDSRegarding Specification:SPML 2.0This specification does not provide a reasonable description of it's purpose, scope and context of use.
The SPML 2.0 specification refers to the concepts defined in the SPML 1.0 specification. See the SPML 1.0 specification for more details. Also see section 2 in the SPML 2.0 specification for the concepts described there. Additionally the TC is considering publishing a non-normative primer for SPML 2.0. This is not intended to be available prior to the SPML 2.0 ratification.
|
Jeff Bohren |
|
|
|
13577 Feather Sound Drive, Suite 200, Clearwater, FL 33762 |
|
tel: 727.561.9500 x219 |
|
fax: 727.374.0171 |
