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] Re: draft_protocol


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?





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