Optional operation request/response types.

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

In the hopes of provoking a response, I'll restate this issue as an 
assertion:

Every optional operation that is defined by a custom capability MUST be 
defined as a request/response pair such that the request type (directly 
or indirectly) extends SpmlRequestType and the response type (directly 
or indirectly) extends SpmlResponseType.

Gary P Cole wrote:

> MUST optional operations be defined as request/response pairs that 
> extend SpmlRequestType and SpmlResponseType?  Or is this just "a good 
> idea"?
>
> What are the consequences if an operation is not defined in this way?  
> I don't think you can use SPML to invoke an operation that's not 
> defined as an SPML request/response pair.
>
> Gary P Cole wrote:
>
>> Gerry Woods wrote:
>>
>>> Not sure about the relationship between capability operations and 
>>> SpmlRequest/Response. As a SHOULD this seems a little meaningless.
>>>
>> This is probably a good issue for the list.  I thought about this, 
>> and saying SHOULD was as far as I was prepared to go without group 
>> buy-in.  It seems to me that optional operations should be defined as 
>> request/response pairs that extend SpmlRequest and SpmlResponse, but 
>> I don't think we'd ever discussed this.  AFAIK, nothing precludes an 
>> optional operation being defined "out-of-band"....
>>
>>> Would it be better to outline the restrictions that apply if the 
>>> operations do not extend the core SPML operations? For example, for 
>>> operations to be sent in batch mode they must be derived from the 
>>> BatchableRequestType.
>>>
>> We could do this.  What are the consequences of a request does not 
>> derive from SpmlRequest type, or of a response that does not derive 
>> from SpmlResponseType?
>
>
>
>
>
> 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. 
>
>