VOSpace-1.0 WSDL and schema

The VOSpace-1.0 schema has been completed, the release versions are available here :

• VOSpaceContract-v1.0.wsdl: Final 1.0 version
• VOSpaceTypes-v1.0.xsd: Final 1.0 version

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.

The experiments that were on this page have been moved

Core schema

Version 1.0rc6

• VOSpaceContract-v1.0rc6.wsdl: Service WSDL V1.0rc6

• VOSpaceTypes-v1.0rc6.xsd: XML Schema V1.0rc6

Changes from V1.0rc5

• ensured that Axis 1.3 WSDL2Java would produce code
  • corrected fault declarations
  • redefined PropertyReferenceType so that it was not derived by restriction.

-- PaulHarrison - 03 Aug 2006

Comments

• why is View optional in TransferType - what view should be assumed if is missing? -- PaulHarrison - 11 Sep 2006
• the extra metadata that is added with exceptions still needs review -e.g. NodeNotFoundFaultType includes uri for the node (sensible), but ProtocolNotSupportedFault need a full Protocol object -- PaulHarrison - 11 Sep 2006
• not sure that parameters for protocols are really useable, will need specialized client to deal with them if the protocol does not already allow parameters in the URL format c.f. http. -- PaulHarrison - 11 Sep 2006
• in general this is too much reuse of types in several places where it would aid understanding to have two separate types - TransferType is one of the best examples of this - on an operation where this type is used to specify a request to transfer data - only parts of the subtypes are relevant - e.g. endpoint of the protocol is not meaningful - this leads to
  • elements being made optional in the schema, when in some uses of the type they are actually mandatory
  • and, as a consequence, the explanatory documentation having to be more complicated.

Version 1.0rc5

• VOSpaceContract-v1.0rc5.wsdl: Service WSDL V1.0rc5

• 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

• VOSpace-v1.0rc4.zip: Zip file containing core schema and wsdl for rc4

• VOSpaceResource-v1.0rc4.xsd: VOSpace registry schema 1.0rc4

• 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

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

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

• VOSpaceContract-v1.0.wsdl: Final 1.0 version
• VOSpaceTypes-v1.0.xsd: Final 1.0 version

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.

The experiments that were on this page have been moved

Core schema

Version 1.0rc6

• VOSpaceContract-v1.0rc6.wsdl: Service WSDL V1.0rc6

• VOSpaceTypes-v1.0rc6.xsd: XML Schema V1.0rc6

Changes from V1.0rc5

• ensured that Axis 1.3 WSDL2Java would produce code
  • corrected fault declarations
  • redefined PropertyReferenceType so that it was not derived by restriction.

-- PaulHarrison - 03 Aug 2006

Comments

• why is View optional in TransferType - what view should be assumed if is missing? -- PaulHarrison - 11 Sep 2006
• the extra metadata that is added with exceptions still needs review -e.g. NodeNotFoundFaultType includes uri for the node (sensible), but ProtocolNotSupportedFault need a full Protocol object -- PaulHarrison - 11 Sep 2006
• not sure that parameters for protocols are really useable, will need specialized client to deal with them if the protocol does not already allow parameters in the URL format c.f. http. -- PaulHarrison - 11 Sep 2006
• in general this is too much reuse of types in several places where it would aid understanding to have two separate types - TransferType is one of the best examples of this - on an operation where this type is used to specify a request to transfer data - only parts of the subtypes are relevant - e.g. endpoint of the protocol is not meaningful - this leads to
  • elements being made optional in the schema, when in some uses of the type they are actually mandatory
  • and, as a consequence, the explanatory documentation having to be more complicated.

Version 1.0rc5

• VOSpaceContract-v1.0rc5.wsdl: Service WSDL V1.0rc5

• 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

• VOSpace-v1.0rc4.zip: Zip file containing core schema and wsdl for rc4

• VOSpaceResource-v1.0rc4.xsd: VOSpace registry schema 1.0rc4

• 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

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

VOSpace-1.0 WSDL and schema

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.

The experiments that were on this page have been moved

Core schema

Version 1.0rc6

• VOSpaceContract-v1.0rc6.wsdl: Service WSDL V1.0rc6

• VOSpaceTypes-v1.0rc6.xsd: XML Schema V1.0rc6

Changes from V1.0rc5

• ensured that Axis 1.3 WSDL2Java would produce code
  • corrected fault declarations
  • redefined PropertyReferenceType so that it was not derived by restriction.

-- PaulHarrison - 03 Aug 2006

Comments

• why is View optional in TransferType - what view should be assumed if is missing? -- PaulHarrison - 11 Sep 2006
• the extra metadata that is added with exceptions still needs review -e.g. NodeNotFoundFaultType includes uri for the node (sensible), but ProtocolNotSupportedFault need a full Protocol object -- PaulHarrison - 11 Sep 2006
• not sure that parameters for protocols are really useable, will need specialized client to deal with them if the protocol does not already allow parameters in the URL format c.f. http. -- PaulHarrison - 11 Sep 2006
• in general this is too much reuse of types in several places where it would aid understanding to have two separate types - TransferType is one of the best examples of this - on an operation where this type is used to specify a request to transfer data - only parts of the subtypes are relevant - e.g. endpoint of the protocol is not meaningful - this leads to
  • elements being made optional in the schema, when in some uses of the type they are actually mandatory
  • and, as a consequence, the explanatory documentation having to be more complicated.

Version 1.0rc5

• VOSpaceContract-v1.0rc5.wsdl: Service WSDL V1.0rc5

• 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

• VOSpace-v1.0rc4.zip: Zip file containing core schema and wsdl for rc4

• VOSpaceResource-v1.0rc4.xsd: VOSpace registry schema 1.0rc4

• 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

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

Version 1.0rc6

• VOSpaceContract-v1.0rc6.wsdl: Service WSDL V1.0rc6

• VOSpaceTypes-v1.0rc6.xsd: XML Schema V1.0rc6

Changes from V1.0rc5

• ensured that Axis 1.3 WSDL2Java would produce code
  • corrected fault declarations
  • redefined PropertyReferenceType so that it was not derived by restriction.

-- PaulHarrison - 03 Aug 2006

Version 1.0rc5

• VOSpaceContract-v1.0rc5.wsdl: Service WSDL V1.0rc5

• 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

• VOSpace-v1.0rc4.zip: Zip file containing core schema and wsdl for rc4

• VOSpaceResource-v1.0rc4.xsd: VOSpace registry schema 1.0rc4

• 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

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

Version 1.0rc5

• VOSpaceContract-v1.0rc5.wsdl: Service WSDL V1.0rc5

• 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

• VOSpace-v1.0rc4.zip: Zip file containing core schema and wsdl for rc4

• VOSpaceResource-v1.0rc4.xsd: VOSpace registry schema 1.0rc4

• 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

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

Version 1.0rc4

• VOSpace-v1.0rc4.zip: Zip file containing core schema and wsdl for rc4

• VOSpaceResource-v1.0rc4.xsd: VOSpace registry schema 1.0rc4

• vospace-1.0rc4.xml: Example VOSpace registry documents 1.0rc4

In rc3 we changed Protocol and View params from

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

• VOSpaceContract-v1.0rc4.wsdl the service WSDL contract
• VOSpaceTypes-v1.0rc4.xsd the XSD schema file containing the XML type definitions.

Version 1.0rc4

• VOSpace-v1.0rc4.zip: Zip file containing core schema and wsdl for rc4

• VOSpaceResource-v1.0rc4.xsd: VOSpace registry schema 1.0rc4

• 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

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

• VOSpaceContract-v1.0rc4.wsdl the service WSDL contract
• VOSpaceTypes-v1.0rc4.xsd the XSD schema file containing the XML type definitions.

Version 1.0rc4

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

• VOSpaceContract-v1.0rc4.wsdl the service WSDL contract
• VOSpaceTypes-v1.0rc4.xsd the XSD schema file containing the XML type definitions.

Version 1.0rc4

• VOSpace-v1.0rc4.zip: Updated to rc4

There is a know problem with this version.

In rc3 we changed Protocol and View params from

    <xsd:element name="param" xsi:type="vos:ParamType">

    <xsd:element name="param" xsi:type="vos:PropertyType">

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.

    <protocol uri="ivo://net.ivoa.vospace/protocols/ftp-get">
        <param uri="#name">
            ....
        </param>
    </protocol>

However, the latest metadata schema allows more than one protocol or view to be defined in a single resource document.

    <vor:Resource xsi:type="vsp:VOSpaceProtocol">
        ....
        <protocol id="http-get">
            ....
        </protocol>
        <protocol id="ftp-get">
            <param id="name">
                ....
            </param>
        </protocol>
        ....
    </vor:Resource>

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.

    <xsd:element name="param" xsi:type="vos:ParamType">

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.

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

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

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

• VOSpaceContract-v1.0rc4.wsdl the service WSDL contract
• VOSpaceTypes-v1.0rc4.xsd the XSD schema file containing the XML type definitions.

Version 1.0rc4

• VOSpace-v1.0rc4.zip: Updated to rc4

Version 1.0rc3

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

Version 1.0rc3

vospace-interface-1.0rc3.zip

This matches v0.22 of the specification document.

Version 1.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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.

The experiments that were on this page have been moved

News

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

1. VOSpace-v1.0.wsdl the main WSDL file.
2. 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.0rc2

• 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 ChangeOwner operation

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

Version 1.0rc1

• 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 = TWikiAdminGroup
 
 
-->

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

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

1. VOSpace-v1.0.wsdl the main WSDL file.
2. 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

Change Requests

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

Include WSDL for VO Standard Interfaces

Votes

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

1. VOSpace-v1.0.wsdl the main WSDL file.
2. 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

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

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

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

name	vote <-- -->	comment
DaveMorris	-1	Change the specification document first
GuyRixon	-1	Change spec first

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

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

1. VOSpace-v1.0.wsdl the main WSDL file.
2. 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

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

Change Requests

Rename bulk data transfer operations

• I stilll find the data transfer operations confusing- I think that the basic problem is that the push and pull verbs are opposite in meaning and viewed from opposite perspectives. I have a new set of proposals

which I think are better because

1. the overall objective of the operation is the first verb
2. the active party in the transfer is identified
3. the direction of the transfer is then related to the active party.

-- PaulHarrison - 13 Jun 2006

This is a change to the specification not the WSDL, move this to the specification change page.

-- DaveMorris - 16 Jun 2006

Votes

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

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

Keep new GetPropertyKeys operation

-- PaulHarrison - 13 Jun 2006

I agree with adding the method. 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

Add new createTempNode operation

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

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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

• Mailing list for discussions of VOStore and associated protocols: vospace@ivoa.net
  Messages archive: http://ivoa.net/forum/vospace/

• Schema discussion page created.

Core schema

The files for the 1.0 VOSpace release are

1. VOSpace-v1.0.wsdl the main WSDL file.
2. 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

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

Change Requests

Rename bulk data transfer operations

• I stilll find the data transfer operations confusing- I think that the basic problem is that the push and pull verbs are opposite in meaning and viewed from opposite perspectives. I have a new set of proposals

which I think are better because

1. the overall objective of the operation is the first verb
2. the active party in the transfer is identified
3. the direction of the transfer is then related to the active party.

Votes

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

Keep Transports/Formats as separate opertation

Votes

Keep new GetPropertyKeys operation

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.

Add new createTempNode operation

Votes

Consider use of Status responses for some operations

Experiments

The experiments have been moved to a separate page

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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.