| 9 | 1. Allow input data to be passed to the service as a reference type. |
| 10 | a. Do this without breaking any existing typing system such as Moby data types, XML schema - this implies that the description of the service must seperate the transport and data content descriptions in some way. The service at a conceptual level consumes the data type independently of the transport type the service container uses to supply this. |
| 11 | 2. When the call to the service is made the service should allow the client to specify the delivery type for any results. |
| 12 | a. Delivery types can be specified as references - there are already systems out there such as the OGSA-DAI system that define a delivery block (such as 'put data on this ftp server and return a URL to it' |
| 13 | b. Some level of negotiation would be good - client requests a set of plausible references and the service negotiates one it can provide. |
| 14 | c. The default delivery would presumably be pass by value. |
| 15 | 3. Ideally a naive (non reference aware) client should be able to use the service exactly as it would without any of this work - this implies either back compatibility at the client API layer (Moby) or back compatibility in the description (i.e. WSDL) |
| 16 | 4. Allow some level of lifecycle management for results held in a delivery location |
| 17 | a. Allow the client to request specific characteristics i.e. 'hold this data for at least five minutes' |
| 18 | b. Generate policies based on authentication where present? |
| 19 | |