[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Request/response element pairs.
I agree. In order to be consistent, we must do the same thing in the Password and Suspend capabilities. We'll need top-level elements of type spml:ResponseType: - setPasswordResponse and expirePasswordResponse - suspendResponse and resumeResponse Bohren, Jeffrey wrote: >It seems that we should be logically consistent. If we do this in Core, we >should do it for all other capabilities as well. In for a penny, in for a >pound. > >Jeff Bohren > >-----Original Message----- >From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] >Sent: Tuesday, April 05, 2005 3:07 PM >To: PSTC >Subject: Re: [provision] Request/response element pairs. > >I'm almost afraid to ask this, but...should we follow the same logic to >define in the Search Capability a top-level element <iterateResponse> of >type spmlsearch:SearchResponseType? > >This would once again gives us a request/response element pair (in this >case, for the 'iterate' operation) without defining a new type. > >Bohren, Jeffrey wrote: > > > >>Gary's approach seems reasonable to me. >> >>Jeff Bohren >> >>-----Original Message----- >>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] >>Sent: Tuesday, April 05, 2005 2:33 PM >>To: PSTC >>Subject: [provision] Request/response element pairs. >> >>In today's conference call, Rami suggested that each request element >>should have a corresponding response element for reasons of clarity. >>During the conference call, Jeff Bohren objected that defining a new >>type (e.g., BulkModifyResponseType that extends spml:ResponseType but >>adds nothing) would be overkill. >> >>However, it occurs to me that we could add a new top-level element >>without defining a new type. >> >>For example, in the bulk capability where it declares: >> <element name="bulkDeleteRequest" >>type="spmlbulk:BulkDeleteRequestType" /> >>we could add: >> <element name="bulkDeleteResponse" type="spml:ResponseType" /> >> >>I believe that this would meet Rami's goals without defining an >>unnecessary type. >> >>Gary >> >> >>--------------------------------------------------------------------- >>To unsubscribe from this mail list, you must leave the OASIS TC that >>generates this mail. You may a link to this group and all your TCs in >> >> >OASIS > > >>at: >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >>--------------------------------------------------------------------- >>To unsubscribe from this mail list, you must leave the OASIS TC that >>generates this mail. You may a link to this group and all your TCs in >> >> >OASIS > > >>at: >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> >> >> > > > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. You may a link to this group and all your TCs in OASIS >at: >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]