Hi, I got some more stuff to discuss: WS-Addressing mandates the use of the wsa:Action information element. WS-Addressing also allows for explicit association or default association of a wsa:Action value. The default association generates a wsa:Action value derived automatically from the invoked operation on the port type. However, the explicit association is mandated to be specified in the portType rather in the binding. As ByteIO uses WS-Addressing, I think we are facing the following issues: - AFAIR RByteIO and SByteIO do not define explicit action values. - However, the non-normative SOAP Encoding examples indicate explicit values as the values given do not match the construction pattern for default association based wsa:Action values. - WSRF uses WS-Addressing, and explicitly defines wsa:Action values. WSRF does not give the wsa:Action value in its portTypes as it expects the user to create the portType according to the specification - RByteIO and SByteIO port types do not specify the wsa:Addressing wsa:Action attributes. Currently I see these issues jeopardizing the interop fiesta success, so I propose the following solution: - ByteIO defines explicit wsa:Action values or all its operations on the RByteIO and SByteIO operations. - Change the RByteIO and SByteIO portTypes to reflect those explicit wsa:Action values - Change the RByteIO and SByteIO portTypes to reflect the explicit wsa:Action values for the WSRF operations. - Change the interop binding WSDLs for SByteIO and RByteIO in the interop testing specification - Publish a new draft 12 of the interop testing specification that reflets all the proposed changes in this mail, plus the changes proposed on the Wiki (regarding WS-I violating namespace issues, and the missing ResourceUnknownFault issue). If you guys agree to that, I'll take the pen to make all the necessary changes. Any comments? Cheers, Michel Michel Drescher wrote:

Hi Karolina, all,

thanks for pointing these things out, good catch!

However, I think we are out of synch, mostly, I fear, it being y fault.

I have been browsing though old notes of ByteIO WG sessions and mailsw on the ML, and I discovered the following: - We once decided to drop WSRF message exchanges except for GetResourceProperty, as we are testing ByteIO, not WSRF - We decided to keep the WSRF GetResourceProperty test cases (sections 4.1 and 5.1) to check for a generally proper setup on the server side.

I actually have a draft 11 of the ByteIO Interop testing document that reflects all this; it somehow totally slipped my mind that I had to do some editorial stuff on the interop document. :(

Comments? Should I publish version 11, with or without the currently discovered issues?

Cheers, Michel

Karolina Sadrnowska wrote:

...

Hello All,

My name is Karolina Sarnowska. I am a part of Andrew Grimshaw’s group at the University of Virginia. I have been working with Mark Morgan on getting Genesis II ready for the Interoperability Fiesta. I wanted to email everyone what I just posted on the Wiki regarding some issues with the documentation.

-Karolina

/ByteIO Interoperability Testing Scenarios/ Document Issues and Corrections

This section lists issues in 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 section they refer to.

--------------------------------------------------------------------------------

Missing Tags in SOAP Body of Request Message

/(4.2) wsrf-rp:GetMultipleResourceProperties operation/

The non-normative example of the elements the ByteIO client adds to the SOAP body of the request message is missing the wsrf-rp:ResourceProperty tag. The SOAP body should instead contain the following:

wsrf-rp:GetMultipleResourceProperties

wsrf-rp:ResourceProperty rbyteio:Readable

wsrf-rp:ResourceProperty rbyteio:Writeable

wsrf-rp:ResourceProperty rbyteio:TransferMechanism

--------------------------------------------------------------------------------

Incorrect Resource Property Name and Possibly Incorrect Query

/(4.3) wsrf-rp:QueryResourceProperties operation/

An incorrect name for the Resource Property is used in the non-normative example of the elements the ByteIO client adds to the SOAP body of the request message. The Resource Property queried is called “ModificationTime” not “ModificationDate”. The SOAP body should instead contain the following:

wsrf-rp:QueryResourceProperties

http://www.w3.org/TR/1999/REC-xpath-19991116”>

/*/rbyteio:ModificationTime

It is also unclear whether this example contains the correct query. If the query does not need to include the namespace, then the query could be instead “/*/ModificationTime”.

--------------------------------------------------------------------------------

Missing Tag in SOAP Body of Response Message

/(4.3) wsrf-rp:QueryResourceProperties operation/

The non-normative example of the elements the ByteIO client adds to the SOAP body of the response message is missing the rbyteio:ModificationTime tag. The SOAP body should instead contain the following:

wsrf-rp:QueryResourcePropertiesResponse

rbyteio:~ModificationTime

2006-09-11T16:15:33+05:00

--------------------------------------------------------------------------------

Missing Tags in SOAP Body of Request Message

/(5.2) wsrf-rp:GetMultipleResourceProperties operation/

The non-normative example of the elements the ByteIO client adds to the SOAP body of the request message is missing the wsrf-rp:ResourceProperty tag. The SOAP body should instead contain the following:

wsrf-rp:GetMultipleResourceProperties

wsrf-rp:ResourceProperty sbyteio:Seekable

wsrf-rp:ResourceProperty sbyteio:TransferMechanism

wsrf-rp:ResourceProperty sbyteio:EndOfStream

--------------------------------------------------------------------------------

Possibly Incorrect Query

/(5.3) wsrf-rp:QueryResourceProperties operation/

This section incorrectly refers to a modification date query. It should instead state: In this case, the client wishes to query the resource’s writeable property.

Mainly, it is unclear whether the non-normative example of the elements the ByteIO client adds to the SOAP body of the response message contains the correct query. If the query should include the namespace, then it should be “/*/sbyteio:Writeable” and the SOAP body should then contain the following:

wsrf-rp:QueryResourceProperties

http://www.w3.org/TR/1999/REC-xpath-19991116”>

/*/sbyteio:Writeable

If the namespace is not required, then querying for “/*/Writeable” if fine.

--------------------------------------------------------------------------------

Missing Tag in SOAP body of Response Message

/(5.3) wsrf-rp:QueryResourceProperties operation/

The non-normative example of the elements the ByteIO client adds to the SOAP body of the response message is missing the sbyteio:Writeable tag. The SOAP body should instead contain the following:

wsrf-rp:QueryResourcePropertiesResponse

sbyteio:Writeable

true

-------------------------------------------------------------------------------- --------------------------------------------------------------------------------

Discussion

This section lists questions that need to be answered to resolve ambiguity in the Interoperability Fiesta documentation.

--------------------------------------------------------------------------------

Queries and Namespaces

If the client wishes to query a resources property, should the query contain the namespace? Which of the following queries are valid? The sections in parentheses refer to where the queries appear in the “ByteIO http://forge.gridforum.org/sf/wiki/do/createPage/projects.byteio-wg/wiki?pageName=ByteIO&referrerPageName=HomePage Interoperability Testing Scenarios” document.

* “/*/sbyteio:Writeable” vs. “/*/Writeable” (Section 5.3) * “/*/rbyteio:ModificationTime” vs. “/*/ModificationTime” (Section 4.3)

------------------------------------------------------------------------

-- byteio-wg mailing list byteio-wg@ogf.org http://www.ogf.org/mailman/listinfo/byteio-wg

------------------------------------------------------------------------

-- byteio-wg mailing list byteio-wg@ogf.org http://www.ogf.org/mailman/listinfo/byteio-wg

Hi Mark, all, Mark Morgan wrote:

Michel,

Definitely please do make the changes indicated. I think all of the changes you mentioned are fine though I do believe that part of the OGSA Base Profile (and part of WS-I) indicates that SOAPAction cannot be used for message routing. However, I think the changes you suggest are in line with that any ways (in so much as they still don't require services to use the action). Given the magnitude of some of these changes, we should probably extend the drop-dead deadline for the services by a week. Does anyone disagree. I'll give this 24 hours to percolate through everyone's mailboxes and will send out an amended date tomorrow.

-Mark

After torturing MS Word like it has never been tortured before (*G*) I produced new versions of all three ByteIO documents: - ByteIO Functional Specification, v1.5 - ByteIO WSRF Basic Profile Rendering Specification, v1.5 - ByteIO Interoperability Testing Specification, draft 12 I also attached them for your convenience. Mark, could you do me the favour and update Gridforge accordingly? All, please review the changes carefully, and give feedback. Cheers, Michel

Can you please come see me regarding this when you get in Kar? Thanks, Mark -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a@virginia.edu (434) 982-2047

-----Original Message----- From: byteio-wg-bounces@ogf.org [mailto:byteio-wg-bounces@ogf.org] On Behalf Of Michel Drescher Sent: Tuesday, July 17, 2007 2:34 AM To: Karolina Sarnowska Cc: byteio-wg@ggf.org Subject: Re: [BYTEIO-WG] ByteIO Interoperability Fiesta

Hi Karolina, all,

thanks for pointing these things out, good catch!

However, I think we are out of synch, mostly, I fear, it being y fault.

I have been browsing though old notes of ByteIO WG sessions and mailsw on the ML, and I discovered the following: - We once decided to drop WSRF message exchanges except for GetResourceProperty, as we are testing ByteIO, not WSRF - We decided to keep the WSRF GetResourceProperty test cases (sections 4.1 and 5.1) to check for a generally proper setup on the server side.

I actually have a draft 11 of the ByteIO Interop testing document that reflects all this; it somehow totally slipped my mind that I had to do some editorial stuff on the interop document. :(

Comments? Should I publish version 11, with or without the currently discovered issues?

Cheers, Michel

...

Hello All,

My name is Karolina Sarnowska. I am a part of Andrew Grimshaw's group at the University of Virginia. I have been working with Mark Morgan on getting Genesis II ready for the Interoperability Fiesta. I wanted to email everyone what I just posted on the Wiki regarding some issues with the documentation.

-Karolina

/ByteIO Interoperability Testing Scenarios/ Document Issues and Corrections

This section lists issues in the /ByteIO Interoperability Testing Scenarios/ document and presents corrections. The issues are listed in the order that they appear in the document and reference

Karolina Sadrnowska wrote: the specific section they refer to.

...

----------------------------------------------------------------------

...

----------

Missing Tags in SOAP Body of Request Message

/(4.2) wsrf-rp:GetMultipleResourceProperties operation/

The non-normative example of the elements the ByteIO client adds to the SOAP body of the request message is missing the wsrf-rp:ResourceProperty tag. The SOAP body should instead contain the following:

wsrf-rp:GetMultipleResourceProperties

wsrf-rp:ResourceProperty rbyteio:Readable

wsrf-rp:ResourceProperty rbyteio:Writeable

wsrf-rp:ResourceProperty rbyteio:TransferMechanism

...

----------

Incorrect Resource Property Name and Possibly Incorrect Query

/(4.3) wsrf-rp:QueryResourceProperties operation/

An incorrect name for the Resource Property is used in the non-normative example of the elements the ByteIO client adds to the SOAP body of the request message. The Resource Property queried is called "ModificationTime" not "ModificationDate". The SOAP body should instead contain

---------------------------------------------------------------------- the following:

...

wsrf-rp:QueryResourceProperties

http://www.w3.org/TR/1999/REC-xpath-19991116">

/*/rbyteio:ModificationTime

It is also unclear whether this example contains the

correct query. If

...

the query does not need to include the namespace, then the query could be instead "/*/ModificationTime".

----------------------------------------------------------------------

...

----------

Missing Tag in SOAP Body of Response Message

/(4.3) wsrf-rp:QueryResourceProperties operation/

The non-normative example of the elements the ByteIO client adds to the SOAP body of the response message is missing the rbyteio:ModificationTime tag. The SOAP body should instead contain the following:

wsrf-rp:QueryResourcePropertiesResponse

rbyteio:~ModificationTime

2006-09-11T16:15:33+05:00

----------------------------------------------------------------------

...

----------

Missing Tags in SOAP Body of Request Message

/(5.2) wsrf-rp:GetMultipleResourceProperties operation/

The non-normative example of the elements the ByteIO client adds to the SOAP body of the request message is missing the wsrf-rp:ResourceProperty tag. The SOAP body should instead contain the following:

wsrf-rp:GetMultipleResourceProperties

wsrf-rp:ResourceProperty sbyteio:Seekable

wsrf-rp:ResourceProperty sbyteio:TransferMechanism

wsrf-rp:ResourceProperty sbyteio:EndOfStream

----------------------------------------------------------------------

...

----------

Possibly Incorrect Query

/(5.3) wsrf-rp:QueryResourceProperties operation/

This section incorrectly refers to a modification date query. It should instead state: In this case, the client wishes to query the resource's writeable property.

Mainly, it is unclear whether the non-normative example of the elements the ByteIO client adds to the SOAP body of the response message contains the correct query. If the query should include the namespace, then it should be "/*/sbyteio:Writeable" and the SOAP body should then contain the following:

wsrf-rp:QueryResourceProperties

http://www.w3.org/TR/1999/REC-xpath-19991116">

/*/sbyteio:Writeable

If the namespace is not required, then querying for "/*/Writeable" if fine.

----------------------------------------------------------------------

...

----------

Missing Tag in SOAP body of Response Message

/(5.3) wsrf-rp:QueryResourceProperties operation/

The non-normative example of the elements the ByteIO client adds to the SOAP body of the response message is missing the sbyteio:Writeable tag. The SOAP body should instead contain the following:

wsrf-rp:QueryResourcePropertiesResponse

sbyteio:Writeable

true

----------------------------------------------------------------------

...

----------

----------------------------------------------------------------------

...

----------

Discussion

This section lists questions that need to be answered to resolve ambiguity in the Interoperability Fiesta documentation.

...

----------

Queries and Namespaces

If the client wishes to query a resources property, should

---------------------------------------------------------------------- the query

...

contain the namespace? Which of the following queries are valid? The sections in parentheses refer to where the queries appear in the "ByteIO

<http://forge.gridforum.org/sf/wiki/do/createPage/projects.byteio-wg/w

...

iki?pageName=ByteIO&referrerPageName=HomePage> Interoperability Testing Scenarios" document.

* "/*/sbyteio:Writeable" vs. "/*/Writeable" (Section 5.3) * "/*/rbyteio:ModificationTime" vs. "/*/ModificationTime" (Section 4.3)

----------------------------------------------------------------------

...

--

-- byteio-wg mailing list byteio-wg@ogf.org http://www.ogf.org/mailman/listinfo/byteio-wg