On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote:
> The key problem with "application/atom+xml;type=entry" is that at least
> one major browser (Firefox 2.0) still treats it as a feed and shows the
> "subscribe" link. So while the type parameter is a potentially more
> elegant solution, the new media type approach would likely be far less
> disruptive.
I don't understand the logic behind saying that it would be "far less
disruptive" to rely on the type parameter in lieu of creating new media
types. Personally, I think the type parameter is the solution to this
alleged "problem"... It appears to me that the disruption that would be
avoided by orphaning atom entries behind a "weird" new media-type is nothing
more than the effort of a minor update in a future revision of Firefox.
Prior to that update, behavior would be as it is today and frankly, that
isn't a really big problem since, as far as I can see, there haven't been
many reports of harm being caused by hordes of people accidently trying to
subscribe to atom entries.
The issues being discussed in this thread seem to be largely
hypothetical at best. Nobody has actually established that any harm is
currently being done as a result of the "ambiguity" of having both atom
document types share a single atom media type. The discussion would be a
great deal more engaging if someone could cite an actual history of issues.
Barring discovery of real, pressing problems, I think we should take the
more conservative approach of using the disambiguation tools provided by the
media-type specification -- i.e. use the type parameter. We've got more
important issues to focus on...
James suggests: "the type parameter is [a] potentially more elegant
solution." Elegance is goodness. Let's insist on elegant solutions in the
absence of compelling reasons to be inelegant.
bob wyman
