Hello All,

 

Once again I am emailing everyone what I just posted on the Wiki regarding some issues with the Interop documentation.  I deleted the issues I posted previously that do not apply to the current documentation. 

 

Also, I wanted to bring an issue to everyone's attention:

 There is a potential race condition brought on by the fact that the ByteIOInterop factory port type's DeleteResource operation is defined as a one-way message. 

 

-Karolina

 

 

 

Wiki Update:

ByteIO Interoperability Testing Scenarios Document Issues and Corrections

This section lists issues in v.12 of the ByteIO Interoperability Testing Scenarios document and presents corrections. The issues are listed in the order that they appear in the document and reference the specific sections/pages they refer to.

Incorrect Blocks-per-Byte in SOAP Example

(4.2) rbyteio:read operation (i)

The non-normative example of the SOAP elements in the body of the request message does not match the specifications of test 4.2. The required bytes-per-block is 12 not 6. The SOAP body of the requet message should be as follows: 

<rbyteio:read>
    <rbyteio:start-offset> 20 </rbyteio:start-offset>
    <rbyteio:bytes-per-block> 6 </rbyteio:bytes-per-block>
    <rbyteio:num-blocks> 1 </rbyteio:num-blocks>
    <rbyteio:stride> 0 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple"/>
</rbyteio:read>

Incorrect Write Value of Transfer-Information

(4.5) rbyteio:write operation (i) (5.3.1) sbyteio:seekWrite operation'

"KysrKysr" is the value that corresponds to writing a block of bytes equivalent to "++++++". This value is incorrectly given as "KysrKys=" in Section 4.5 and 5.3.1. The corrected SOAP request messages follow: 

<rbyteio:write>
    <rbyteio:start-offset> 20 </rbyteio:start-offset>
    <rbyteio:bytes-per-block> 6 </rbyteio:bytes-per-block>
    <rbyteio:stride> 0 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKysr </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:write>
<sbyteio:seekWrite>
    <sbyteio:offset> 20 </sbyteio:offset>
    <sbyteio:seek-origin>
        http://schemas.ggf.org/byteio/2005/10/streamable-access/seek-origins/beginning
    </sbyteio:seek-origin>
    <sbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKys= </byteio:data> 
    </sbyteio:transfer-information>
</sbyteio:seekWrite>

Wrong Treatment of Transfer-Information-Type XML element throughout Document

The Interoperability Testing Specification repeatedly and consistently uses wrong "transfer-information-type" XML elements in both sample XML fragments, and in its interoperability requirements.

For example, the document gives as sample SOAP fragment: 

<rbyteio:readResponse>
    <rbyteio:transfer-information transfer-mechanism= ”http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple”> 
        MTExMjEzMTQxNTE2
    </rbyteio:transfer-information>
</rbyteio:readResponse>

but it MUST read: 

<rbyteio:readResponse>
    <rbyteio:transfer-information transfer-mechanism=”http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple”> 
        <byteio:data>MTExMjEzMTQxNTE2</byteio:data>
    </rbyteio:transfer-information>
</rbyteio:readResponse>

This mistake is spread all over the document.

Per Appendix C of the ByteIO Recomendation Document, a <byteio:data> tag should surround data being passed. This applies to response messages of read operations and request messages of write operations. (Request messages of read operations and response messages of write operations should not contain data.)

The corrected SOAP body messages of the affected tests are listed below: 

<rbyteio:readResponse>
    <rbyteio:transfer-information transfer-mechanism="http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple"> 
        <byteio:data> MTExMjEzMTQxNTE2 </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:readResponse>
<rbyteio:readResponse>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> MDIwNDA2MDgxMA==  </byteio:data> 
    </rbyteio:transfer-information>
</rbyteio:readResponse>
<rbyteio:readResponse>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> MDEwMjAzMDQwNTA2MDQwNTA2MDcwODA5 </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:readResponse>
<rbyteio:write>
    <rbyteio:start-offset> 20 </rbyteio:start-offset>
    <rbyteio:bytes-per-block> 6 </rbyteio:bytes-per-block>
    <rbyteio:stride> 0 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKysr </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:write> 
<rbyteio:write>
    <rbyteio:start-offset> 22 </rbyteio:start-offset>
    <rbyteio:bytes-per-block> 2 </rbyteio:bytes-per-block>
    <rbyteio:stride> 4 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
       <byteio:data>  KysrKysrKysrKw== </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:write> 
<rbyteio:write>
    <rbyteio:start-offset> 0 </rbyteio:start-offset>
    <rbyteio:bytes-per-block> 6 </rbyteio:bytes-per-block>
    <rbyteio:stride> 3 </rbyteio:stride>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> Pz8/Pz8/KysrKysr </byteio:data> 
    </rbyteio:transfer-information>
</rbyteio:write> 
<rbyteio:append>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKysr </byteio:data> 
    </rbyteio:transfer-information>
</rbyteio:append> 
<rbyteio:truncAppend>
    <rbyteio:offset> 30 </rbyteio:offset>
    <rbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple">
        <byteio:data> KysrKysr </byteio:data>
    </rbyteio:transfer-information>
</rbyteio:truncAppend>

} 

<sbyteio:seekReadResponse>
    <sbyteio:transfer-information transfer-mechanism= "http://schemas.ggf.org/byteio/2005/10/transfer-mechanisms/simple"> 
        <byteio:data> MTExMjEzMTQxNTE2 </byteio:data>
    </sbyteio:transfer-information>
</sbyteio:seekReadResponse>

Discussion

This section lists issues that need to be discussed to resolve ambiguity for the Interoperability Fiesta.

ByteIO Interop Port Type, DeleteResource, and Race Conditions

Per Appendix A of the ByteIO Interoperability Testing Scenarios, the ByteIOInterop::PortType defines the DeleteResource operation as a one-way message. This results in a race condition if a resource is deleted and then tested for successful deletion.