illegal/unrecommended use of IVOA identifiers

[Doug Tody]

Hi All -

In thinking about where this sort of inter-tool messaging might go in
the future, it might be useful to look into the past, for example the
messages which have been defined for the ds9 image display client (which
uses XPA as the underlying messaging transport).  See for example

     http://hea-www.harvard.edu/RD/ds9/ref/xpa.html

One might conclude that messages of this sort can be viewed as a
language, defined separately for each type of tool, based on the types
of data and operations it deals with.  When a language becomes rich
enough one would probably prefer to register the namespace or schema
for the language, not the individual elements of the language itself.

 	- Doug


On Fri, 17 Nov 2006, Roy Williams wrote:

> John
>
> Following your logic, this means that VOEvents can also be registered 
> individually, rather than registering the server that handles them, as Ray 
> suggests. I understand that LSST will be putting out thousands of event 
> notices every night. Do you think the VO registry system will be able to 
> handle the load?
>
> Another problem is inflexibility. Suppose a group wishes to experiment with 
> their own dialect of messages, and they want to change rapidly, adding and 
> deleting. In the official (Ray) scheme, they would have a standalone message 
> registry that may or may not be registered with the VO registry. In your 
> scheme, each message is added and deleted from the entire global VO registry.
>
> Of course it is much more convenient to have "everything in the registry", it 
> is a one-stop shop instead of a two-stage process. But perhaps not always the 
> best solution.......
>
> Roy
>
>
>
> John Taylor wrote
>>  a search of the registry reveals the ivo://..../loadVOTable message
>> 
>> Ray Plante wrote:
>>>  Instead, I would recommend the approach that is to be used by the VOSpace 
>>> standard in which names are identified using a # suffix; e.g.,
>>>
>>>    ivo://votech.org/plastic#info/getIVORN
>> 
>