> Working backwards to build tools and transformations to interface
> between standard XML tools and VOTable is the wrong way around. We
> should be working with the standard XML tools to build a series of
> VOXmls that works with them directly. That means considering what we
> want to store - and not the structure that it happened to have been
> stored in before, but the structure of the information. For example, we
> need to think not in terms of 'a table', but 'a Stellar Catalogue'.
>
> The metadata section is more interesting and could be carried over to
> SoVOTable (Spawn of VOTable...), but we should also have a look at how
> this is starting to overlap with VOResource/VODescription. There are
> better ways of linking tagged values with extended information (eg,
> relating the tag <Magnitude>5</Magnitude> with other information, either
> inside the file or without, that describe passbands, zero points, etc),
> though I confess to not having written any myself.
I pretty much agree with all of that.
> Finally our replacement VOXmls should be able to handle a certain amount
> of data, but we should not not not be thinking of using XML as a
> standard for passing around arbitrary sizes of data results.
Yes, agreed. But being able to encapsulate a small amount of data into an XML document along with the meta-data is important, the "buy in" is much smaller that way for sending small amounts of data encapsulated in the document as a message between servcies (moderately common application I would have thought?).
> XML is a rich language for description and messaging. Lets use it for
> that.
Agreed, but ee my point above!
The other thing that starting to worry me is what we're going to do about spctral data and time series data in XML. Are we going to overload this into VOTable as well? If so we could start running into real architecture problems.
Al.
-- Dr. A. Allan, School of Physics, University of ExeterReceived on 2004-01-19Z16:09:40