[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] FW: SPML 2.0 Response schema is inconsistent
James, Sorry about taking so long to get this. There reason that a PSO ID is called out as an option only one the add response is to allow for the Provisioning Service to define the PSO ID for newly created object based on provisioning data. All other responses are responses to actions on an existing PSO and the PSO ID is not allowed to change as a result of the action. Jeff B. -----Original Message----- From: Hu, James [mailto:james.hu@hp.com] Sent: Friday, September 28, 2007 12:20 PM To: provision@lists.oasis-open.org Subject: [provision] FW: SPML 2.0 Response schema is inconsistent Do any ones know why pso is not consistently defined in some of responses ( see below )? Thanks, James -----Original Message----- From: Ganesan, Chandru Sent: Thursday, September 27, 2007 3:40 PM To: Hu, James Subject: SPML 2.0 Response schema is inconsistent Hi James In the SPML 2.0 specs addResponse and modifyResponse have pso elements defined (see the XSD snippet below). This allows SI request status information to be communicated (SI requestId, SI status, SI request type etc) in the response to the client in the addResponse and nested statusResponse <complexType name="AddResponseType"> <complexContent> <extension base="spml:ResponseType"> <sequence> <element name="pso" type="spml:PSOType" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> However resetPasswordResponse, setPasswordResponse, suspendResponse, resumeResponse do not contain a pso element. - Using extension mechanism (Extensible type) instead of predefined schema (pso element) has a interoperability issue as clients cannot easily bind the response XML to application type. Could you follow this issue with SPML 2.0 standards body? thanks Chandru
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]