[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] 7/29/2003: Conformance Efforts and ebXML IIC
Farrukh Najmi wrote: > Monica Martin wrote: > >> As requested in last week's call, I did talk to the ebXML IIC about >> your interest in conformance. They indicated if our team could >> provide a draft/strawman list of abstract test requirements (or >> objectives), that would be great. They could then formulate some >> examples as specified in the test framework and make this an >> interactive exercise. > > > Recall from last meeting that I had suggetsed that we compile a set of > spec assertions and give that as a starting point for IIC to get > engaged. I feel that the " abstract test requirements (or objectives)" > are likley to mean the same thing. > > I had an AI from last meeting to send an example of what I mean by > test assertion list. Please find attached file with a sample of what > such a list might look like. > > Monica, could you please get coments from IIC whether this is > representative of what they need from us? mm1: I would be happy to do so. Two comments before I do forward: 1. Do I wait for team inputs first? 2. On the assertions, the test framework has the notion of conditions and assertions to meet test requirements (which may or may not be 1-1 to a specification requirement). I'll give you an example based on your assertions: * Condition: For a submitted registry object, if the client does not supply an id * Assertion: The registry must generate a universally unique id for the submitted object. If you look to the reference I gave you, this gives greater detail and explains this. Thanks. > > Team members please share your thoughts. Thanks. > > > > ------------------------------------------------------------------------ > > > OASIS ebXML Registry 2.5 > Specification Assertions > > > ID Section Section Title > Description > EBRR:EBRS:1 6.6.2 QueryManager HTP Interface > > > The HTTP Interface to QueryManager /must/ be supported by all registries. > > EBRR:EBRS:2 7.3.3 Universally Unique ID Generation > > > The registry must assign a client specified id to an object submitted > by the client if the id conforms format of a URN that specifies a DCE > 128 bit UUID. > > EBRR:EBRS:3 7.3.3 Universally Unique ID Generation > > > If the client does not supply an id for a submitted object then the > registry must generate a universally unique id. > > EBRR:EBRS:4 7.3.5 > Audit Trail > > > The RS must create AuditableEvent objects with eventType /Created/ for > each RegistryObject created via a SubmitObjectsRequest. > > EBRR:EBRS:5 7.4.2 > Audit Trail > > > The RS must create AuditableEvents object with eventType /Updated/ for > each RegistryObject updated via an UpdateObjectsRequest. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]