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: [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:mmartin@certivo.net]
Sent: Monday, October 14, 2002 10:19 AM
To: ebxml-iic@lists.oasis-open.org
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>



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


Powered by eList eXpress LLC