RE: [ebxml-iic] ebXML IIC 10/14/2002: Comments on Abstract Test C ases

Title: RE: [ebxml-iic] ebXML IIC 10/14/2002: Comments on Abstract Test Cases

Obviously quite some support for "GetPayload" test operation...

So I rally here.

On another note, I just want to publicized on the list another 

fix that Mike and I agreed on yesterday, to make sure none has problem with that.

Not much a visible change in test material, rather some more precise interpretation:  

- we will use exactly the same type of "message expression" in both putMessage and getMessage:

(so same "=" operator, as in real XPath - with only one meaning: equality op rel), 

in order to remove any confusion.

Both expressions will be "logical" expressions (no more assignments):

- The meaning in putMessage is:

"you use the message header XYZ - as specified in putMessage argt - and update it

so that the following XPath-based expression is TRUE. (Then you send the message)"

- The meaning in getMessage is:

"select the next message(s) before timeout, the envelope/header of which satisfies 

the following XPath-based expression"

Let me know if any problem with that.

Regards,

jacques

-----Original Message-----

From: Monica Martin [mailto:]

Sent: Monday, October 14, 2002 10:19 AM

To: 

Cc: Monica Martin

Subject: [ebxml-iic] ebXML IIC 10/14/2002: Comments on Abstract Test

Cases

One comment in response to Jacques and Michael Kass:

/Payload  <Jacques> we need to explain how to interpret such expression

, or, could we assume that the GetPayload (or even GetMessage )

operation, is automatically casting the MIME envelope into an XML format

so that we can then use Xpath conditions on it? If we assume that

GetMessage does this implicitly, we would not even need "GetPayload"

above: we can test that there is a MIME part "Content-ID child" with

value <cid:payload_1>., in our conformance condition. Opinion?   

<MIKE>

1) I agree that documentation is needed to explain all of the abstract

test terminology. 

2) I can do what you are asking here( "downcast" MIME

headers ), it just means that "containership" only exists at the MIME

Message level, and message components are expressed in XPath.  We can do

that, it just means there is no "real-world" relationship between the

syntax expressed here and actual test suite XML schema.  Of course, that

is what an "abstract test suite" is  :-) 

 3) I would like to keep

<GetPayload>. I think that it is very helpful in giving someone an idea

what the XPath expression really means.    

[mm1: I would agree to keep

so we provide as much flexibility as possible (given our assumptions may

change or the assumptions will change with an implementation of the test

cases).]  

Regarding the meaning of this particular operation: This XPath

expression actually evaluates the contents of the returned payload to to

verify that a single XML clement called  <Payload> is present.   We will

be doing a lot of payload content verification with Registry and

vertical application conformance testing.       

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

To subscribe or unsubscribe from this elist use the subscription

manager: <http://lists.oasis-open.org/ob/adm.pl>