OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [provision] Draft 22 of the SPML 2.0 XSDs...


1) Okay, let's look for something in-between "insufficientResources" and 
"requestAborted".  ErrorCode#requestAborted is so generic that it could 
subsume just about every other value of ErrorCode we have defined. (In 
a  way, it's more like status='failure'.  RequestAborted due to 
unsupportedExecutionMode, RequestAborted due to invalidContainment, 
RequestAborted due to unsupportedSelectionType....)

Can anyone suggest a better name for this condition?

2) Jeff, are the other issues valid?

Bohren, Jeffrey wrote:

>The error code ErrorCode#'requestAborted' is intended to be generic. The
>originally suggested error code 'insufficientResources' is too specific and
>may not represent the actual error condition. For instance when a PSP is
>streaming back search results the search may be aborted by the underlying
>target. For example if the PSP is doing a long search on a backend LDAP
>server of RDBMS, the search could abort for a variety of reasons, none of
>which have anything to do with the PSP resources.
>
>Further it could be argued that the client has no reason to be concerned
>about the availability of resources on the PSP. 
>
>I am open to other suggested names, but 'insufficientResources' seems
>unreasonable to me.
>
>Jeff Bohren
>BMC
>
>-----Original Message-----
>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>Sent: Tuesday, June 14, 2005 4:53 PM
>To: Bohren, Jeffrey
>Cc: provision@lists.oasis-open.org
>Subject: Re: [provision] Draft 22 of the SPML 2.0 XSDs...
>
>CORE:
>
>ErrorCode#'requestAborted' should be changed to 'insufficientResources'.
>(Value 'requestAborted' is too generic--could apply to virtually any 
>request failure.)
>
>Element <data> in PSOType must be optional (minOccurs=0)
>(This avoids empty <data> elements when returnData='identifier'.)
>
>SEARCH:
>
>Element "iterator" in CloseIteratorRequestType does not need 
>"minOccurs=1 maxOccurs=1"
>(since this is the default cardinality).
>
>Top-level element "closeIteratorResponse" should be type='spml:ResponseType
>(rather than type="spmlsearch:SearchResponseType"). 
>A closeIteratorResponse should contain neither an <iterator> nor <pso> 
>elements.)
>
>Bohren, Jeffrey wrote:
>
>  
>
>>Draft 22 of the SPML 2.0 XSDs is attached.
>>
>> 
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>*Jeff Bohren*
>>
>>13577 Feather Sound Drive, Suite 200, Clearwater, FL 33762
>>
>>tel: 727.561.9500 x219
>>
>>fax: 727.374.0171
>>
>>Jeffrey_Bohren@bmc.com <mailto:Jeffrey_Bohren@bmc.com>
>>
>>www.bmc.com <http://www.bmc.com/>
>>
>> 
>>
>>    
>>
>
>
>
>---------------------------------------------------------------------
>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]