Here is a list of the things I brought back that are relevant to my stuff:


Treeview
--------

Treeview as (primary)? viewer of MySpace.
Paul Harrison said he thought this was a good idea (so did CliveD)
and there was a comment in Nic Walton's talk which sounded like
he was thinking along these lines too. From what I can see it
would work pretty well, and of course makes SPLAT/TOPCAT/SoG the
natural viewers for items that exist within MySpace.
Paul says he will contact me when there is a working MySpace test
environment so I can have a go at it.

Treeview as viewer for the registry.
This sounds like it could be rather a good idea too, though I really
haven't looked at the registry stuff at all, so I've only got a pretty
dim idea of how it might work/what it might do.

Treeview as viewer for other web services, e.g. the SDSS skyserver ones.

A couple of people wanted to be able to use a Treeview-like component
in their GUIs (adding new node types). It is designed to allow this
sort of thing (it's not hard to do, though there are some subtleties),
but there isn't currently a user document addressing this, probably
there should be. Come to think of it a proper user guide wouldn't
go amiss either.


TOPCAT
------

Enhanced capabilities for user-extensible processing - allow users to
add own toolkits, enhance the complexity of expressions for adding
new columns (e.g. FFTs) etc. Maybe even access web services which
can do complex statistical processing? Some of this is reasonably
easy, some hard.

Add cross-match functionality.

Enhancement to allow processing of large files (larger than memory)
(can do this currently with FITS files on disk, but not, e.g. VOTables).
Probably quite easy (by writing to local files).

TOPCAT as applet?

Some people wanted to use TOPCAT as an embedded viewer for tables/VOTables
in their GUIs. Others just wanted to use it freestanding. There was
quite a bit of interest in it.



Tables infrastructure
---------------------

More file format readers required, in particular for various plain text
formats (including CSV). This would provide the easiest-to-use possibility
for people who want to turn their plain text tables (and possibly
Excel databases etc, in the case of CSV) into VOTables, which a lot
of people seem to want to do. It can turn them into FITS tables
etc as well, but that's less relevant to IVOA and probably affects
less people. I've written a quickie text-format reader (though not
CSV) today, seems to work OK, but it certainly won't fit everybody's
text-format files (which would be, essentially, an artificial
intelligence type problem).


VOTable library
---------------

My VOTable reading library appears to the the only one out there which
can read non-TABLEDATA-type VOTables, that is ones in which the
cell data themselves are encoded in a <FITS> or <BINARY> element.
I have resisted pushing this library for public use up till now for
the following reasons:

   - BINARY support is untested, probably broken
   - A few things in the API are a bit messy
   - The implementation is DOM-based, so it's not suitable for very
     large tables. The interface is completely DOM/SAX neutral
     (uses Sources), but getting it to actually use SAX would require
     a certain amount of work.
   - Laziness - if other people are using it I have less leeway in
     mucking about with it

I did put some work into making it a standalone component however, and
it is extractable into a reasonably small self-contained jar file.

It is probably the most full-featured VOTable access library out
there, so it might make sense to try to polish it up and encourage
other people to use it. However, nobody at ADASS seemed to be falling
over themselves to ask me about it, and I suspect this is more to do with
the fact that the ones they are using suit their needs than because of
any problems with mine (e.g. nobody at all is actually using
FITS/BINARY-type VOTables, or seems to want to do so, though surely
when they come to looking at proper-sized tables they'll have to
change their minds??). So I don't know whether it's worth the effort.

Additionally, a number of ideas of varying degrees of stupidness were
advanced at the interop meeting VOTable session for enhancements
to the standard - attempting to support these might add significantly
to the maintenance burden for a VOTable library which attempted to
provide full functionality.


Mark

--
Mark Taylor Starlink Programmer Physics, Bristol University, UK
[log in to unmask] 0117 928 8776 http://www.star.bris.ac.uk/~mbt/