On Tue, May 28, 2013 at 1:13 PM, Ben Reser <ben_at_reser.org> wrote:
> On Tue, May 28, 2013 at 12:56 AM, Greg Stein <gstein_at_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
Received on 2013-05-28 20:16:20 CEST