NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hello Ben, Firstly, thank you very much for quoting. However, to be honest, I don't get the point because of ambiguity: Are the MIME parameters used for data format? Or MIME parameters indicate the same thing what KVP is used for? Either makes sense but I don't think "it is how most of the web negotiates formats". In HTTP a client indicates a list of acceptable media types, and the server choses the best one according to priority (q parameter) given by the client. For example, a HTTP request shown below means "The best is HTML or XHTML, XML is fine. Give me anything if nothing above is available." GET /path/progname.cgi?key=value&key2=value2 HTTP/1.1 Host: server.domain Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 That is negotiation. Anyway, it is very good to know the proposal doesn't care whether the MIME type is a registered with IANA. Why don't we start with something like application/x-cf-netcdf or parameterized counterpart? On Thu, Jul 17, 2008 at 12:11 AM, Ben Domenico <Ben@xxxxxxxxxxxxxxxx> wrote:
Hi GALEON collaborators, The note I sent out earlier about parametrized MIME types for CF-netCDF was prompted by a suggestion in the WCS working group. Since not all of you are involved in those discussions, I'm quoting the specific suggestion below for using such MIME types as "identifiers" for WCS encoding extensions. I hope this background information will provide some context for the GALEON discussion of MIME types for CF-netCDF. Please note that the quote below is just a suggestion. By no means has it been adopted for WCS, but it was put forth as a possible solution to a key issue related to defining WCS standard extensions for encoding formats. On the other hand, it serves as a good reminder that the question of MIME types may be generally important in the CF-netCDF realm -- not just in the WCS context. -- Ben ================================================================================= 1. Use Parameterized MIME Types to transmit format request options (parameter values). It is flexible, it is simple, and it is how most of the web negotiates formats. That last one is what clinches it for me because it works! 2. To have Encoding Extensions that: Describe how a WCS GetCoverage response is mapped to a specific format. I would even say that an extension could even map to two or more formats: for example GIF with GML based georeferencing. To me that is essentially devising a new format. Provide a unique encoding extension "identifier" : The "identifier" must be a MIME type. Whether the MIME type is a registered with IANA doesn't matter. Where possible it may make sense to use a registered mime type with a parameter name and value that uniquely identifies the extension. An un-parameterized MIME type means that all parameters use their default values. List additional the parameters available, their possible values, and their defaults. There is no theoretical limit on the number of mime type parameters but there is likely a practical limit. Keep the list short to start - others can extend the extension if they need more parameters. As stated above the parameters should be encoded as MIME parameters. However, extension writers are free to add parameters as KVPs or extend the XML request. In reality whether parameterize MIME types or something else is used doesn't matter because, when a client recognizes an encoding extension identifier (mime type) the client automatically knows how to encode the extension parameters. Extension writers can even mix and match KVPs and MIME parameters. When no WCS encoding extension exists for a given mime type then the resulting file depends entirely upon the server implementation.
galeon archives: