Methods to serialise - Re: [QUANTITY] doc consistency

[Guy Rixon]

On Wed, 19 May 2004, Martin Hill wrote:

> This is all implementation stuff not part of our data modelling.  The
> bit that does the serialisation is likely to be very different across
> languages; for example a java one might not be a method on the object at
> all, but reflection-based inspection of the classes.  A FORTRAN one
> might be a procedure in a 'class'/module, but in general serialisation
> works better (long term) from code 'outside' the object.
>
> (BTW defining such methods binds our model to its representation which
> we ought to avoid - for example we would have to say that some objects
> take 'SQL statement' as a method, and some don't.  We also block anyone
> from adding their own serialisations without fiddling with the object
> model).
>
> Let's work out the data model, then work out how it might be
> represented.  The programmers who write the libraries (me! me!) are the
> right ones to do the bit inbetween.

Yes, I agree.  To me, that suggests that the model should consist only in
data, not in behaviour.  I.e., if we model using classes in UML, then we
should declare public data members and not methods.

> Having said that, it would be worth listing the forms we will expect to
> use to represent our data.  Presumably we start with:
>
>   * XML/VOTable/table (ie the table form of VOTable)

I.e. VOTable/TABLEDATA.

>   * XML/Marshallable (eg using Castor/Axis/WSDL2Java etc)
>   * FITS/table (with VOTable header?)
>
> I can't think how serialisation would work with SQL; it may be that bits
> of ADQL might be able to make use of it...

You can preserve the state of a database by storing a script that recreates
the DB in a new DBMS. The dump function in MySQL does this by writing an SQL
script. In that case, the script contains CREATE and UPDATE statements, one
UPDATE per row.


> Pierre Didelon wrote:
> > Hi,
> >
> > Pierre Didelon wrote:
> >
> >
> >> Another point concerning all the levels is related to serialisation.
> >> As you
> >> outlined it, it is  a very important point and I feel that a
> >> corresponding
> >> method would preferably included in the interface definition at each
> >> level.
> >>
> >
> > May I insists?
> > It would be nice to materialise the serialization possibility
> > of quantity by a method, appearing in clase Frame or BasicQuantity.
> > Moreover it would be nice if this "serialize" method could have a
> > calling param
> > to choose the output format, this one could perhaps be pure_xml, VOTable,
> > ASCII, Fits, SQL Statements... or whatever needed or required,
> > incrementally,
> > starting implementation of the most obvious one, which would be
> > the default format, if the required one by user is unavailable
> > Something like getSerialization(format: string): string
> >
> > regards,
> > pierre
> >
> >
>
>
> --
> Martin Hill
> www.mchill.net
> 07901 55 24 66
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523