RE: MTOM CR Test Scenarios

Bob,

I tried to reply to your earlier private mail to me, but I now see it
bounded. You are of course correct. My mistake. The correct name is
"EchoTest" not "Wrapper" although to be honest the way I've got my
end-point set up, it wouldn't actually matter. Provided the Data
elements have base64 or xop:Include children things will work.

So, the schema is correct. The message examples should say "EchoTest"
whereever you see "Wrapper"

Cheers

Gudge

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Bob Cunnings
> Sent: 20 August 2004 16:54
> To: [email protected]
> Subject: RE: MTOM CR Test Scenarios
> 
> 
> Hello,
> 
> There is a conflict between the schema and the examples 
> below, is it safe to
> assume the wrapper element name will be "EchoTest"?
> 
> Thanks,
> 
> RC
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On
> Behalf Of Martin Gudgin
> Sent: Wednesday, August 18, 2004 8:41 AM
> To: [email protected]
> Subject: MTOM CR Test Scenarios
> 
> 
> 
> Here are a set of test scenarios for MTOM. We will use these tests
> during the Candidate Recommendation phase. As noted previously[1] the
> tests will take the form of an echo test. These come in two forms;
> 
> 1.	A client implementation sends an MTOM message and the server
> implementation returns the corresponding XML 1.0 message
> 2.	A client implementation sends an XML 1.0 message and the server
> implementation returns the corresponding MTOM message
> 
> In all cases elements with the namespace name
> "http://example.org/mtom/data" and a local name of "Data" will be of a
> type derived from xs:base64Binary. Such elements will have a 
> xop:Include
> element child in the MTOM messages and base64 text as children in the
> XML case. A schema for the elements used is as follows:
> 
> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
>            targetNamespace='http://example.org/mtom/data'
>            xmlns:x='http://example.org/mtom/data' >
> 
>   <xs:import namespace='http://www.w3.org/2004/06/xmlmime' />
> 
>   <xs:element name='Data' >
>    <xs:complexType>
>     <xs:simpleContent>
>      <xs:extension base='xs:base64Binary' >
>       <xs:attribute ref='xmime:contentType' />
>      </xs:extension>
>     </xs:simpleContent>
>    </xs:complexType>
>   </xs:element>
> 
>   <xs:element name='EchoTest' >
>    <xs:complexType>
>     <xs:sequence>
>      <xs:element ref='x:Data' minOccurs='1' maxOccurs='unbounded' />
>     </xs:sequence>
>    </xs:complexType>
>   </xs:element>
> 
> </xs:schema>
> 
> I've listed the various tests below, with example XML messages. Please
> note that in all cases, despite the vagaries of mailers, the x:Data
> element do not have any whitespace characters as children. 
> The amount of
> base64 text sent ( as either text or optimized binary ) is 
> unimportant.
> However, to avoid running into memory limitations during testing, it
> would be best to send smaller rather than larger binary parts. If
> someone wants to propose an upper limit, let me know. I think 
> most of my
> own test messages come in below 512Kb.
> 
> 
> 
> Test 1: Single binary part. Limit the number of x:Data elements in the
> message to 1. An example XML version of the message will be 
> as follows:
> 
> <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope' >
>  <soap:Body>
>   <x:Data xmlns:x='http://example.org/mtom/data'
> >IK44HhIvWXSX2NIeoJyjiUfI5+ynntOwSmsYyf29ks0NuVSwaHWQedq6kn/qD
> ql6Rmnu5W2
> a44HaiNSnF5B22g==</x:Data>
>  </soap:Body>
> </soap:Envelope>
> 
> Test 1a: Send XML, get back MTOM
> Test 1b: Send MTOM, get back XML
> 
> 
> 
> Test 2: Multiple binary parts. Allow any number of x:Data elements in
> the message. An example XML version of the message will be as follows:
> 
> <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope' >
>  <soap:Body>
>   <x:Wrapper>
>     <x:Data xmlns:x='http://example.org/mtom/data'
> >IK44HhIvWXSX2NIeoJyjiUfI5+ynntOwSmsYyf29ks0NuVSwaHWQedq6kn/qD
> ql6Rmnu5W2
> a44HaiNSnF5B22g==</x:Data>
>     <x:Data xmlns:x='http://example.org/mtom/data'
> >3T4iLkRXu+K/QNlhEJqaIt8uE
> ZHpS7kRdXBLNhiet+xYAUyTiNPFGBuc8EPti+vc9Fe3mMNxAlGFELkUDEXKA==
> </x:Data>
>     <x:Data xmlns:x='http://example.org/mtom/data'
> >g0txZNBHOf5ho5pv7NsXLm5m1
> 3dmG5MC2GCUW2bjRar55raIMPUvkiYFpsJ/dwbKtgtZUb07DWi3b4tvst6Xfg=
> =</x:Data>
>   </x:Wrapper>
>  </soap:Body>
> </soap:Envelope>
> 
> Test 2a: Send XML, get back MTOM
> Test 2b: Send MTOM, get back XML
> 
> 
> 
> Test 3: Testing xmime:contentType attribute and MIME content-type
> header. The xmime:contentType header is specified on x:Data 
> elements in
> an XML message. An MTOM message is returned with the MIME content-type
> of the binary parts set to the appropriate value. An example 
> XML version
> of the message will be as follows:
> 
> <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope' >
>  <soap:Body>
>   <x:Data xmlns:x='http://example.org/mtom/data'
>           xmlns:xmime='http://www.w3.org/2004/06/xmlmime'
>           xmime:contentType='image/jpeg'
> >IK44HhIvWXSX2NIeoJyjiUfI5+ynntOwSmsYyf29ks0NuVSwaHWQedq6kn/qD
> ql6Rmnu5W2
> a44HaiNSnF5B22g==</x:Data>
>  </soap:Body>
> </soap:Envelope>
> 
> The corresponding MTOM message would set the content-type 
> header of the
> binary part for the x:Data element to 'image/jpeg'
> 
> Test 3a: Send XML, get back MTOM
> Test 3b: Not applicable.
> 
> 
> 
> Test 4: Failure test: Missing MIME part. Send an MTOM message with a
> xop:Include element that references a non-existent MIME part. A SOAP
> fault should be returned indicating that the message was in error.
> 
> Test 5: Failure test: Use of content-location. Send an MTOM 
> message that
> references one or more MIME parts by content-location (rather than
> content-id). A SOAP fault should be returned indicating that 
> the message
> was in error.
> 
> Test 6: Failure test: Use of startinfo parameter that does NOT specify
> application/soap+xml. Send an MTOM message that uses a startinfo of
> image/jpeg. A SOAP fault should be returned indicating that 
> the message
> was in error.
> 
> Test 7: Failure test: Use of type parameter on the root part that does
> NOT specify application/soap+xml. Send an MTOM message that 
> uses a type
> parameter of image/jpeg for the root part. A SOAP fault should be
> returned indicating that the message was in error.
> 
> Regards
> 
> Gudge
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Jul/0025.html
> 
> 
>