NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Eizi and All, Comments inline: On Sunday 13 July 2008 03:19:31 Eizi TOYODA wrote:
Years ago, I was leading a project called Pandora in which MIME type parameter was extensively used to negotiate data types. My quick thoughts: * MIME type parameter sounds clean, but it's hard to implement MIME dispatcher using parameter. Most dispatcher (such as apache, MS Windows shell) just ignores MIME type parameter. So, different types (not parameter) need to be created if different handler applications are to be invoked. * I think netcdf files with different conventions are better handled with different applications if dispatcher-handler approach is used. i.e. Netcdf is too generic vehicle of data like XML. Rather, I suggest using XHTML's approach. RFC3236 decides to use "application/xhtml+xml" media type. Please read Appendix A of RFC3023 http://www.rfc-editor.org/rfc/rfc3023.txt.
Thanks, that was very informative.I think perhaps there is a subtle difference in the CF case in that 'cf' in itself is not a media format. i.e. in the general case of "application/a+b" my reading of the document suggests that both a and b must be data/media formats. So while xhtml and xml are both formats in there own right, cf is not - it is merely a convention for writing NetCDF. There's no such thing as a CF file, only netCDF files. It is a blurry distinction as xhtml is just a way of writing xml, but there is such a tangible thing as an xhtml file (or a GML file...) whereas I don't think there is such a tangible thing as a CF file. There are no applications for reading CF files, only applications that read NetCDF and understand CF.
So my take on it is that application/cf+netcdf does not conceptually fit this pattern. My preference would be to have optional parameters that look something like this.
application/netcdf;version=3;convention=cf-1.1However your main point is that dispatchers may not be able to deal with this and so the pragmatic solution may indeed be application/cf+netcdf...
But, this could be with us for a long time, so if we are not sure at this point in time perhaps it is safest just to register application/netcdf ?
Does anyone know if it is necessary to register parameters? If it is do you just register the parameter names or names + values?
Finally, who is reading these parameters/profiles? One use case is the WCS client server negotiation. Are there any other use cases at the moment?
More questions than answers... :) Cheers,Dominic
galeon archives: