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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic-msg message

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

Subject: Re: [ebxml-iic-msg] A declarative syntax for driving ebXML a testingebXML MS API

On Tuesday, April 9, 2002, at 09:34  PM, Michael Kass wrote:

> Matt,
>    I agree with your approach.  Actually, when you look at the ebXML MS 
> schema, it is fairly "shallow", and coming up with a schema 
> modification to incorporate "add", "modify" or "delete" portions of a 
> message could be done.  The goal would be to do it as elegantly as 
> possible without cluttering up the schema too much.  I would envision 
> that one would want to "tweak" portions of a message as opposed to 
> wholesale message creation, for testing purposes, and that the amount 
> of declarative coding would not be that great for incremental test 
> steps.

I would cringe at this approach for anything that involves deep nesting, 
so I suspect this approach is fine for Messaging and Registry, maybe 
BPSS.  CPPA will be more challenging, but there is nothing we can do to 
make it easier with the level of specification that takes place in the 
CPPA schema.

> The assumption would be that the testing API has access to all portions 
> of the constructed message prior to its sending.

My assumption is that the Vendor, or third party conformance suite 
implementor for a given product would use this message content 
specification to build a "driver" for the target API, so under this 
assumption, your assumption is well founded.  This does, however, raise 
more questions in my mind about how testing is to be instrumented in a 
manner that is consistent, and easily reproducible for NIST or others to 

Maybe we need to define a simple driver API that the vendor being tested 
would implement.

>    On the Testing side, this would provide complete control of 
> content.  On the Candidate side, I would think that this power would be 
> used very judiciously, since that is the implementation under test.
>    I will take a crack at a schema to do "add", "modify" and "delete".  
> ( I'm a little uncertain if "delete" would be used in testing... but 
> then again, creative testers might find it useful ).

I don't know about "modify", but "delete" statements would be useful 
especially when placed as the last directives, to ensure certain 
elements did not exist.

>  Thanks for the info.
>    By the way, wouldn't XPath be the tool of choice though for "trace 
> log testing"?  Since it is a "query" syntax... post-processing of the 
> testing trace would be a perfect use for this tool.  If the test trace 
> were all XML ( including MIME properties expressed as:
> <TestRequirement id="r1.1">
> <TestCase id="r1.1.1">
> <MessageHeader ContentId="foo" start="bar" type="text/xml" 
> boundary="myboundaryvalue"/>
> <BoundaryValue>myBoundaryValue</BoundaryValue>
> <SOAPEnvelope ContentId="bar" type="text/xml"/>
> <SOAP:Envelope xmlns:..........................
> </SOAP:Envelope>
> <BoundaryValue/>
> </TestCase>
> </TestRequirement>

Certainly.  The Messaging spec itself somewhat agrees with us on this as 
well...have you noticed the section which specifies the user of XPointer 
for error reporting?  You can dig the specref out of the requirements 
files with grep if you need to.  My advice is simply to be wary of 
document construction with XPath.  I've done it before in Perl a few 
years back, and it is a bit tricky to do right which might be a 
stumbling block for implementers.



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

Powered by eList eXpress LLC