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
