new MType proposals.

[Mark Taylor]

On Wed, 8 Apr 2009, Noel Winstanley wrote:

> 
> On 8 Apr 2009, at 11:15, Mark Taylor wrote:
> 
> > On Tue, 31 Mar 2009, Noel Winstanley wrote:
> > > 
> > > 2 Exchange a set of VOResources
> > > (http://www.ivoa.net/Documents/latest/VOResource.html)
> > > MType:
> > > 	voresource.loadlist
> > > Parameters:
> > > 	name: (optional) name for this set of resources
> > > 	ids: (required) map of IVOID -> (optional) URL
> > > 		The keys of this map are the IVO-identifiers of the
> > > voresources to load. The optional value associated with each key is an URL
> > > from which the XML of the voresource can be downloaded.
> > > 
> > > Return Values:
> > > 	none
> > > 
> > > The URL values in the ids map are optional and need not be provided, but
> > > may
> > > be useful for a receiving application which isn't able to query a registry
> > > service. (e.g. because it doesn't bundle the whole SOAP stack required to
> > > do
> > > this)
> > 
> > I wonder whether this ought to be decomposed into two MTypes,
> > one in which the URLs are present and one in which they are not.
> > The reason is that an application which can't do IVOID->resource-info
> > mapping (e.g. no SOAP, no registry access) probably won't be able
> > to do much with a list of IVOIDs (will it?).  So such a client would
> > want to subscribe to receive messages that come with the URLs but not
> > ones that don't.  An application which can do IVOID->resource-info
> > mapping would be able to use either form.  An alternative would be
> > to have only one MType as above, but make the URLs mandatory.
> > 
> 
> I didn't want to make the URLs mandatory, as it's maybe a bit too onerous for
> some applications (you need to setup an internal webserver to do this at the
> moment, as resources are only SOAP-accessible).
> 
> Is there some suitable language between mandatory and optional? - recommended,
> preferred?

Not sure that would help - a receiver wants to know either it will 
contain URLs or it might; relative probabilities aren't that much use.

> I was less keen to have two mtypes, as the messages have the same semantics
> and intention.
> However, is it possible to do something with MType subtyping? My understanding
> of the spec at this point is a bit shakey, but can't a client subscribe to a
> MType, and it will receive all subtypes of that MType too?
> 
> So would defining the following MTypes work?
> voresource.loadlist : same as described above
> voresource.loadlist.annotated - same structure, but resource URLs are
> mandatory.
> 
> A client that didn't require the resource URLs could subscribe to
> 'voresource.loadlist', and would receive both kinds of mesage, while a client
> that required the resources would subscribe only to the subtype.
> 
> Does a subscription to 'voresource.loadlist' automatically match subtypes, or
> does an explicit wildcard need to be used (in whichcase, this could be a bit
> of a gotcha)

no automatic matching of subtypes, you'd have to subscribe to both.

> > I'm not much involved with applications which send or receive this
> > kind of message, so I may have misconceptions about how it would be
> > used; more weight is due to the opinions of those (like Noel) who are
> > likely to use it.
> > 
> 
> One of the use cases I had in mind was sending a set of resources off to an
> external tool (such as Norman's SKUA)  that uses some kind of deduction /
> ontological reasoning / magic to suggest related resources, which are then
> messaged back to voexplorer.
> 
> In this case, when voexplorer hands off the set of resources, the resource
> URLs might be useful if the external tool wants to crawl the XML to extract
> search terms, or whatever it uses as input to the reasoner.
> 
> However, if the reasoner has previously digested a registry, it might not have
> access to the XML source of the suggestions it computes - and voexplorer
> wouldn't require the resource URLs anyhow. So it seemed convenient not to
> require these.

sounds fair enough.  Since you've given it consideration, I don't
object to you doing it like you said at first.

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