VOSpace10schema < IVOA

<H1><nop>VOSpace-1.0 WSDL and schema</H1>

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 [[IvoaGridAndWebServices][page]].

The experiments that were on this page have been [[VOSpace10schemaExperiments][moved]]

---
%TOC%
---

---++ News
   * Mailing list for discussions of <nop>VOStore and associated protocols: <b> vospace@ivoa.net </b><br/>Messages archive: http://ivoa.net/forum/vospace/

   * Schema discussion page created.

---+ Core schema
This is the main section for schema and WSDL files.

---++ Version 1.0rc5

   * [[%ATTACHURL%/VOSpaceContract-v1.0rc5.wsdl][VOSpaceContract-v1.0rc5.wsdl]]: Service WSDL V1.0rc5

   * [[%ATTACHURL%/VOSpaceTypes-v1.0rc5.xsd][VOSpaceTypes-v1.0rc5.xsd]]: XML Schema V1.0rc5


Changes from V1.0rc4
   * Added =elementFormDefault="qualified"= to WSDL and schema
   * Restored =ParamType= for view and protocols params (changed back from =PropertyType= used in rc4).
   * Removed commented =xsd:annotation= elemets that broke Axis code generator.
   * Removed =ViewErrorType=, not required and reports that it caused some problems.
   * Added =nillable="true"= to fault details.
   * Changed =TypeNotSupportedFault= to use =xsd:QName= (let me know if this causes problems).

Question : Should we add a text message to the base class for our faults. Currently we rely on using the message in the standard SOAP fault. 

---++ Version 1.0rc4

   * [[%ATTACHURL%/VOSpace-v1.0rc4.zip][VOSpace-v1.0rc4.zip]]: Zip file containing core schema and wsdl for rc4

   * [[%ATTACHURL%/VOSpaceResource-v1.0rc4.xsd][VOSpaceResource-v1.0rc4.xsd]]: VOSpace registry schema 1.0rc4

   * [[%ATTACHURL%/vospace-1.0rc4.xml][vospace-1.0rc4.xml]]: Example VOSpace registry documents 1.0rc4

There is a known problem with the rc4 schema.

In rc3 we changed Protocol and View params from
<verbatim>
    <xsd:element name="param" xsi:type="vos:ParamType">
</verbatim>
to use the same type as Node properties
<verbatim>
    <xsd:element name="param" xsi:type="vos:PropertyType">
</verbatim>

This meant that params were identified by uri rather than a string name.

The original intention was that we would use the fragment symbol '#' to reference the param description within the resource document for the protocol or view.
<verbatim>
    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>
</verbatim>
In this example, the param uri refers to the definition of the =name= param within the ftp-get protocol resource.
The full uri of the param would be =ivo://net.ivoa.vospace/protocols/ftp-get#name=

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.
<verbatim>
    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>
</verbatim>
This uses one resource document to register all of the vospace protocols as a set, and using the '#' fragment identifier to resolve one protocol within the set.

For example, the full uri for the =ftp-get= protocol would be =ivo://net.ivoa.vospace/protocols#ftp-get=

However, this means that we can't use the '#' fragment identifier to refer to a specific parameter within a protocol without overloading its meaning and using it twice. e.g. =ivo://net.ivoa.vospace/protocols#ftp-get#name=.

I can't see a strong use case for registering params as separate entities outside protocols and views, so we probably don't need a full uri to identifiy a param. In which case, to solve the above problems we might as well change back to using a string key to identify params within protocols and views.

So, next version of the schema will revert to using ParamType for protocol and view params, identified by a string key rather than a uri. 
<verbatim>
    <xsd:element name="param" xsi:type="vos:ParamType">
</verbatim>

Note also that allowing more than one protocol description within one resource document means that we can end up with more than one element with the same =id= attribute. 
<verbatim>
    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
            <param id="pass">
                ....
            </param>
        </protocol>
        <protocol id="ftp-put">
            <param id="name">
                ....
            </param>
            <param id="pass">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>
</verbatim>
In this example, we have two param elements with =id="name"= and two param elements with =id="pass"=.

Ideally, the =id= attributes should be unique within an XML document, so the identifying attribute on param elements should probably be changed to =key=, matching the way they are used in the main schema.

---++ Version 1.0rc3

[[%ATTACHURL%/vospace-interface-1.0rc3.zip][vospace-interface-1.0rc3.zip]]

This matches v0.22 of the specification document.

---++ Version 1.0rc2
   * [[%ATTACHURL%/vospace-interface-1.0rc2.zip][vospace-interface-1.0rc2.zip]]: vospace-interface-1.0rc2.zip

This release attempts to follow the interface described in version 0.21 of the specification document as closely as possible.

---++ Changes from previous version
   * Use namespaces in release candidates that include release number
   * Make sure that the naming of operations/parameters more closely matches the written specification
   * Remove enumerations for security related types
   *  Remove enumerations of transport keys
   *  Remove enumerations of parameter key values
   *  Remove any idea of callbacks
   *  Remove the use of <noop>ChangeOwner operation

---++ Change Requests

---+++ Keep Transports/Formats as separate opertation

-- IVOA.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.

-- IVOA.DaveMorris - 16 Jun 2006

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.DaveMorris | -1 |Change the specification document first|
| IVOA.GuyRixon | -1 | Change spec first |

---+++ Refactor use of <noop>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.

-- IVOA.PaulHarrison - 16 Jun 2006

Needs to be much clearer what this represents.

-- IVOA.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.

-- IVOA.DaveMorris - 16 Jun 2006

---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.DaveMorris | -1 |Change the specification document first|
| IVOA.GuyRixon | -1 | Don't see the need: we have faults for errors conditions |


---+++ Include WSDL for VO Standard Interfaces
Is the VOSI WSDL finalized?
---++++ Votes
| *name* | *vote*| *comment* |
| IVOA.PaulHarrison | +1 | proposer|
<br/>
---
---++ Version 1.0rc1
   * [[%ATTACHURL%/vospace-interface-1.0rc1.zip][vospace-interface-1.0rc1.zip]]: vospace-interface-1.0rc1.zip

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'.

<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
zip	VOSpace-v1.0rc4.zip	r1	manage	7.2 K	2006-07-20 - 13:32	GuyRixon	Updated to rc4
wsdl	VOSpaceContract-v1.0rc5.wsdl	r1	manage	45.0 K	2006-07-28 - 21:58	DaveMorris	Service WSDL V1.0rc5
xsd	VOSpaceResource-v1.0rc4.xsd	r1	manage	11.0 K	2006-07-21 - 10:37	PaulHarrison	VOSpace registry schema 1.0rc4
xsd	VOSpaceTypes-v1.0rc5.xsd	r1	manage	38.3 K	2006-07-28 - 21:59	DaveMorris	XML Schema V1.0rc5
zip	vospace-1.0-rc3.zip	r1	manage	6.1 K	2006-07-18 - 09:38	GuyRixon	Matches v0.22 of the specification document
xml	vospace-1.0rc4.xml	r1	manage	9.2 K	2006-07-21 - 10:38	PaulHarrison	registry instance document 1.0rc4
zip	vospace-interface-1.0rc1.zip	r1	manage	7.3 K	2006-06-13 - 15:34	PaulHarrison	vospace-interface-1.0rc1.zip
zip	vospace-interface-1.0rc2.zip	r1	manage	6.1 K	2006-06-20 - 14:39	PaulHarrison	1.0rc2 interface

This topic: IVOA > WebHome > IvoaGridAndWebServices > VOSpace10schema
Topic revision: r20 - 2006-07-28 - DaveMorris