VOSpace-1.0 WSDL and schema
This is a discussion page for the WSDL and schema for the VOSpace-1.0 service.
This is somewhere where we can post proposals for schema and WSDL to enable interested parties to discuss the different versions.
For each version there is a Change request section - please add to this and vote on other suggestions
- +1 if you agree
- -1 if you disagree
- 0 if you have no particular preference
Once we have finalised the WSDL and schema, the final versions will be posted on the main Grid & Web Services
page.
News
- Schema discussion page created.
Core schema
This is the main section for schema and WSDL files.
The files for the 1.0 VOSpace release are
-
VOSpace-v1.0.wsdl the main WSDL file.
-
VOSpaceBase-v1.0.xsd a subsidiary schema file that contains core types that might be useful in implementing a VOSpace server cf. the WSDL which contains types that are used only in the web service interface.
These file are packaged in a zip file which is named with the release candidate number for each sucessive release candidate. The exact release candidate number is also reflected in the files in
- the version attribute of the top level xsd:schema element in the schema file
- the name attribute of the top level wsdl:definitions element in the WSDL file
Version 1.0rc1
This is the first 'official' release candidate of the VOSpace interface definition, and is based on version 0.21 of the specification document, though is known not to follow this document exactly, as there are areas still to be finalized for which the WSDL is the best 'source'.
Change Requests
Use namespaces in release candidates that include release number
Votes
Make sure that the naming of operations/parameters more closely matches the written specification
Votes
Remove enumerations for security related types
Votes
Remove enumerations of transport keys
Votes
Remove enumerations of parameter key values
Votes
Remove any idea of callbacks
Votes
Remove the use of ChangeOwner operation
Votes
| name |
vote |
comment |
| PaulHarrison |
0 |
we do want this concept in 2.0 definitely and 2.0 servers are supposed to be able to talk to 1.0 servers - if we remove it now, we need to have a 1.1 release that does have different WSDL - however if we accept that 1.1 could have different WSDL then it can be dropped from 1.0. |
| MatthewGraham |
+1 |
| DaveMorris |
+1 |
Not in the specification document |
| GuyRixon |
+1 |
|
Keep Transports/Formats as separate opertation
--
PaulHarrison - 13 Jun 2006
I agree with adding the new methods.
However, this should be changed in the specification first, not the WSDL. Move this to the specification change page.
--
DaveMorris - 16 Jun 2006
Votes
Refactor use of DataObjectReference
This construct was there principally to get round difficulties in specifying the use-case "create a file with a server generated name" before the vos: URI scheme was approved. Not needed any more.
--
PaulHarrison - 16 Jun 2006
Needs to be much clearer what this represents.
--
DaveMorris - 16 Jun 2006
Consider use of Status responses for some operations
Changing the method signatures to return status codes should be defined in the specification first, not the WSDL. Move this to the specification change page.
--
DaveMorris - 16 Jun 2006
Votes
Experiments
The experiments have been moved to a separate
page
Include WSDL for VO Standard Interfaces
Is the VOSI WSDL finalized?
Votes
zip 
