Re: [regrep] 7/29/2003: Conformance Efforts and ebXML IIC

["Michael Kass" <michael.kass@nist.gov>]

Title: ebXML Registry 2.5 Specification Assertion List

To all,

 

  Sorry about the mixup.  I sent the original test requirements file.  Here is the updated one.

 

 

Mike

 

 

Title: ebXML Registry 2.5 Specification Assertion List

OASIS ebXML Registry 2.5
Specification Assertions

ID	Spec Ref	Section Title	Requirement	Precondition	Assertion
EBRR:EBRS:1	6.6.2	QueryManager HTP Interface	REQ	For any registry implementation	The HTTP Interface to QueryManagermust be supported
EBRR:EBRS:2	7.3.3	Universally Unique ID Generation	REQ	If the id conforms format of a URN that specifies a DCE 128 bit UUID.	The registry must assign a client specified id to an object submitted by the client
EBRR:EBRS:3	7.3.3	Universally Unique ID Generation	REQ	If the client does not supply an id for a submitted object	The registry must generate a universally unique id.
EBRR:EBRS:4	7.3.5	Audit Trail	REQ	For each RegistryObject created via a SubmitObjectsRequest.	The RS must create AuditableEvent objects with eventType Created
EBRR:EBRS:5	7.4.2	Audit Trail	REQ	For each RegistryObject updated via an UpdateObjectsRequest.	The RS must create AuditableEvents object with eventType Updated

Required Modifications:

Below is a list of changes made to Farrukh's original set of conformance test requirements for ebRS.   I've itemized them as:

1) Add a "main" test requirement used to collect or group individual sub-requirements.  Just provide an ID, Spec Ref and Section Title,
then create a series of "functional requirements" underneath it. This creates a "modular" grouping, useful for profile testing, and also permits specifying
a "main" requirement to be tested in the framework, without the need to specify all of its "child" functional requirements.
2) Change Section Title for functional requirements to a "single word descriptor" that is meaningful to that particular requirement. This promotes easy readability without
having to visually scan each assertion to determine the meaning of the functional requirement.
3) State the the requirement level is (REQ = required, REC = recommended, OPT = optional)  This is useful when generating the test report.
4) Provide a "precondition" ( or preconditions )  for every test requirement.  Depending on the test requirement, preconditions can be very explicit, or general.
Avoid lumping preconditions into the actual test assertion.
5)When possible, "break apart" test assertions into separate "atomic" sub-assertions, so that testing can be discreet.

ID	Spec Ref	Section Title	Requirement Level	Precondition(s)	Assertion
EBRR:RS:1	6.6	HTTPBinding
EBRR:EBRS:1:1	6.6.2	QueryManagerHTTP Interface	REQ	For any registry implementation	The HTTP Interface to QueryManagermust be supported
EBRR:RS:2	7.3	SubmitObjectsProtocol
EBRR:EBRS:2:1	7.3.3	ClientSpecifiedID	REQ	If the id conforms format of a URN that specifies a DCE 128 bit UUID.	The registry must assign a client specified id to an object submitted by the client
EBRR:EBRS:2:2	7.3.3	RegistryGeneratedID	REQ	If the client does not supply an id for a submitted object	The registry must generate a universally unique id.
EBRR:EBRS:2:3	7.3.5	CreatedAuditableEvent	REQ	For each RegistryObject created via a SubmitObjectsRequest.	The RS must create AuditableEvent objects with eventType Created
EBRR:EBRS:2:4	7.4.2	UpdatedAuditableEvent	REQ	For each RegistryObject updated via an UpdateObjectsRequest.	The RS must create AuditableEvents object with eventType Updated