VOSpace v1.15 PR comments

[Norman Gray]

Greetings.

Below are some comments on v1.15 of the VOSpace PR.

There are no deep conceptual queries, nor any comments which are  
merely typos.  They are mostly about the style and detail of the  
prescriptions in the document.  I haven't been at all involved in the  
VOSpace developments, beyond some coffee-time chats about it with Dave  
or Matthew, so I'm coming at this spec almost completely naive.

The comments are in document order.



Format: the page at <http://www.ivoa.net/Documents/cover/VOSpace-20090505.html 
 > shows only a .doc file as the available formats.  I trust that's a  
draft-only state of affairs, and there'll be an HTML version for REC,  
yes?  If I recall correctly, the Document Standards document  
prescribes HTML with a PDF alternative.

Conformance related definitions: the document says 'in upper or lower  
case', but I think it should be restricted to only upper-case uses (or  
some other distinguished way).  For example, in Sect. 3.3.3 there's a  
lowercase 'should' which is not a normative one.  As far as I can see,  
the document has been consistent in using MUST and SHOULD in upper- 
case in all normative contexts, so this will need little or no editing  
in the body of the text.

Sect 2: "A client SHOULD use the following procedure".  Using SHOULD  
suggests that there may be a sensible reason for not using this  
procedure, which suggests that there is some other under-the-counter  
way of getting this information.  If the concern is efficiency, then  
an alternative way of putting this might be "A client MUST use a  
procedure which is equivalent to the following": that means that a  
client can use a different procedure for efficiency reasons, but  
forbids any under-the-counter mechanisms (such as static local  
configuration files) unless they provably have the same effect, unless  
you do want to permit that in some circumstances.

Sect 2: there's a description of the resolution procedure for the  
'vos' scheme, which I believe illustrates quite well the vices of non- 
http URI schemes.  This battle has of course long been lost, and I  
have no wish to reopen it here -- I simply wish to lodge a 'gaarrrk,  
cough, blech!'.

Sect 3.1: the 'StructuredDataNode' definition might usefully and  
painlessly be made more precise than 'preserve the meaning'.  Perhaps:  
"StructuredDataNode describes a data item which the space  
understands.  A space MAY make transformations on such an item which  
results in a representation which is syntactically different but has  
the same information.  For XML formats, for example, this means any  
serialisation which has the same InfoSet [ref], and for FITS it means  
any FITS file which corresponds to the same (unordered) set of card  
images."

Sect 3.1: "URI-encoded according to RFC2396".  What work is "URI- 
encoded" doing here?  If whoever is minting this URI has, in the  
process, URI-encoded it or not, that's not the business of this spec;  
and if it for some reason hasn't been encoded and needs to be, then  
it's an invalid URI.  Also, RFC 2396 has been obsoleted by RFC 3986.   
Similarly with the "LinkNode" definition.

Sect 3.1: "MUST have no data bytes associated with them".  This seems  
an odd way of phrasing this, unless you mean to suggest that a  
ContainerNode or LinkNode could have a non-empty set of data endpoints  
associated with them, as long as those endpoints, when dereferenced,  
produce zero bytes (I'm not saying that this would be unreasonable,  
but it seems surprising and might therefore be worth commenting on).   
Might it be more natural to require that a ContainerNode's 'provides'  
and 'accepts' methods return empty arrays, which would have the same  
effect with less scope for misinterpretation?  If I'm understanding  
the process correctly, then it's impossible in any case for a LinkNode  
to provide any data bytes, since it doesn't have a 'provides' method  
on it (in which case this MUST is redundant and therefore confusing).

I realise, by the way, that I'm not confident that I _am_  
understanding the process correctly: the description in Sect. 2 stops  
at the point where the client has retrieved a VOSpace endpoint, and it  
might be useful to continue this example to the point where an HTTP  
endpoint (say) has been identified and some bytes retrieved.

Sect. 3.1: "SHOULD return a TypeNotSupported fault".  I can't think of  
any other sensible possibilities -- should this therefore be a MUST?

Sect 3.2.2: "The rules for the Property ... on a public service" (and  
the corresponding text in Sects. 3.3.2, 3.4.2 and 3.5.1).  I think  
this passage has some problems.

This Sect. 3.2 refers to URIs, URLs and URNs, although RFC 3986 more- 
or-less deprecates the latter two (myself, I think that the term 'URL'  
is still useful, informally implying a URI which is dereferenceable,  
so I'm not saying this is necessarily a defect).  Also, it's not clear  
from the text why it's talking about XML Schemas in this passage, and  
it seems to hint at a requirement without explicitly stating what it is.

Also, I think I would _always_ expect to be able to use non-conformant  
URIs in 'testing and development on a private system', so the second  
half of this passage seems otiose, and therefore makes me think I'm  
missing something.  Thus, if this passage is doing something other  
than giving me permission to do something I don't think I need  
permission for, then I think it might need to be expanded.

Sect 3.2.3: para 2: "Property description" should presumably be  
"PropertyDescription" (and again in a later paragraph in this  
section).  If this isn't a typo, then the passage reads oddly.

Sect 3.5.4.2: "Local NFS transfers".  This talks of transfers within a  
specific local NFS filesystem.  This is so local that it strikes me as  
odd that anyone would want to register an IVORN to describe it -- why  
would anyone not on this local system ever need to look this up?   
Indeed, it strikes me that one could reasonably insist that a site  
SHOULD NOT register such cluttering IVORNs.

Sect 3.6.1: para 2. "...the client constructs a Transfer request...",  
what happens if there are missing details in the transfer request?   
Whose fault is this and what happens next?  Can the service use  
defaults or try to repair the problem as best it can?  (similarly in  
the corresponding text in 3.6.2).

Sect 3.6.1: The sentence "The server SHALL be allowed to only use each  
Protocol option once" might be more readable as "The server MUST NOT  
use any Protocol option more than once".  In the following paragraph,  
"not allowed to" might be better as "MUST NOT" (similarly in the  
corresponding text in 3.6.2).

I hope these remarks are useful.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester, UK