NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi all, see my comments inline. Il giorno 14/ott/2011, alle ore 10:55, Dominic Lowe ha scritto: > Hi all, > > On 13/10/11 18:06, jgallagher@xxxxxxxxxxx wrote: >> +1 for x-netcdf with an optional conventions attribute > > Just to note that the x- prefix is for mimetypes that are not registered with > IANA. So if we are talking about what to register we should be talking about > application/netcdf or application/netcdf-3 (or 4) without the x-. yes, the x- branch would be a temporary solution, whilst waiting for the formal registration approval. Actually, the recent MIME RFC's introduced a "dotted" syntax equivalent to the "dashed" one, so we may also use "application/x.netcdf" (or both.) Besides, afaik, the "x-/x." branch has been deprecated altogether, in favor of the "prs." branch (aka "vanity branch"), supposedly with much easier registration procedures and governance. I have not had time to look at that, but, in case, "application/prs.netcdf" would be our (temporary) option. > My preference would be to make a distinction between NetCDF3 and NetCDF4 > filetypes as they require different tools to read them (or at least the tools > must be linked to different libraries). > Some clients might wish to express a preference in the HTTP Accept header > about which format they get back for a particular resource (if there is an > option). Agree, I would propose registering: application/netcdf application/netcdf-3 (alias of the above) application/netcdf-4 > You could extend this argument to the conventions but that might be getting > impractical - I agree with the use of optional parameters there, although not > sure how much they are used in practice for mime-type negotiation? UncertWeb would surely leverage the optional parameter for dynamic process composition. It's useful to know what conventions a dataset is compliant to, to route it to the appropriate processing service. We can of course open the dataset and inspect the Conventions attribute (that's what we are doing now), but having a MIME parameter would make things easier. I can think of a number of other use-cases, e.g. in data discovery, where a catalog may exploit that information to refine queries, etc. In general, imho, the more information is more easily available, the better (the parameter would be optional, anyway). Regards, Lorenzo > Regards, > > Dom > > > _______________________________________________ > galeon mailing list > galeon@xxxxxxxxxxxxxxxx > For list information, to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
galeon archives: