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

Re: Test update for MTOM/XOP/RRSHB

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 25 Jul 2007 16:59:58 -0700
Message-ID: <46A7E3FE.9090605@oracle.com>
To: "Xml-Dist-App@W3. Org" <xml-dist-app@w3.org>

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 Thursday, 26 July 2007 00:02:37 GMT

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