NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Jon, all, I guess "baptizing" something with a specific MIME is mainly a matter of convenience (in case of MS Word, maybe even of a touch of marketing: in fact .docx is still binary, actually a zip archive). I argue that the change from netCDF3 to 4 is quite radical, from the application/user point of view, as it impacts on what libraries/tools one should use, so I wouldn't object to having this captured in the mime. But I agree that a single mime for netCDF is more elegant and applications can live with it. However, I maintain that having the version information, as well as the conventions in use, in (optional) parameters is a useful and inexpensive mechanism for facilitating data interchange on the web, especially when we generalize the assumption that everybody will use the same libraries for netCDF handling. I see benefits from this in service composition scenarios, the Model Web, distributed processing, Linked Data approaches, etc. The whole thing is reminiscent of the rationale behind the optional "charset" parameter for the XML mime type (see http://tools.ietf.org/html/rfc3023#section-3.2, pg. 9) A specific application may always add its own parameters to the netCDF mime, but of course agreeing on standard names and semantics is always good :-) L Il giorno 20/ott/2011, alle ore 21:29, Jon Blower ha scritto: > Hi, > > I tend to think that a single MIME type for NetCDF would be appropriate. In > practice there tends to be a 1:1 mapping of file extension to MIME type. > There’s no theoretical reason why this should be the case, but it’s common > practice in web server configuration to associate a file extension with a > single MIME type. > > All Microsoft Word documents (.doc) pre-2007 share the same MIME type, even > though older versions of Word won’t correctly read a .doc from later > versions. The change to .docx generated a new MIME type, but this was a > radical format change from binary to XML – the change from NetCDF3 to NetCDF4 > is not so radical I think and maybe should not spawn a new extension or MIME > type. > > However I can see the contrary point of view – lots of people at the moment > only have NetCDF-3 aware tools as they wait for upstream software vendors to > upgrade. These people might want to distinguish between versions (and > probably don’t want to download a large file only to find they can’t read > it). But surely this problem will go away in a couple of years. > > I think the simplest solution (single extension, single MIME type) is > probably best, unless there are compelling use cases to make things more > complicated. > > HTH, > Jon > > > From: galeon-bounces@xxxxxxxxxxxxxxxx > [mailto:galeon-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ben Domenico > Sent: 20 October 2011 15:57 > To: Little, Chris > Cc: Simon Elliott; galeon@xxxxxxxxxxxxxxxx; > CF-NetCDF-1.0.SWG@xxxxxxxxxxxxxxxxxxxxxxxx; Ross, Gil; Tandy, Jeremy > Subject: Re: [galeon] [CF-NetCDF-1.0.swg] CF-netCDF SWG Session Summary:Sept > 2011 TC Meeting > > Hi all, > > Can someone describe a scenario where having the version information (e.g., > netcdf3 or netcdf4) somewhere in the mime type would make a difference for a > client? If one is using the latest netCDF libraries, they should be able to > deal with either. If one has an older client using an older version of the > library, then presumably the client application would not be aware of > mime-types and would not know what netcdf4 means anysay. If the client is > doing a protocol negotiation, e.g., WCS, it would seem that the > describeCoverage interaction would be where the netcdf3 - netcdf4 distinction > would be important so the client would know whether it really wants to do the > getCoverage at all. > > I'm struggling a bit to visualize a use case where the client would make use > of the version information in the mime-type. > > -- Ben > > On Thu, Oct 20, 2011 at 7:32 AM, Little, Chris > <chris.little@xxxxxxxxxxxxxxxx> wrote: > Dear Ben, Dominic, > > There was a similar discussion in the WMO format group (IPET-DRC) with Simon > Elliott, EUMETSAT, concerning the WMO file naming convention. > > We took the approach that the format should be specified as just NetCDF > (actually 'nc') rather than nc3 or nc4; GRIB (grb) rather than grb1 or grb2; > BUFR (bfr) rather than bfr1,2,3,4.... > > The argument was that current (monolithic) applications 'know' what version > of a format they support and can behave appropriately. > > The suggestion for separate Mime types, rather than a single parameterised > type, makes sense when the majority of applications are Mime aware and are > programmed to do the correct negotiation at the HTTP level, rather than > within their application environment. > > HTH, Chris > > Chris Little > OGC Meteorology & Oceanography Domain Working Group > > International Telecoms & Projects > Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom > Tel: +44(0)1392 886278 Fax: +44(0)1392 885681 Mobile: +44(0)7753 880514 > E-mail: chris.little@xxxxxxxxxxxxxxxx http://www.metoffice.gov.uk > > > -----Original Message----- > From: > cf-netcdf-1.0.swg-bounces+chris.little=metoffice.gov.uk@xxxxxxxxxxxxxxxxxxxxxxxx > > [mailto:cf-netcdf-1.0.swg-bounces+chris.little=metoffice.gov.uk@xxxxxxxxxxxxxxxxxxxxxxxx] > On Behalf Of Dominic Lowe > Sent: 14 October 2011 09:55 > To: galeon@xxxxxxxxxxxxxxxx; CF-NetCDF-1.0.SWG@xxxxxxxxxxxxxxxxxxxxxxxx > Subject: Re: [CF-NetCDF-1.0.swg] [galeon] CF-netCDF SWG Session Summary:Sept > 2011 TC Meeting > > > > 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-. > > 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). > > 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? > > Regards, > > Dom > > > > > -- > Scanned by iCritical. > _______________________________________________ > CF-NetCDF-1.0.swg mailing list > CF-NetCDF-1.0.swg@xxxxxxxxxxxxxxxxxxxxxxxx > https://lists.opengeospatial.org/mailman/listinfo/cf-netcdf-1.0.swg > > _______________________________________________ > galeon mailing list > galeon@xxxxxxxxxxxxxxxx > For list information, to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > > _______________________________________________ > galeon mailing list > galeon@xxxxxxxxxxxxxxxx > For list information, to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/
galeon archives: