Spectrum data model

[Norman Gray]

Hello, Doug and Mark,

> On Wed, 13 Sep 2006, Mark Taylor wrote:

>> The reason is that there may be multiple different and incompatible
>> serializations which share the same Data Model and MIME type.

It might be worth pointing out, here, that MIME types (or rather the  
Content-Type headers in which they're used) admit of  
parameterisation.  Thus

     Content-Type: image/fits; serialization=http://www.ivoa.net/...

is syntactically acceptable.  No parameters are specified as required  
or optional by the FITS MIME-type RFC, but the MIME RFC requires that  
implementations ignore any parameters they do not recognise, so that  
the above Content-Type header would I think be irreproachable.  The  
data model of which this is the serialization would be specified  
elsewhere in the transaction, and in any case might well be implicit  
in the serialization, so that wouldn't have to be indicated here.   
It's arguably the wrong layer for that, anyway.


On 2006 Sep 13 , at 20.29, Doug Tody wrote:

> The intention was that for
> Spectrum only the documented serializations would be used, but I agree
> that we do not yet have a way yet to fully specify the serialization
> and that this would be a useful thing to add.

Probably the most web-friendly place to put this is, as you indicated  
in an earlier message, within the access/transport protocol --  
possibly as a parameterized MIME type.

If, however, the object being transported (FITS file or VOTable or  
XML) is seen as something that would be stored for a time, rather  
than being merely a rather high-level transport encoding, then the  
serialization would have to be indicated within the object as well.

Or would it?  A way round this is to avoid mandating any specific  
serialisation format (though have specific formats as `good practice'  
or strong suggestions), but instead make it rigourously required to  
associate utypes with the data in the serialisation, and expect the  
client to use these alone to reconstruct the original model instance.

That is, if I see

<PARAM name="Equinox"
     utype="spec:Spectrum.CoordSys.SpaceFrame.Equinox"
     ucd="time.equinox;pos.eq"
     datatype="float"
     value="2000.0" />

then I don't really have to have read Jonathan's section 8 to know  
that I'm going to have to put 2000.0 wherever  
spec:Spectrum.CoordSys.SpaceFrame.Equinox things usually go in the  
deserialised object.  As far as I can see, the same applies to  
everything else in Jonathan's example VOTable.

It would also be immediately true for FITS files, if the keyword- 
 >utype mapping of Jonathan's section 9.1 were included in a table  
within the FITS file, or referred to by some retrievable (and  
cacheable) URL.   Once the client has read that table, it has all the  
information it might need to reconstruct the original object, piece  
by piece.

This involves less standardisation cost, and it would be robust  
against both deliberate and accidental variations in the  
serialisation format.  It also opens the way for clients to glean  
information from a serialisation even if they don't (or don't need  
to) understand all of it.

All the best,

Norman


-- 
------------------------------------------------------------------------ 
----
Norman Gray  /  http://nxg.me.uk
eurovotech.org  /  University of Leicester, UK