<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi,<br>
<br>
With some delay, thanks to Brian, Séverin and Andreas for their
answers.<br>
<br>
About the attributes DisplayName, Description, UCD, etc, I think
we will output them even if they are not part of the XSD schema.
Otherwise, it makes no sense to spend so much time in the document
describing them if they are actually not used/visible at the
end....and we already got them..so let's use them.<br>
<br>
Thank you again. We continue our VOSpace discovery and will keep
you up-to-date as soon as we have other questions or a living
working public VOSpace service.<br>
<br>
Cheers,<br>
Grégory<br>
<br>
<br>
<br>
On 14/05/2020 21:21, Brian Major wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKGJ5K_LRA0PFe=6YR=P2AjfmLjO1Yj24=YwrWKQh0xM+wP_yQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">http://server.example.com/vospace/nodes/mydir?detail=min&</a></tt><b><tt>uri=vos://<a
href="http://example.com" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">"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>
</blockquote>
<br>
</body>
</html>