+1 to "yeah, what Bob said". We'll still have to manage the transition around clients that don't send "type=entry" to GData services, but if we can point at an APP spec where this param is required on POST/PUT, it's possible to push through this.
-- Kyle On 12/14/06, Tim Bray <[EMAIL PROTECTED]> wrote:
Bob Wyman wrote: > There is, I think, a compromise position here which will avoid breaking > those existing implementations which follow the existing RFC's. <co-chair-mode>In case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say "yeah what Bob said" your co-chairs would probably do a hasty consensus grab.</co-chair-mode> -Tim > > 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get > them defined, registered, and "ready to use.") > 2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml" > 3) New specifications MAY require that ;type=entry be used. (Note: Just > because ;type=entry is used DOES NOT imply that ;type=feed must also be > used....) > > Thus, APP would accept application/atom+xml when looking for a feed but > might insist that entries be explicitly identified with a disambiguating > type parameter. Thus, no code which currently uses > "application/atom+xml" to designate a feed would be broken. > Additionally, any code which is "properly" built and thus ignores > unknown types will not be hurt when it sees > "application/atom+xml;type=entry" since it will ignore the type > parameter and dig around inside the data to figure out if it is feed or > entry. The only code which will be hurt is some potential code that does > not follow the existing RFCs for Atom or mime types. It is, I think, OK > to occasionally break code that doesn't follow the specs. > > Whatever the technical arguments may be, I believe it is important from > a "political" point of view that we do not change the definition of > things defined in Atom. I am all for extending Atom, but not for > changing Atom. We must not change the exiting specification unless there > is some really serious harm being done. If we do, we risk losing the > trust of at least some members of the community that we've built these > last few years... Folk will remember that one of the "advantages" that > is claimed for RSS is that it has been declared to be eternally free > from modification. While I personally believe that that is silly, the > proponents of RSS do have a point when they speak of the value of stable > specs. If we allow the Atom spec to be *changed* so soon after it was > accepted and we don't have a really, really good reason for doing it, we > will simply have proven the often made claim that standards groups > simply can't be trusted with important specifications. We will be > encouraging more of the kind of "standards making" that resulted in the > mess that is RSS... > > bob wyman > > PS: Since Kyle points out that GData, a Google product, is potentially > impacted by the results of this discussion, I should state that I > currently work for Google -- although I am not currently assigned to any > product or project that has a direct interest in the definition of Atom, > APP, etc... My participation in this discussion, at this time, is driven > purely by personal interest. >
