RE: [provision] FW: SPML 2.0 Response schema is inconsistent

["Bohren, Jeff" <Jeff_Bohren@BMC.com>]

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