<div dir="ltr"><div>Hi Grégory,</div><div><br></div><div>It is exciting to hear about a new VOSpace implementation in the works. I've added my thoughts to your questions below.</div><div><br></div><div>Cheers,</div><div>Brian</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 6:30 AM Grégory Mantelet <<a href="mailto:gregory.mantelet@astro.unistra.fr" target="_blank">gregory.mantelet@astro.unistra.fr</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><b>
1. About getNode and its parameter `detail=min`:</b><br>
<br>
The VOSpace document says:<br>
<blockquote>
<blockquote type="cite">- min: the returned record for the node
contains minimum detail<br>
with all optional parts removed – the node type should
be re-<br>
turned</blockquote>
</blockquote>
If I try to sum up: the "optional parts" are everything except
<vos:nodes> in case of a ContainerNode. So, it means that
apart from the node type (attribute xsi:type) a non-ContainerNode
will be empty.<br>
<br>
Is it correct?<br>
<br>
If yes, there is a mistake in the example given in 6.3.1: the
XML elements <vos:properties>, <vos:accepts>,
<vos:provides> and <vos:capabilities> should not be
returned. According to the XML schema they are optional.<br>
Or are they optional only if empty?<br>
Or because "SHALL" is used instead of "MAY" (in 3.1, page 13) it
make them mandatory if not empty?<br></div></blockquote><div><br></div><div>Yes, you are correct and the example is wrong. I've created an issue for it:</div><div><br></div><div><a href="https://github.com/ivoa-std/VOSpace/issues">https://github.com/ivoa-std/VOSpace/issues</a><br></div><div><br></div><div>(This is the first issue for this standard. If this is not the correct procedure, TCG, please let us know. If this is correct then the list of items at <a href="https://wiki.ivoa.net/twiki/bin/view/IVOA/VOSpaceHome#VOSpace_2_2_or_3_0">https://wiki.ivoa.net/twiki/bin/view/IVOA/VOSpaceHome#VOSpace_2_2_or_3_0</a> should be added as issues at some point.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
--------------<br>
<br>
<b>2. About getNode and its parameters `uri` and `offset`:</b><br>
<br>
The VOSpace document says:<br>
<blockquote>
<blockquote type="cite">If a “uri” and “offset” are specified in
the request then the returned list<br>
will consist of the subset of children which begins at the node
matching<br>
the specified value of the “uri” parameter and with cardinality
matching the<br>
specified value of the “offset” parameter drawn from an ordered
sequence<br>
of all children. The ordering is determined by the server but
results must<br>
always be drawn from the same ordered sequence.</blockquote>
</blockquote>
When it is said "which begins at the node matching the specified
value of the “uri” parameter",<br>
does "begin" mean "the string begins" or "the returned sublist
must starts with"?<br>
<br>
For instance, in the given example:<br>
<br>
<tt><a href="http://server.example.com/vospace/nodes/mydir?detail=min&" target="_blank">http://server.example.com/vospace/nodes/mydir?detail=min&</a></tt><b><tt>uri=vos://<a href="http://example.com" target="_blank">example.com</a>!vospace/mydir/file3401</tt><br>
</b><br>
* Should the `uri` filter be interpreted as all files whose name
begins with "file3401" in the directory
"vos://<a href="http://example.com" target="_blank">example.com</a>!vospace/mydir"?<br>
<i>(e.g. "file3401a", "file3401b", ...)<br>
<br>
</i>* If yes, the example in 6.3.1. should be fixed.<i><br>
</i><br>
* Or should it be the sublist of all children starting from the
child "file3401"?<br>
<i>(e.g. if the complete ordered list is [file3399, file3400,
file3401, file3402, file3403], the returned list would be
[file3401, file3402, file3403])</i></div></blockquote><div><br></div><div>It should be the sublist of all children (your second example.). The uri and offset parameters are giving clients a method to 'page' through a potentially long list of child nodes.</div><div><br></div><div>It doesn't specify if detail=min applies to the child nodes, but I think the example is correct in this case in that only the type is shown for the DataNodes. The same should be true for child ContainerNodes because a getNode should only go 1 level deep.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
<br>
--------------<br>
<br>
<b>3. About getNode</b><br>
<br>
Using the same example as in the document, if I run the
following request:<br>
<br>
<tt>curl -v <a href="http://server.example.com/vospace/nodes" target="_blank">"http://server.example.com/vospace/nodes"</a></tt><br>
<br>
Should it give me the list of all child nodes at the root of the
VOSpace (as if the root is itself a ContainerNode)?<br>
<br>
Sorry for the possibly stupid question, but it is just to be
sure.<br></div></blockquote><div><br></div><div>Yes, that's correct. It's like / in a file system.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
--------------<br>
<br>
<b>4. About Properties, Capabilities and Views</b><br>
<br>
Properties, Capabilities and Views may have the following
attributes:<br>
<br>
- DisplayName<br>
- Description<br>
- UCD <i>(only for Properties)</i><br>
- Unit <i>(only for Properties)<br>
</i> - MimeType <i>(only for Views)<br>
</i><br>
But none of these elements appear in the XML schema (and they
appear in no example). The XML schema does not give enough
flexibility to insert additional information like these.<br>
<br>
So, we wonder how to represent them in the XML and where? How
can they be discovered?<br>
Have we missed something?<br></div></blockquote><div><br></div><div>Right, there is clearly an inconsistency there. We at the CADC have implemented these endpoints according to the XSD, but they are not particularly useful to us in our interaction with our VOSpace instances.</div><div><br></div><div>Hope this helps. Cheers,</div><div><br></div><div>Brian</div></div></div>