Re: [provision] statusReturns.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Jeff,

Your suggestion of 'statusOnly' is an improvement on what we currently 
have, but I think we need to take this a little bit further.

1) It appears to me that SPML 1.0 specified (what we would now call) 
'statusOnly' as the default so that a requestor could poll until an 
operation was complete and *then* request the output (or "results"). 

If we change this so that the 'status' operation returns output (or 
"results") by default, then (by default) each poll would transmit data 
(at least partially) redundant with (that of) the previous poll.

2) Even if we adopt the 'statusOnly' approach, I still need a term I can 
use to describe the output (or "results") of a requested operation. 
 
I currently use the term "output" in the draft specification because I 
found the distinction between "result" and "results" too confusing. 
- StatusReturnsType#status actually requests the "result" attribute 
(which is a value of type ResultCode).  Even with your suggestion, 
'statusOnly' actually requests the "result" attribute.
- StatusReturnsType#result actually requests the *output* of the 
operation (which is nowhere formally described, except perhaps in the 
context of specific extensions of SpmlResponseType).

I came up with the term "output" because "results" was simply too close 
to "result". 
What about using the term "content"?

3) I think that the boolean option should request whichever behavior is 
NOT the default.

If returning results/output/content should be the default, then I like 
your suggestion:

    <attribute name='statusOnly' type='xsd:boolean" use="optional" 
 default="false"/>

If returning only status/result should be the default, then how about

    <attribute name='includeContent' type='xsd:boolean" use="optional" 
 default="false"/>


gpc

Jeff Bohren wrote:

>IS this is confusing we should change it. I'm not thrilled with "output"
>since this is a term we have not used yet. I would prefer to keep it in
>terms that we already use. I also think the option of returning the
>status and the resulting data should be the default. How about:
>
>    <attribute name='statusOnly' type='xsd:boolean" use="optional" 
> default="false"/>
>
>Jeff Bohren
>Product Architect
>OpenNetwork Technologies, Inc
> 
>Try the industry's only 100% .NET-enabled identity management software.
>Download your free copy of Universal IdP Standard Edition today. Go to
>www.opennetwork.com/eval.
> 
> 
>
>-----Original Message-----
>From: Darran Rolls [mailto:Darran.Rolls@sun.com] 
>Sent: Friday, November 19, 2004 1:45 AM
>To: Gary P Cole
>Cc: Jeff Bohren; PSTC
>Subject: Re: [provision] statusReturns.
>
>I had trouble with this in 1.0 so i agree with (1); can't answer (2) and
>
>your (3) makes good sense to me...
>
>Darran
>
>Gary P Cole wrote:
>
>  
>
>>The 'status' operation can return either 1) the current state of the 
>>target operation (which is executing asynchronously) or 2) any results
>>    
>>
>
>  
>
>>of the target operation.  The optional 'statusReturns' attribute of 
>>the StatusRequestType indicates whether the requestor wants the 
>>provider to return #1 or #2 above.  The value of  "statusReturns" must
>>    
>>
>
>  
>
>>be either 'status' or 'result'.
>>
>>Have I stated it correctly up to this point?  If not, please correct 
>>me.  If so, hold on, because this is where I think it gets weird.
>>
>>If the statusRequest#statusReturns='status', then the provider 
>>actually returns (in the SpmlResponse that is nested as 
>>statusResponse#currentResponse) one of 
>>{'success'||'failure'||'pending'}.  In other words, asking for 
>>'status' gets you "result".
>>If the statusRequest#statusReturns='result', then the provider 
>>actually returns (in the SpmlResponse that is nested as 
>>statusResponse#currentResponse) any output thus far produced by the 
>>target operation .  In other words, asking for 'result' gets you
>>    
>>
>output.
>  
>
>>1) Am I the only one who finds this confusing?
>>
>>2) Doesn't status always have to return the "result" attribute (in the
>>    
>>
>
>  
>
>>SpmlResponse that is nested as statusResponse#currentResponse) since 
>>the "result" attribute is required?
>>
>>3) Wouldn't it be simpler to have an optional attribute that asks the 
>>provider to return output?
>>Couldn't we replace 'statusReturns' with something like:
>>   <attribute name='returnOutput' type='xsd:boolean" use="optional" 
>>default="false"/>
>>
>>gpc
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster 
>>of the OASIS TC), go to 
>>
>>    
>>
>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
>kgroup.php. 
>  
>
>>    
>>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor
>kgroup.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
>
>  
>