Hi,
Most plastic messages defined so far define exchange data (images,
tables, positions).
i'd like to propose a new class of messages, for exchanging
_metadata_ about services, catalogues, and other stuff TBD.
Most things I'd like to exchange metadata about are described (or
describable) using a VOResource (an ivoa registry entry).
At first, I thought it'd be sufficient to define messages to exchange
a single VOResource or list of resources
as proposed at
http://wiki.eurovotech.org/twiki/bin/view/VOTech/
PlasticMessagesProposal#Registry_resource_related_messag
However, this is essentially untyped - with this message an
application will receive any kind of registry resource - whilst it
might only be interested in one particular kind of resource
For example, an image tool might be interested in resources that
describe siap services, and on receipt of a message show the user a
'perform siap query dialogue'. Another tool might only care to
receive metadata about tables.
For this to be useful, the image tool needs to provide further
information as to which kinds of metadata it can usefully consume.
At the votech meeting, we thought the simplest way to do this is to
define different plastic messages for each well-known/useful kind of
resource, figuring that most of the use cases & protoocols could be
covered with 5-10 new messages. However, we'd need to invent new
names for all these. In light of this, I'd like to propose the
following 'pattern' of plastic messages, which replaces my previous
proposal.
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'
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.
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.
so, comments?
cheers
noel.
|