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

[Michael Kass <michael.kass@nist.gov>]

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.

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

    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 ).

  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>

Mike


At 08:38 PM 4/8/2002 -0700, Matthew MacKenzie wrote:
>Michael,
>
>Perhaps a script defined in plain text or xml that allowed a message to be 
>constructed, and features added to it declaratively would work.
>XPath would be more difficult to implement, as most of us only use XPath 
>for selection, and not construction, of xml content.
>
><new_msg id="nm1">
>         <header>
>                 <To><PartyId type="uri">http://company/msh</PartyId></To>
>                 <CPAId>blah</CPAId>
>         </header>
>         <attachment index="1" content-id="cid:blah"; 
> content-type="text/plain">
>hello, world
>         </attachment>
>...
></new_msg>
>
>The ebXML SOAP extensions schema could be used inside of this syntax 
>allowing you to specify everything in the message.  Putting on my vendor 
>hat, I think this would be relatively easy to provide an API driver for.
>
>
>On Tuesday, April 9, 2002, at 08:04  PM, Michael Kass wrote:
>
>>
>>To all,
>>
>>    I have been looking into possible choices for declarativey driving an 
>> ebXML MS testing API using XML.  My primary choice ( a logical one ) is 
>> to use the XML syntax defined in the ebXML schema, as it would allow the 
>> construction of all of the various message objects and setting the 
>> values of their attributes using their methods.  However, our "testing 
>> API" will no doubt need to not only "create" portions of a message , but 
>> "modify/replace" attribute values.  In addition, this may require 
>> "modifying the nth instance of a particular object in a message".
>>    I have looked for other possible XML syntaxes that might do the job, 
>> but have not found anything suitable. JMS appears to be too simple to 
>> handle the complexities of ebXML messages, as it only allows simple 
>> property setting, and nothing as complex as ebXML message content structure.
>>
>>  XPath is a great choice for using as a declarative syntax to test 
>> RECEIVED message content, or parsing a "testing trace", as it is 
>> syntactically succint, exact and easy to code.
>>
>>    But I do not see a declarative way to "tweak" an outgoing message 
>> through the testing API using ebXML MS syntax.... Perhaps by creating a 
>> modified schema to incorporate new elements/attributes that could 
>> provide "hints" to the testing API how to "modify" a message component?
>>     Any thoughts on this?
>>
>>Mike
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>--
>Matthew MacKenzie
>XML Global R&D
>PGP Key available upon request.
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>