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, UKReceived on 2006-09-14Z15:03:57