NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi all, This is an interesting and valuable discussion. My suggestion is to go with cf-netcdf. NetCDF 3 is netCDF in the classic sense so let's just treat it that way. And it is really the combination of CF conventions in netCDF form that we are talking about. GALEON has shown that's what client applications are able to deal with, so let's use that for the MIME type. By using the dash between "cf" and "netcdf" instead of the plus sign, we avoid the issue (noted by Dominic) that CF is not really a media format. In the future, when we move on to doing this for netCDF 4, we will have the issue of the whether the file format is netCDF4 or HDF5, so I suggest we just leave it at CF-netCDF for now and make it clear with a parameter (version = 3 and is the default). I agree with Eiji that we should make the CF community aware of the fact that we are considering this. They may already have thought it through and have some additional thoughts on the matter. Eije, are you on the CF list? You seem to have the most experience with MIME types and you made the suggestion to bring them into the conversation. Would you like to broach the subject on the CF email list? -- Ben On Mon, Jul 14, 2008 at 3:12 AM, Dominic Lowe <d.lowe@xxxxxxxx> wrote:
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.1 However 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: