Error column in VOResource->DM-Quantity <=> VOTable-PARAM

[Martin Hill]

Pierre Didelon wrote:

>> The 'existing standard' is an illusion: there are no existing tools 
> 
> I think that there is a small mis understanding here.
> I spoke of tools in the sens of endusers tools like VOPlot, TopCat,
> Specview... and it seems (to me) that you are thinking of programming
> tools useful for software ingeneers (like us).

Aha! Here is the illusion in practice I think.  These tools exist to do 
particular things with VOTable; as you say none of these are appropriate 
to using VOTable for this de/serialising task.  So the fact that we have 
a 'standard' way of representing table data to, eg, viewing tools is 
irrelevent  to having a 'standard' way of representing object models in 
general.  It's not actually the same standard - we can't use 
VOTable/objectmodel in tools that expect VOTable/tables... or indeed 
VOTable/SIA... We end up with a set of *different* standards of 
VOTable/somethings all based on VOTable form, all preventing us from 
using the full power of XML.

>> that can marshall/unmarshall (read: de/serialise) a VOTable to an 
>> object model.  
> 
> Isn't/can't STIL of starlink/uk a tentative of this kind of tool?

This I wasn't aware of.  Can it take any object model and de/serialise 
to VOtable?  I was under the impression you were describing a new 
possible way of de/serialising object models <-> VOTable below:


>>> Concerning Quantity it is eveident that PARAM tag in VOTable can be 
>>> seen as
>>> a possible serialisation of basicQuantity (atomic quantity with one 
>>> value),
>>> with one PARAM in a VOTable even VOTable can be used as one possible 
>>> serialisation of it,
>>> I am not arguing that it must be the realisation of it ( ;-) martin ).
>>> Admitting that, FIELD tag and corresponding column in TABLEDATA can 
>>> be seen as vectors,
>>> GROUP allow to associate them, TABLE can be used to serialised matrices,
>>> and RESOURCE/VOTable as generic serialisation for N-Cubes.
>>> It is a perhaps a too generic serialisation which do not force semantic
>>> to be included always in the same way, but at least it gives a way of 
>>> serialisation
>>> which would works with an already existing VO standard...


> 
>> So we would have to build a new standard onto VOTable to represent 
>> object models, new tools, etc, whereas there are several existing 
>> tools (eg castor) that will do this already straight to XML.
> 
> Can't castor with an xsd file handle properly VOTable?
> At least the metadata (header) part of it?

Sorry I was thinking of serialisation here rather than metadata 
modelling (which is why I shifted this to DM).

I'm not sure if it's (practically) possible to use XSD to transform 
VOTable/somethings to more general forms because of the break between 
the header and the data.  It might be possible when just dealing with 
the metadata.

But again I don't see the point; if we have a general form, why spend 
extra effort writing (difficult) XSDs to transform VOTable/objectmodel 
when we're going to have to write special tools to handle the 
VOTable/objectmodel form anyway?  We can standardise on the general 
form, save a lot of work, and go on a long holiday to Timbuctou.

Cheers!

MC

-- 
Martin Hill
www.mchill.net
07901 55 24 66