Notes from VOSpace meeting with GuyRixon and MatthewGraham.

Mandate at least one protocol

http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace10Spec#Mandate_and_define_at_least_one

Not agreed.

Too many conflicting use cases, and security implications.

Specify well known transports

http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace10Spec#Specify_as_optional_a_small_list

Agreed.

Defined as a list of transports, wirth details of spec and how it is used as annexi of main spec.

• Dave HTTP GET and PUT
• Guy FTP
• Matthew jparse
• ??? DIME and MTOM (to discuss later)

Clarify format element in messages

Agreed, more later.

Wildcard in ListNodes^?

Agreed it would be useful, but not in this version.

• Needs more work on the wildcard syntax.
• Possibly combine this with other query forms in a separate search API ?

---

SetNodeProperties^?

Agree that it needs to be clearer in the spec.

• Operation is UNION of existing properties and changes.
• To delete a property use xsi:nill="true".

    <node>
        <properties>
            <!-- This updates the property value -->
            <property key="xxxx">new value</property>
            <!-- This sets the property value to an empty string -->
            <property key="yyyy"/>
            <!-- This deletes the property -->
            <property key="zzzz" xsi:nill="true"/>
        </properties>
    </node>

Operation can change all editable properties|elements of a node, including elements of an extended node type.

GetPropertykeys^?

Yes to the new method. Returns a list of the properties that this service knows about, but not 3rd party properties.

    <PropertyDescriptor readonly="true|false">
        <key>xxxx</key>
        <description>
            Text description of the property
        </description>
    </PropertyDescriptor>

To make it easier for UI to decide which properties are editable, also added editable attribute to node properties.

    <node>
        <properties>
            <property key="xxxx" editable="true|false">string value</property>
            <property key="yyyy" editable="true|false">string value</property>
        </properties>
    </node>

More details in faults

Agree

Will cover these in more detail when we look at individual messages.

Suggest we have a base class of VOSpaceException^?, and then extend that.

Check with WSI spec to see which is better, SOAPFault or MessageException^? ?

WSI-1000 has details of how to handle soap:Fault

Semantics for creating a server named data object

Agree CreateUniqueNode^?()

Will look at this in more detail later.

Rename status to TransferStatus^?

http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace10Spec#Rename_Status_of_Node_object_to

Not agreed.

Suggest a simplification of simple status attribute on *DataNode* of "busy" or "ready". All that a client really needs to know is can I download data from this node ?

    <!--+
        | The base class for all data nodes.
        | The data transfer methods operate at this level.
        +-->
    <complexType name="DataNodeType">
        <xsd:extension base="Node">
            ....
            <xsi:attribute name="busy" value="true|false"/>
        </xsd:extension>
    </complexType>

Need to check syntax of XSD.

Note - it is possible that a node may change from ready => busy => ready if underlying system is performing housekeeping. e.g. re-indexing DB or refactoring underlying filesystem

Node types and extensions

Suggest we have two sub-types of DataNode^?, Structured and Unstructured.

    <!--+
        | The base class for all node types.
        +-->
    <complexType name="NodeType">
        ....
    </complexType>

    <!--+
        | The base class for all data nodes.
        | The data transfer methods operate at this level.
        +-->
    <complexType name="DataNodeType">
        <xsd:extension base="one-zero:NodeType">
            ....
        </xsd:extension>
    </complexType>

    <!--+
        | A placeholder class to indicate unstructured data.
        | No additional elements.
        +-->
    <complexType name="UnstructuredDataType">
        <xsd:extension base="one-zero:DataNodeType">
            ....
        </xsd:extension>
    </complexType>

    <!--+
        | A class to represent structured data.
        | Additional elements TBD.
        +-->
    <complexType name="StructuredDataType">
        <xsd:extension base="one-zero:DataNodeType">
            ....
        </xsd:extension>
    </complexType>

Namespace changes for new node types, reflecting service version.

    <!--+
        | A new type specific to 1.1 service contract.
        +-->
    <complexType name="TablularDataType">
        <xsd:extension base="one-zero:StructuredDataType">
            ....
            <xsd:element name="struct">
                ....
            </xsd:element>
        </xsd:extension>
    </complexType>

Which would result in the following message XML for a 1.1 service.

    <one-zero:node uri="xxx" status="ready" xsi:type="one-one:TablularDataType">
        ....
        <one-one:struct> ... </one-one:struct>
    </one-zero:node>

Which can be extended further in 1.2

    <!--+
        | A new type specific to 1.2 service contract.
        +-->
    <complexType name="CustomTablularDataType">
        <xsd:extension base="one-one:TablularDataType">
            ....
            <xsd:element name="custom">
                ....
            </xsd:element>
        </xsd:extension>
    </complexType>

Which would result in the following message XML for a 1.2 service.

    <one-zero:node uri="xxx" status="ready" xsi:type="one-two:CustomTablularDataType">
        ....
        <one-one:struct> ... </one-one:struct>
        <one-two:custom> ... </one-two:custom>
    </one-zero:node>

At a major version number we can fold things back into the main spec.

    <two-zero:node uri="xxx" status="ready" xsi:type="two-zero:CustomTablularDataType">
        ....
        <struct> ... </struct>
        <custom> ... </custom>
    </one-zero:node>

Operations on same object

http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace10Spec#Consider_interactions_when_two_c

This is locking by another name.

Yes we need file locking ... but as an extension capability in future version.

Will need a full state diagram worked out before we add it to the specification.

Expired status

http://www.ivoa.net/twiki/bin/view/IVOA/VOSpace10Spec#Expand_expired_Node_status_to_in

Leave TransferStatus^? as an object until future version of VoSpace^?.

For V1.0, add a new attribute to DataNode^? content="empty,undefined,OK"

Node schema

    <node uri="vos://[xxxx]/yyyy/zzzz" xsi:type="">
        <properties>
            <property key="xxxx" editable="true|false">string value</property>
            <property key="yyyy" editable="true|false">string value</property>
        </properties>
    </node>