On Tue, May 28, 2013 at 1:13 PM, Ben Reser <b...@reser.org> wrote: > On Tue, May 28, 2013 at 12:56 AM, Greg Stein <gst...@gmail.com> wrote: >> Hmm. Why would the media-type vary based on ${project} ? >> >> It seems like all you would need is application/vnd.apache.pubsub.json >> >> Is there a reason for something more than that? > > The vendor tree media-types are somewhat undefined as far as how > people use them.
Well aware, from my work on httpd... > Originally we were thinking vnd.subversion but if > you look at the existing registrations you'll see the Vendor name is > registered first, so I thought it should be vnd.apache. We wanted to > avoid polluting a namespace that is ASF wide with things that are > specific to a project. So we came up with two formats, that I You guys are over-thinking it. Simply state this format is ASF-wide and be done with it. Media types are not born every month. More like one every few years. I'm even gonna guess most aren't registered with the IANA (tho I suggest we register ours). > mentioned in my first email. > > vnd.apache-${project}.${format} > and > vnd.apache.${format} > > The latter format would be used in the case of cross project > standards. E.G. say two projects collaborated on a format. However, > if a project independently made their own format they'd put it under > their project name to avoid a conflict. Your counter suggestion of > application/vnd.apache.pubsub.json is ambiguous as to what the pubsub So? That's what the registered definition is for: to explain the media type. Are these obvious? application/vnd.svn-svndiff application/vnd.svn-skel Not really. But we just started using them. Again, you're overthinking things :-) ... just go with something simple. > is used for, pubsub is a fairly generic concept so if several projects > wanted to come up with a generic pubsub format then that name would > already be used for our very specific version control format. > > You could resolve that issue by using > application/vnd.apache.svnpubsub.json. However, while we consider the > Apache Subversion project as the vendor, I've done a fair amount of > work to generalize the format so that it can be used by the git folks > (there is a gitpubsub but I don't think they're using this format at > current, partly because their work predated the work I undertook to > generalize our format). So using svnpubsub signals that the format is > Subversion specific when it really isn't. > > We used the +json rather than .json since that seems to be consistent > with what people have been doing with XML and JSON based formats. Yeah, sorry, I meant to type +json, much like application/$FOO+xml, and several existing +json types. Anyway, you suggested: application/vnd.apache-subversion.pubsub-stream+json and I suggested: application/vnd.apache.pubsub+json cuz we don't need the -subversion in there. And the -stream will be inherent in the format. As you state: it is also generic, so no need for svnpubsub or whatever. (and we also don't need/want a media type that is freakishly long) For existing "conventions" (for whatever that's worth): http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types I'll note that a vnd.apache does not exist. So it's empirically true that per-project naming for conflict resolution isn't worthwhile. > If you want there was quite a bit of discussion between Daniel and > myself (with some input from Branko) on IRC last night leading up to > my email. You can see our full linke of thinking from that. *shrug* ... you posted the summary to the list. Frankly, I'm only concerned where you ended up rather than how you got there :-) Cheers, -g