OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Kass 10/24/2002 [ebxml-iic]: Abstract Test Cases


Thanks.  Only comment on req45, <ValidateMessage/> should work.

Monica

-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Saturday, October 26, 2002 11:20 PM
To: Monica Martin; Jacques Durand; ebxml-iic@lists.oasis-open.org
Subject: Re: Kass 10/24/2002 [ebxml-iic]: Abstract Test Cases


Monica,

   Thanks for taking a look at these.  See my comments below.

Cheers,
Mike

At 08:53 AM 10/25/2002 -0700, Monica Martin wrote:
>Michael,
>Grand job!
>
>On req36, the requirement is to verify ConversationId is always
present,
>yet you test for verification a ConversationID is not present
>(count()=0).


[MIKE] - Fixed.  Changed syntax to reflect a check for presence.

>On req45, is the end of the abstract 'pseudo code' correct 'and /'?

[MIKE] - You are right.  Actually, this will be a little difficult to 
test.  I could add a
<ValidateMessage/> operation, along with existing <GetMessage/>
operation.
Problem is, validation will be done for entire message, and if it fails,

there's no way that
I would know for sure if it was because an invalid <TimeToLive/> value.
Validation could fail because of another part of the message is 
invalid.  Checking
the validity of discreet parts of a message would be difficult, I
believe.
Comments?


>On req74, wouldn't we be repeating steps until we hit the max retry
>count as a loop? How is that represented or is it implicit in the
>abstract?
>


[MIKE] - We should not be repeating any steps. What would happen is, the
TestDriver "persistent store", will collect incoming messages since the
last
<TestStep>. It will cease collection once the "timeout" period ( set up
in
the <ConfigurationGroup/> or <ConfigurationItem/> ) is reached, then
  filter ( correlate ) them based upon $RefToMessageId, $CPAId  and 
$ConversationId.
Then, the <ConformanceRequirement/> XPath filter examines the virtual 
"NodeSet" ( a collection of
<MIME:Message/> elements and their children ) to determine the count 
of  <MIME:Message/>s
actually found that contain an <AckRequested> element.  They should
equal 
the maximum number
of retries specified in the CPA ( and corresponding CONFIG data 
).  Unfortunately, my XPath syntax
was off by one bracket.  It should read:

//MIME:Message[MIME:Container[0]/SOAP:Envelope/SOAP:Header/eb:MessageHea
der/eb:AckRequested][count() 
= $MaxRetries]





>Thanks, Michael.
>Monica




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC