VOSpace vs WebDAV

[Norman Gray]

Paul and all, hello.

[ I'm replying just to Paul's message here, because it's been a while since I last read the VOSpace spec, and so would be less confident replying to those messages (not that that's _necessarily_ stopped me in the past). ]

On 2014 May 16, at 08:17, Paul Harrison <paul.harrison at manchester.ac.uk> wrote:

> This does seem like a simple but good idea - is the “:" in the path part actually strictly allowed by the various RFCs (as our resident standards lawyer)? - I know that you can legally put “;” as "path parameters”, but I thought that : was one of the “top level delimiters”.

*Dons robes and wig...*

No, it's OK.  ":" is one of the 'pchar' characters that can appear in a URI path segment (there's a special case in the grammar that's there to avoid precisely the confusion with the scheme colon, but that's apparently to avoid "/foo:bar" being a legal URI, and doesn't preclude 'foo:' being part of an absolute URI.).

> The only nastiness that I can see is that unfortunately IVORNs have a resource key that looks hierarchical (and must be so interpreted according to the “/" rules for URIs) - it would be cleaner if IVORNS where just ivo://authority/key with no extra hierarchical parts - which actually represents what the “registry data model”  is.

What do you mean by "interpreted according to the “/" rules"?  The only rules that occur to me would be the ones about resolving relative URIs, and they would only apply to an IVORN if we were throwing around relative IVORNs (which we don't, I think), or if some lunatic at a data centre decided that /./ or /../ was a sensible thing to include in an IVORN.  Is there a gotcha I'm missing?

>> A resource (referenced by an ivo URI)
>> has 0..n capabilities, each of which has
>>   0..n interfaces, each of which has
>>     0..n accessURLs
>> 
>> (with RegTAP, we're pushing for 1:1 between interfaces and
>> accessURLs, but even then we have 1:n^2 between ivo and http).
>> 
>> So, a simple redirector won't cut it, and frankly I think plain HTTP
>> (in the sense of "curl is all you need") just won't do as a Registry
>> client protocol, even with accept: and all the other fancy stuff.
> 
> I was not originally thinking of a redirector all the way to the end service that is described by the registry resource, but simply just for accessing the resource record itself - then it is only like accessing a HTML web page (which might contain further links). I am not saying that this would the only registry access protocol (you still want to be able to do searches for which RegTAP is ideal), but the ark: idea above would provide a HTTP referable location for the resource record if you already knew the IVORN.
> 
> You could then imagine a pretty standard sort of REST API that did then give you parts of the resource
> 
> http://ivoa.net/registry/ivo:authority/resourcekey - would return the whole XML resource record.
> http://ivoa.net/registry/ivo:authority/resourcekey/capabilities - just returned the capabilities
> http://ivoa.net/registry/ivo:authority/resourcekey/capabilities/1  - the first capability
> http://ivoa.net/registry/ivo:authority/resourcekey/capabilities/1/interfaces - the interfaces etc.


I think this is a nice idea.  The fact that Registry entries are XML gives one a straightforward way of naming elements within them.

I was about to suggest that XPath could provide an out-of-the-box set of rules here, and that .../resourcekey/capabilities[1] would act as name for the first capability element, but "[" and "]" can't appear here in URIs.  But that's just a matter of syntax.

If this were to exist, I would expect that most users of this would just want to retrieve the whole resource record, wouldn't they?  Or am I missing a use-case?

See you,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK