Published as GFD.160 on 2009-11-30.

The document below which contains a very minor change from that submitted to public comment is ready for publication.

We have now done our interop process for two independent implementations of the WS-DAI (GFD.74) and WS-DAIR (GFD.76) - mainly one from OGSA-DAI and 
the other from AMGA. We would like to proceed by taking the WS-DAI and WS-DAIR proposed recommendations to full recommendation status. I gather that 
this requires the appointment of an external reviewer that will examine the documents and advice on how to proceed.

Let me know if something else is required from the DAIS-WG.

In response to the comments that Elias made:

- In case of GetSQLResponseItem, maybe it should be  
  clarified that the items are supposed to return in order,  
  i.e. first rowsets, then update counts, etc

   Point 24 on page 32 of the interop document proposes  
   an update to the proposed WS-DAIR recommendation 
   to specify an order in which these elements SHOULD 
   be returned.

- In case of GetTuples, the AccessMode will give an 
  error if already the required rows have been 
  accessed. It was not clear how this
  condition would be produced on the test.

   Test 16 invokes SQLRowset::GetTuples to get 1 
   tuple at position 1 (the second tuple available, 
   since the first tuple is at position 0). Test 17 then 
   attempts to get the first tuple at position 0:

     If the SQLRowset supports Random AccessMode 
     then Test 17 expects the first tuple to be returned.

     If the SQLRowset supports Forward AccessMode 
     then Test 17 expects an InvalidPositionFault to be 
    generated.

- Finally, without knowing the details of the AMGA 
   implementation, is consistency expected with the 
   OGSA-DAI one in the case that an SQLResponse is 
   destroyed and consequently all the child 
   SQLRowsets are destroyed as well?

   The WS-DAI specifications do not specify what 
   happens when associated derived data resources 
   are destroyed (ChildSensitiveToParent and 
   ParentSensitiveToParent give an indication of 
   whether changes in the dervied data resources
   are written through to the parent or vice versa but 
   this becomes irrelevant if the parent or child 
   resource is not there anymore). See 5.3.3 in the 
   WS-DAI spec:

   When an internally managed data resource is 
   destroyed all of its associated data MAY be 
   destroyed, and the resources used MAY be
   reclaimed. The internal behavior depends upon the 
   data access service implementation but from the 
   consumers perspective the data resource is no 
   longer available following this operation.

   Hence there is no reason for AMGA to be consistent 
   in behaviour to what OGSA-DAI does.

Oops ... sorry commented on the wrong document - meant to do it for the motivational one and not this one that is already up ... :(

The public comment tracker:
  http://www.ogf.org/gf/docs/comment.php?id=308

Would be good if it go into public comment before OGF so the folks that are going to be there could mention it at the meeting though I realise that 
you will be very busy just now ...