Debatable Issues for May Interop meeting on Registry in Kyoto:
- TERMS? - This is becoming a big subject lately.
- Application Extension? - Again Applications is popping up again from the Terms discussion. I suggest we give another look at what Paul Harrison gave us in the last couple of IVOA meetings. The CEA structure probably still needs some changes to be agreed upon by everyone, but we really should get the ball rolling on this one.
- Validation & Curation - Normally these are small things like xml elements being out of sequence, but in general there is a lot of non-validated xml. Maybe we should get tough and only allow validated XML into the registry.
- Extenstions? - I am thinking would it be a good idea for new extensions that clients/users create to the Registry to be placed in a particular ivoa/review/extensions url (and possibly namespace). That way we can more easily grab all extensions if needed and helps on validation if we do get tough on validation.
- adql:Select? - find a way of returning sub-elements of a Resource.
- Interface Addressing on Registry Type?- Talked briefly about in Pune, need to extend Registry type to show various Web Browser and WebService endpoints and locations.
- WS-Addreessing? - Cannot quite recall, but I remember Guy Rixon mentioned WS-Addressing for our Interface XML elements. (I think)
- Managed & Owned Authority? - (lower priority for next version of schema) A way of having a registry be a parent of another registry to show its owned authority id's.
- WSDL&OAI (Review)? - Might be good to briefly mention WSDL and OAI again to see if there are any particular issues involved. I know during Pune there was again a few questions about OAI. As well as a possible need for resumptionTokens on the Search interface.
- VOSpace & VOStore Extensions - This has stalled somewhat with the demos going on for VO projects. But I suspect by May this will have started up again, and may require a small review of some new extensions. Might involve ideas of rather a Service supports WS-Security or not.
- RegistryInterface.xsd - Do we really need it or can we put things back in the vr namespace.
- Update - Okay I wonder if it is worth putting on the table; a Update interface. For clients to update registries. This of course encompasses ws-security and other notions. So I am not sure if we want to touch this. But it could come in handy if we were willing to make this an ivoa standard. For example we could make an update smart enough to call the correct Registry who actually manages a AuthorityID, instead of making clients chase around the right registry.
- Registry mirrors, replication, derivation, etc.
- GetRegistries service - May I suggest possibly getting rid of GetRegistries and use ListRecords to do registry types as well.
- Feel free to add more..
- About the New Registry Interface Spec
- Trying to introduce the idea of using OAI sets, need to discuss this more I don't know if it is needed.
- Might need to bold more that ListRecords only returns authorities managed by this registry plus see the "GetRegistries service" comment above, I think it might be nice to add this to ListRecords.
- Probably need to add a link on the Appendix to the wsdls and schemas, just noticed they are not there.
- Need to look at the Registry type of the Resource schema it needs to be revamped to possibly determine types of registries and query, harvest (web browser and/or web service) endpoints/accessurls.
Experience from Astrogrid - Kevin Benson
This is just a few brief notes about the registry over the last several months. And areas I recently been thinking about; All of this relates to some of the debatable issues to be talked about above. First start off with Not-So-Good Points (not necesarily bad though).
Not-So-Good Points
- Communication - I think we should start a kind of a monthly registry telecon. A few things could have been avoided or found out much earlier, with more communication. Even if it might be a quick 5 minutes of "hey everything is going great"
- WSDL - This is really more of a good point see below, but it did have several mistakes that did not get caught untill quite late into the year (2004). Major thanks to Matthew Graham for pointing it out. Communication could have brought it out much earlier.
- RegistryInterface.xsd - I do now like our wsdl's being separated out and versioned. But in my opinion I would like to see a root element in the vr namespace not in RegistryInterface.xsd. And actually would like to see the VOResources in the vr namespace and get rid of the RegistryInterface.xsd.
- OAI - Again see below very good points about it.
- We had some confusion of what goes under the tag. A couple of different namespaces being defined; or if it is "resource" or "Resource" element. All this resulted in an xsl stylesheet just grabbing what is under metadata and putting it the way I store things at the Astrogrid.
- This is a doubtful one but thought I would bring it up, I think we still need the OAI-PMH to help us with the 3rd party tools, so registries can get up to speed faster. But I wonder if we can just return VOReources (with a modified resumptionToken if needed). Does anybody use anything except the metadata element? Does anybody use the oai_dc (dublic core)? Does anybody use anything bug ListRecords and possibly GetRecord? Again it might just need Ray to point out some other point about OAI, to not bother debating on this issue.
- Mostly all harvesting is being done with respect to the Web Browser. Astrogrid did some stsci web service, but that has dissappeared lately. So again conforming to the WSDL is not quite being done through all the registries. Mainly Astrogrid and Caltech.
- Again some confusion on adql:Select vs. adql:where, but I now agree adql:where is probably better for this version, but need to debate adql:Select.
Good points
- OAI - I actually think this was good. It gave us methods/verbs we could easily use. There was already 3rd party tools that could easily get it up and going. And after some discussions with Ray on an idea about just having our Web Services use the Web Browser type ways, this made Web Service methods quite easy.
- WSDL - I think overall the WSDL is getting into a fairly good shape, again discussion on this adql:Select vs. adql:Where will be needed. Plus a possible resumptionToken idea on the Search. And a small discussion of if we need the RegistryInterface.xsd and put elements back into the vr namespace. Other than that, I think it should not be much changed.
- Harvesting/Search - it is good to see that our Registries are slowly starting to interoperate not just on harvesting, but a couple of small recent tests on a fall over to other registries such as CalTech are producing results.