[provision] SPML Conformance Matrix

[Darran Rolls <Darran.Rolls@waveset.com>]

In advance of official minutes from this week’s PSTC f2f, I wanted to briefly re-visit our last item of business.  Those of you who attended, will not doubt recall the active debate on conformance that resulted in the below text for the conformance section of the specification.  Having read through this again, I am now of the opinion that it does not make sense to have an “optional must implement one of” policy for the RA and PS that excludes SearchRequest.  Consensus was that searchRequest should be optional for all parties, so if I optionally choose to implement that, why would it not be my “one in the bag” so to speak and count towards the compliance of my RA/PST?  The same should therefore apply to ExtendedRequest.  In essence we are saying “look, if you implement an RA or PSP you have to support at least one request types and do this in a basic BatchRequest envelope, otherwise what are you doing…”. 

 

So, I would like you to consider the second table/section below as a minor amendment (which does makes the table look much nicer ;-) and propose we vote on this on Monday con-call.

10.Conformance tables (as defined in last order of business)

This section lists those portions of the specification that MUST be included in an implementation of an SPML client or an SPML service that claims to conform with SPML v1.0.

 

Note: "M" means mandatory to implement.  "O" means optional to implement. “O* means optional to implement but must implement  one of either AddRequest, ModifyRequest or DeleteRequest .  “NA” means does not apply.

 

The implementation MUST support ALL those schema elements that are marked “M” and MUST support one of either AddRequest, ModifyRequest or DeleteRequests in the columns marked “O*”

 

 

Element name	RA	PSP Server	PSP Client	PST
spml:AddRequest	O*	M	O*	O*
spml:ModifyRequest	O*	M	O*	O*
spml:DeleteRequest	O*	M	O*	O*
spml:SearchRequest	O	O	O	O
spml:ExtendedRequest	O	O	O	O
Support for the synchronous SPML operations model (requires support for spml:BatchRequest)	M	M	M	M
Support for the asynchronous SPML operations model (requires support for spml:BatchStatus and spml:BatchCancel)	O	O	O	O
Provide an spml:Schema compliant definition of all published services	NA	M	NA	M
Support the spml:SchemaRequest operation for all published service	O	O	O	O

 

 

 

11.Conformance tables (New DR slight amendment ;-)

This section lists those portions of the specification that MUST be included in an implementation of an SPML client or an SPML service that claims to conform with SPML v1.0.

 

Note: "M" means mandatory to implement.  "O" means optional to implement. “O* means optional to implement but must implement one of either AddRequest, ModifyRequest, DeleteRequest, SearchRequest or ExtendedRequest.  “NA” means does not apply.

 

The implementation MUST support ALL those schema elements that are marked “M” and MUST support one of either AddRequest AddRequest, ModifyRequest, DeleteRequest, SearchRequest or ExtendedRequest in the columns marked “O*”

 

 

Element name	RA	PSP Server	PSP Client	PST
spml:AddRequest	O*	M	O*	O*
spml:ModifyRequest	O*	M	O*	O*
spml:DeleteRequest	O*	M	O*	O*
spml:SearchRequest	O*	O*	O*	O*
spml:ExtendedRequest	O*	O*	O*	O*
Support for the synchronous SPML operations model (requires support for spml:BatchRequest)	M	M	M	M
Support for the asynchronous SPML operations model (requires support for spml:BatchStatus and spml:BatchCancel)	O	O	O	O
Provide an spml:Schema compliant definition of all published services	NA	M	NA	M
Support the spml:SchemaRequest operation for all published service	O	O	O	O

 

 

--------------------------------------------------------

Darran Rolls                      http://www.waveset.com

Waveset Technologies Inc          drolls@waveset.com

(512) 657 8360                   

--------------------------------------------------------