Re: [Plastic-devs] messages for resources.

[Mark T. <m.b...@br...>]

On Thu, 15 Mar 2007, Noel Winstanley wrote:

> In the v1.0 registry schema, a resource document may describe
> multiple 'capabilities' . Each capability is described by a block of
> xml within the resource. The 'type' of the capability is defined
> using an attribute called 'standardID', which has  a schema-type of
> 'anyURI'
>
> Each IVOA standard defines a new standardID - for example, the ID for
> SIAP is 'ivo://ivoa.net/std/SIA'
>
> I propose that we could use these standardIDs within plastic message
> _names_ - but with a prefix that indicates that it's a kind of
> resource. So, an image viewer that likes to consume siap resources
> can tell the hub that it accepts the message 'resource:ivo://ivoa.net/
> std/SIA'

I think this is a good proposal.

> This saves us inventing new message names, handles versioning, and
> allows new tools, that support newly supported capabilities to
> advertise their ability in applications that know nothing about this
> new capabilitiy. Furthermore, the standardID is often registry-
> resolvable to an entry that provides further information on that
> standard - this could be used to dynamically create labels for
> buttons, etc.
>
> all such messages take the same parameters - a list of strings, where
> each string is a voresource xml document, where each resource has the
> capability defined by the standardID.

I don't understand this bit - doesn't each resource have one registry
entry, which would imply a single string parameter rather than a 
list of them?

> Although passing data in-message isn't perfect - it might be better
> to pass a list of resource-ids instead - this would require every
> client that accepted a resource-typed plastic message to be able to
> query a registry - which is awkward. As voresources are most often
> quite short, I don't think this should be too much of a problem.

As I said, I do have some reservations about this, since the 
registry entry could in principle be large and it requires the
client to parse XML and understand the relevant bit of registry schema.
Probably OK, but I don't have enough experience of working with
registry entries to have a feel for it.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/