[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: custom operations.
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]