Spectrum data model
norman at astro.gla.ac.uk
Thu Sep 14 05:59:10 PDT 2006
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
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
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
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 Gray / http://nxg.me.uk
eurovotech.org / University of Leicester, UK
More information about the dm