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">
to use the same type as Node properties
<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>
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.
<vor:Resource xsi:type="vsp:VOSpaceProtocol">
....
<protocol id="http-get">
....
</protocol>
<protocol id="ftp-get">
<param id="name">
....
</param>
</protocol>
....
</vor:Resource>
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.
<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>
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. |