W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2007

Re: Test update for MTOM/XOP/RRSHB

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Fri, 27 Jul 2007 07:13:12 -0400
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>, xml-dist-app-request@w3.org
Message-ID: <OFA5A936CF.96A2F360-ON85257325.003D3D3C-85257325.003D796B@us.ibm.com>
Thanks, Anish!

Yves,

Could you update the link from the implementation page [1] to point to the 
updated tests in Anish's note [2]?

[1] http://www.w3.org/2000/xp/Group/4/08/implementation.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2007Jul/0007.html

Thanks,

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986

xml-dist-app-request@w3.org wrote on 07/25/2007 07:59:58 PM:

> 
> This is a follow-up to my earlier email at [1].
> 
> I. Preface:
> 
> The email at [1] provides a delta to the tests at [2] for the xmime NS 
> fixup. The tests at [2] point to two emails [3] and [4]. [3] describes 
> test which are labeled 1a, 1b, 2a, 2b, 3a, 4, 5, 6 and 7. [4] describes 
> tests which are labled RRSHB1, RRSHB2, RRSHB3 and RRSHB.
> 
> This email merges the delta at [1] with the content of emails at [3] and 

> [4] so as to provide a single place to look for the updated tests. The 
> merged tests are listed below.
> 
> II. Updated Tests 1-7 :
> 
> -------------------------------------------------------------------
> 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/2005/05/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/qDql6Rmnu5W2
> 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/qDql6Rmnu5W2
> 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/2005/05/xmlmime'
>            xmime:contentType='image/jpeg'
> >IK44HhIvWXSX2NIeoJyjiUfI5+ynntOwSmsYyf29ks0NuVSwaHWQedq6kn/qDql6Rmnu5W2
> 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.
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2004Jul/0025.html
> -------------------------------------------------------------------
> 
> 
> 
> III. Updated RRSHB Tests
> 
> -------------------------------------------------------------------
> RRSHB Implementation/Interop tests for the CR phase :-
> 
> The tests below cover the following:
> * basic RRSHB testing
> * testing with multiple RRSH blocks that represent the same resource but
>    have different meta-data
> * RRSHB testing in conjunction with xmlmime:contentType attribute
> * RRSHB testing in conjunction with MTOM
> 
> 
> The schema for the elements and attributes used in the tests is as
> follows (reuses the 'Data' element from MTOM tests with different
> namespace):
> 
> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
>             targetNamespace='http://example.org/rrshb/test'
>             xmlns:x='http://example.org/rrshb/test' >
> 
>     <xs:import namespace='http://www.w3.org/2005/05/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='GetResourceRepresentation' >
>      <xs:complexType>
>       <xs:attribute name='resource' type='xs:anyURI' use='required' />
>      </xs:complexType>
>     </xs:element>
> 
>     <xs:element name='ResourceRepresentation' >
>      <xs:complexType>
>       <xs:sequence>
>        <xs:element ref='x:Data' minOccurs='1' maxOccurs='unbounded' />
>       </xs:sequence>
>       <xs:attribute name='resource' type='xs:anyURI' use='required' />
>      </xs:complexType>
>     </xs:element>
> 
> </xs:schema>
> 
> 
> 
> Test 1: Basic RRSHB testing
> 
> The tests consists of -
> 
> Request message: node A (client) sends a message to node B (server) with
> Resource Representation Header block(s) for the resource identified by
> "http://example.org/rrshb/test/data". SOAP Body consists of the element
> {http://example.org/rrshb/test}GetResourceRepresentation. If multiple
> RRSHB are present in the message they must have different values for the
> attribute "xmlmime:contentType".
> 
> example request message:
> 
> <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
>                 xmlns:rep='http://www.w3.org/2004/08/representation'
>                 xmlns:xmlmime='http://www.w3.org/2005/05/xmlmime'>
>     <soap:Header>
>       <rep:Representation resource='http://example.org/rrshb/test/data'>
>         <rep:Data xmlmime:contentType='image/png'>...</rep:Data>
>       </rep:Representation>
>       <rep:Representation resource='http://example.org/rrshb/test/data'>
>         <rep:Data xmlmime:contentType='image/jpeg'>...</rep:Data>
>       </rep:Representation>
>     </soap:Header>
>     <soap:Body>
>       <x:GetResourceRepresentation
>           xmlns:x='http://example.org/rrshb/test'
>           resource='http://example.org/rrshb/test/data' />
>       </x:GetResourceRepresentation>
>     </soap:Body>
> </soap:Envelope>
> 
> Response message: node B (server) responds to node A (client) by 
> including all the representations of the resource identified by 
> "http://example.org/rrshb/test/data", in the SOAP Body as the content of 

> the element {http://example.org/rrshb/test}ResourceRepresentation.
> 
> example message:
> 
> <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
>                 xmlns:rep='http://www.w3.org/2004/08/representation'
>                 xmlns:xmlmime='http://www.w3.org/2005/05/xmlmime'>
>     <soap:Body>
>       <x:ResourceRepresentation xmlns:x='http://example.org/rrshb/test' 
> resource='http://example.org/rrshb/test/data'/>
>         <x:Data xmlmime:contentType='image/png'>...</x:Data>
>         <x:Data xmlmime:contentType='image/jpeg'>...</x:Data>
>     </soap:Body>
> </soap:Envelope>
> 
> 
> Test 2: RRSHB testing with MTOM
> 
> Same as test 1 but the request message uses MTOM to optimize all the 
> RRSHB (by using xop:Include) and the response message uses MTOM to
> optimize all the x:Data elements (by using xop:Include)
> 
> 
> Test 3: RRSHB testing with "reinsert"
> 
> In this test the SOAP path consists of node A --> node B --> node A. 
> Node B acts as a forwarding intermediary. The message sent from node A 
> to node B is same as in test 1, but all the RRSHB headers have the 
> "reinsert" and "relay" attribute with the value of "true". The message 
> sent from node B to node A is same as in test 1, but all the RRSHB 
> headers included in the request message are also present in the response
> message.
> 
> 
> The tests do not cover section "4.3.3 Extension example: HTTP resolver
> extension", as this was considered to be an example and non-normative.
> -------------------------------------------------------------------
> 
> 
> -Anish
> --
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2007Jul/0003.html
> [2] http://www.w3.org/2000/xp/Group/4/08/implementation.html
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2004Aug/0013.html
> [4] http://lists.w3.org/Archives/Public/xml-dist-app/2004Sep/0013.html
> 
Received on Friday, 27 July 2007 11:14:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:24 GMT