RE: [provision] Request/response element pairs.

["Bohren, Jeffrey" <Jeff_Bohren@bmc.com>]

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