proposal: mtypes for exchanging specific types of registry resource.

[Noel Winstanley]

Hi,

I'd like to propose some mtypes for exchanging specific kinds of registry resource.

I've already proposed a mtype for exchanging an arbitrary set of registry resources (voresource.loadlist)  ( http://www.ivoa.net/forum/apps-samp/0903/0332.htm, and http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampMTypes ). This is implemented in VOExplorer, and, I believe, Aladin. 

Although an mtype for a aribtrary set of registry resources is useful, I believe there's a use case for more strongly-typed voresource messaging too:

For example, if an application knows how to perform a cone-search on a service, it could usefully process SAMP messages containing voresources with a cone-search capability (e.g by displaying it's cone-search GUI form). Yet it's doubtful whether it could do anything useful with other kinds of voresource.

The voresource.loadlist mtype doesn't provide any information as to what kinds of resource a receiver is interested in. Without this information, users are liable to get frustrated by sending resources to a receiver, and either a failure, or nothing occuring.

So, I'd like to provide a series of subtypes of voresource.loadlist - each of these have the same message parameters and semantics, but the intention is that the set of vo resources is constrained in some way.

voresource.loadlist.cone - a set of resouces, where each has a cone-search capability
voresource.loadlist.tap - a set of resources that each has a TAP capability
voresource.loadlist.siap - a set of resources that each has a SIAP capability.
voresource.loadlist.ssap - each has a SSAP capability.
voresource.loadlist.vospace - each has a vospace capability.

I hope you can see the pattern here ;)

Are there any other subtypes that would be useful?

If an application could process more than one kind of voresource (e.g. an application that can perform both cone and SIAP searches), it would subscribe to both the voresource.loadlist.cone and voresource.loadlist.siap messages - and each message would trigger a different functionality on receipt.


Your thoughts?

cheers
noel