Dave Morris just posted some spec. material to the list. I made some commments
privately on a previous draft of that material (earlier today). Here's a copy
of Dave's answers to those points.
Guy Rixon gtr-at-ast.cam.ac.uk Institute of Astronomy Tel: +44-1223-337542 Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
Guy Rixon wrote:
>Dave,
>
>thoughts on the specification.
>
>1. Where are the syntatic and semantic rules for vos:// URI?
>
>
Paul was pushing for a separate URI space, so I'm hoping he will cover this.
>2. As has been discussed before, the names of the operations are unhelpful.
>
>
Ok
I've been using them as working names so far because we have been
discussing more fundamental things like containers etc.
>3. I dislike the argument lists; to much like RPC style, which this isn't.
>I'd prefer to define all the structures in a .xsd schema, with identified root
>elements. Then, each SOAP message contains a document with one of these root
>element. That's true document/literal in the spirit of W3C. However, if the
>"parameters" are just the first-level children of the document element then it
>comes to the same thing.
>
>
Absolutely.
This is looking at the functional side of the service, and the params
are just a list of what data the WSDL/schema needs to represent.
How these are represented will hopefully be covered by Paul/Matthews
WSDL and schema.
>4. IVOIDs to identify standards are fine. Using IVOIDs in the
>org.astrogrid.vospace namespace is OK for protoyping, but we should not make
>these part of the final standard. We should make this clear in the spec.
>
>
The spec. refers to 'registered URI for http protocol'.
Ideally, I'd like things like this to registered under a 'net.ivoa'
authority.
Registering them under org.astrogrid is a way to raise the issue and
make it public.
Hopefully this will act as a catalyst to start the discussion.
>5. Where are the supported node-types enummerated?
>
>
They aren't.
I'll add this to the doc.
>6. Don't understand what GetData and PutData do if DIME is included in the
>other data-access methods.
>
>
Ok, I to explain more.
>11. POSIX has the create-but-fail-if-it-already-exists flag (O_EXCL, IIRC). We
>probably need this too.
>
>
<replace>false</replace>
>12. Since VOSpace 1.0 only covers flat spaces, do we need MoveNode? Or do we
>need it for renaming inside the same directory?
>
>
Yes, move is 'rename' and 'move in tree' combined.
>13. There used to be some operations to ask what transfer protocols a space
>supported. Is this information now got from the registry?
>
I was working on one registry entry for each VoSpace service.
Protocols listed in the capabilities.
> If so, it implies
>that an entire space (which is what what gets registered) supports the same
>protocols for all nodes.
>
Yes
> If the space is actually built up of a set of stores
>of different types, then the capability of the space becomes the
>intersection of the capabilities of the stores, which could be awkward.
>
>
Using links to federate spaces means we don't have individual stores -
they are all spaces.
>I would suggest listing the protocols in return from GetNodeProperties.
>However, this means a lot of extra look-ups. Might we make a rule that the
>transfer properties of a container node, if present, apply to all the
>node's children?
>
>
One set of protocol capabilities for the whole space.
>14. For asynchronous transfers, the problem is that we can't push
>notifications if the client is on the desktop (i.e. is not itself a SOAP
>server). Ask Noel for the reasoning if you're interested.
>
>Therefore, we have to support polling, so the <transfer> element has to
>contain some unique ID which the client can use in enquiries.
>
>To support push notification at all, with the limited SOAP tools, the client
>has also to be a service and needs to supply a notification endpoint when
>invoking the transfer.
>
>
Absolutely.
That is why asynch callbacks and status polling are going to be in
separate capability (V1.1).
Push has been to get the initial V1.0 spec. agreed and then we can move on.
>17. We're singling out VOTable as a known format. Do we need to identify other
>formats? FITS maybe?
>
>
Yep, will do.
It wasn't meant as a definitive list, just examples.
>18. Where does the client set or find out the MIME type?
>
>
I'd prefer in a property.
>More later...
>
>
Excellent stuff.
I'll make a few of the changes, but will leave the rest until after I
get this onto the ivoa list.
Would you mind re-posting comments to the ivoa list once I get it published.
Good way to get the discussion started.
Thanks,
Dave
Received on 2006-04-27Z20:17:51