Subject: Atom Entry docs

From: Tim Bray <[email-masked]>
Date: Tue, 12 Dec 2006 14:44:07 -0800

I seems obvious to me that Atom Feed and Entry docs are potentially 
quite different things which can be used for entirely different 
purposes.  The contention that an Entry doc is somehow really the same 
as a one-entry Feed doc is entirely unconvincing.

The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG 
finding on Authoritative Metadata 
(http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear 
that it's advantageous to use HTTP headers to distinguish between 
different kinds of representations.

So I guess I'm in favor of us writing something down to address this 
problem.

RFC4287 is now pretty widely implemented, so there is a distinct cost to 
screwing around with the well-known application/atom+xml.  On the other 
hand, my perception is that virtually all software that knows about 4287 
knows about feeds, rather than entries.  Thus, it seems to me that 
introducing a parameter so that existing software might see 
application/atom+xml;type=feed *might* break some software.  But 
introducing a new media-type application/atom-entry+xml which only goes 
with standalone feed documents is very unlikely to break anything.

So I'm for James' option B)
  application/atom-entry+xml

(James, did you really mean "atom.entry" with the ugly dot?)

  -Tim

---

From: James M Snell <[email-masked]>
Date: Tue, 12 Dec 2006 20:14:29 -0800

I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.

- James

Tim Bray wrote:
> [snip]

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 12 Dec 2006 23:57:28 -0500

Tim,

> different kinds of representations.

Ok, well, I've already voiced my disagreement that "entirely different
purposes" necessitates a new media type using HTML as an example.

I also disagree that the TAG finding has any relevance here, except
insofar as it says that a media type authoritatively determines
meaning by virtue of pointing at a spec ... but every option on the
table, including doing nothing, does that.

But so be it, I'm happy to move on ...

> application/atom+xml;type=feed *might* break some software.

Maybe, but I'd be surprised.  Though not, AFAIK, prescribed behaviour,
convention is that unknown extension parameters are ignored.

Implementors?

>  But

I think it would break servers.

Consider GData apps.  Their docs aren't clear (tsk, tsk!) about the
use of a media type when inserting entries[1], but if they're doing it
properly then their services should be keying off of
"application/atom+xml", and so will break if that's changed.

Other server implementations should have the same issue, of course.

>   application/atom-entry+xml

I'm -1 on that, but +1 on the type parameter.

Cheers,

 [1] http://code.google.com/apis/gdata/protocol.html#Inserting-a-new-entry

Mark.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 13 Dec 2006 07:47:33 +0000

> "application/atom+xml", and so will break if that's changed.

And? Should a status quo be better on the long term?

> Other server implementations should have the same issue, of course.

So please explain me what a server currently does upon receiving an Atom
feed on a POST to a collection that only (app:)accept (atom:)entry(ies)?

Returning a 415 error code seems like the wrong option since the
media-type is perfectly valid. So what should servers do? Should they
pick-up randomly one of the entries part of the feed? How should UA deal
with the returned message?

> I'm -1 on that, but +1 on the type parameter.

I'm still +1 on the new media-type and +0.5 on the parameter type option.

- Sylvain

---

From: Martin Duerst <[email-masked]>
Date: Wed, 13 Dec 2006 16:41:56 +0900

>however, appear to be more consistent with typical mime conventions.

The dot is used for prefixes like vnd. (vendor) and so on.
In the case of atom entries, atom-entry is more in line with
the convention in other types.

Regards,    Martin.

>> (James, did you really mean "atom.entry" with the ugly dot?)

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 13 Dec 2006 10:51:46 -0500

> And? Should a status quo be better on the long term?

I was just disagreeing with Tim's assertion that nothing will break.

> with the returned message?

AIUI, that's undefined, and will remain so no matter what is decided
here.  I don't understand what that has to do with a new media type
breaking existing servers though.

Of course, APP isn't finished yet, and so technically we shouldn't be
worrying about breaking implementations that "jumped the gun".  But
given that an alternative exists which shouldn't break those servers,
why not use it when there's no apparent downside?

Mark.

---

From: "Kyle Marvin" <[email-masked]>
Date: Wed, 13 Dec 2006 09:51:43 -0600

> And? Should a status quo be better on the long term?

Hi Sylvain,

Speaking as an implementer, we've shown ourselves quite willing to change
the GData implementation to track the APP draft as it has evolved.   The
above response didn't come from me, and if you check the history of my
messages on the Atom lists I think you'll find I've generally only cited the
current GData implementation to inform the discussion, not to constrain
it.   It's important to Google that the right things be done for the long
haul, too.

This being said, Mark was responding to Tim's message that just changing the
content-type for Atom entries was less likely to break existing
implementations.  What he is saying is correct and this will break our
existing implementation (and any other current server impl that validates
Content-type headers).   More details below.

> feed on a POST to a collection that only (app:)accept (atom:)entry(ies)?

The GData server implementation requires a Content-Type value of
"application/atom+xml" when POSTing or PUTting an Atom entry to a collection
(for all non-media collections).   It will respond with a 400 (Bad Request)
http error on any other content type.   It will also do the same if the
request body contains an Atom feed document and not an Atom entry document.

So without modification, the server would reject entries that use
"application/atom.entry+xml".    Even with modification, it likely still
would need to accept requests that contain "application/atom+xml" due to
propagation delays in clients conforming to whatever new convention is
established.   This would be contrary to the cited TAG finding [1], because
such a server would no longer be considering the Content-Type header to be
authoritative and would be peeking past it to the posted document.   This
seems bad.   Having an ambiguous common base type ("application/atom+xml")
and a more specific qualified type syntax ("application/atom+xml,
type="entry|feed") avoid this ugliness and the Content-Type remains
authoritative whether using the old or new syntax.

> I'm still +1 on the new media-type and +0.5 on the parameter type option.

It feels like we're just trying to avoid the pain of UAs having to learn
about and use content-type qualifying attributes (like "type").   But as I
noted in my previous message [2], I see this as inevitable if you think Atom
is going to be extended in ways that might need to be UA visible, so all
we're doing is delaying that pain (and letting more UA infrastructure be
built up that will feel it) rather than setting ourselves on what I see as
the right path for long-term growth.    Using attributes enables evolution
in directions that are not strictly hierarchical in nature, whereas
continuing to evolve using only the base type/subtype does not.

For that reason (mostly), I'm +1 on using "type" and -0.5 on using a new
MIME type.

Cheers!

-- Kyle

[1] - http://www.w3.org/2001/tag/doc/mime-respect.html
[1] - http://www.imc.org/atom-syntax/mail-archive/msg19384.html

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Dec 2006 08:00:31 -0800

>the convention in other types.

+1

---

From: James M Snell <[email-masked]>
Date: Wed, 13 Dec 2006 08:33:56 -0800

Very helpful. Thank you.

- James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 13 Dec 2006 17:31:05 +0000

Hi Kyle,

> it.   It's important to Google that the right things be done for the long

Agreed.

> implementations.  

Funnily my comment was solely directed at Mark based on his own comment.
I'm sorry if  things weren't clear enough. I didn't mean more than "what
do you mean Mark?".

> request body contains an Atom feed document and not an Atom entry document.

Right and I find that abusive of the mime type already. An UA that
respects RFC 4287 and sends a feed to a collection that would state it
accepts such media-type would not understand why it gets a 400 Bad
Request (it's fairly interesting to point actually that because of that
umbrella mime type you could not use the proper 415).

> authoritative whether using the old or new syntax.

Agreed.

> For that reason (mostly), I'm +1 on using "type" and -0.5 on using a new

You make a good case regarding the evolution being less hierarchical.
The only thing I'd be afraid of however is that we try to put too much
semantic in the mime-type if we use the type parameter.

Thanks for your feedback.

- Sylvain

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 13 Dec 2006 17:34:11 +0000

> breaking existing servers though.

It has everything to do within the APP context in fact. We have only one
mime type for two distinct semantics (well you disagree on that
statement so I can understand why we disagree with the rest). Having a
new media-type (or at least the type parameter) would help APP server
implementors. Therefore the way servers would handle requests.

> why not use it when there's no apparent downside?

We still disagree on this alternative you suggest I'm afraid.

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Wed, 13 Dec 2006 09:58:02 -0800

> umbrella mime type you could not use the proper 415).

Which is precisely why <accept>entry</accept> exists.  Existing
implementations already have to basically ignore the content-type and
sniff the content.  Implementations will have to continue to do so with
the optional type param because it's optional.

- James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 13 Dec 2006 18:07:49 +0000

> the optional type param because it's optional.

True but I've always found the "entry" awkward.

- Sylvain

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 13 Dec 2006 23:23:16 -0500

There is, I think, a compromise position here which will avoid breaking
those existing implementations which follow the existing RFC's.

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.

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 14 Dec 2006 01:44:58 -0500

> those existing implementations which follow the existing RFC's.

That's what I thought the type parameter option was, so sure, +1 on that too 8-)

Mark.

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 14 Dec 2006 08:36:34 +0100

> those existing implementations which follow the existing RFC's.

It was exactly the point behind my proposal for this 'type' parameter.

-- 
Thomas Broyer

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 14 Dec 2006 11:04:00 +0200

> why not use it when there's no apparent downside?

The downside is that implementations that (quite reasonably) assume  
that application/atom+xml == feed are also reasonable when they  
ignore unknown media type parameters.

Given the options of a new type or a new parameter, I am +1 on the  
new type. (Although in general, I don't like the proliferation of  
application/*+xml types, because apps need to do root sniffing for  
application/xml anyway.)

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Rogers Cadenhead <[email-masked]>
Date: Thu, 14 Dec 2006 07:08:32 -0800 (PST)

> because ;type=entry is used DOES NOT imply that

+1 on this approach. RFC4287 is a powerful argument in
Atom's favor. Chip away at that spec and we're going
to start hearing from Mr. Safe again.

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 14 Dec 2006 10:59:07 -0500

> ignore unknown media type parameters.

True, but I think it's quite reasonable to interpret that behaviour as a bug.

> application/*+xml types, because apps need to do root sniffing for

Let's not go there 8-)  See;

http://www.w3.org/2001/tag/doc/mime-respect.html#embedded

Mark.

---

From: Tim Bray <[email-masked]>
Date: Thu, 14 Dec 2006 09:00:17 -0800

> 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.")
> 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
> 
> 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.
>

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Thu, 14 Dec 2006 17:35:25 -0000 (GMT)

> your co-chairs would probably do a hasty consensus grab.</co-chair-mode>

Personally, I would say that if we find the proper way to notify
implementors they can't dismiss the type parameter then I'll +1 that
option over the new media type.

However we know that implementations won't make the effort to take it into
account then what's the point over the current status?

- Sylvain

---

From: "Kyle Marvin" <[email-masked]>
Date: Thu, 14 Dec 2006 11:41:38 -0600

+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

---

From: Ernest Prabhakar <[email-masked]>
Date: Thu, 14 Dec 2006 10:16:33 -0800

"yeah what Bob said"
I'm not sure it is ideal, but it seems the closest to consensus we're  
ever going to get.

+1

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Dec 2006 10:43:28 -0800

I've found the arguments in favor of the type param to be more
convincing than those in favor of the new media type...

...so +1 to what Bob said.

- James

Tim Bray 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.
> 
>> 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
>> 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
>>
>> 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.
>>
> 
>

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 14 Dec 2006 20:02:42 +0100

> your co-chairs would probably do a hasty consensus grab.</co-chair-mode>

Just in case: "yeah what Bob said" ;-)

-- 
Thomas Broyer

---

From: John Panzer <[email-masked]>
Date: Thu, 14 Dec 2006 11:28:04 -0800

Tim Bray wrote:
> 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>
>
hand up...

---

From: John Panzer <[email-masked]>
Date: Thu, 14 Dec 2006 11:30:36 -0800

> said" your co-chairs would probably do a hasty consensus 
<hands up>

---

From: Sam Ruby <[email-masked]>
Date: Thu, 14 Dec 2006 16:18:57 -0500

> your co-chairs would probably do a hasty consensus grab.</co-chair-mode>

+1 to "what Bob said"

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Fri, 15 Dec 2006 09:18:10 +1100

+1

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 15 Dec 2006 01:43:08 +0100

> your co-chairs would probably do a hasty consensus grab.</co-chair-mode>

*Hands up*

«What Bob said»

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: "A. Pagaltzis" <[email-masked]>
Date: Fri, 15 Dec 2006 13:43:58 +0100

* Bob Wyman <[email-masked]> [2006-12-14 05:45]:
> 1) Define ;type=feed and ;type=entry as optional parameters.
> (i.e. get them defined, registered, and "ready to use.")
> 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....)

+1

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: David Powell <[email-masked]>
Date: Fri, 15 Dec 2006 12:47:05 +0000

> ignore unknown media type parameters.

An example would be an HTML page with rel="alternative" links
pointing to a feed and an Atom Entry document.  This seems quite a
reasonable use-case, yet if we don't create a new MIME type, then I'd
expect that all current feed reader implementations would incorrectly
detect the entry document to be a feed, which would be very confusing
for the user if they select the entry document, and their feed reader
attempts to subscribe to the entry document.  Which would either work,
and they would get subscribed to a feed that doesn't update, or they'd
get an error.

> application/*+xml types, because apps need to do root sniffing for  

Another issue with MIME parameters is that the old MIME RFCs are
inconsistent about the definition of the term "media type", which can
mean top-level type, top-level/sub-type, or top-level/sub-type with
parameters. When Atom was being developed I asked (several times)
whether Atom documents are allowed to contain parameters in places
that they specify media types, and I got conflicting answers. My
perception is that MIME parameters just don't work very well.

Another case for a new type is browser dispatch.  Operating systems
tend not to use MIME types for deciding which application to use.
Whilst a feed reader is a sensible application to open a feed in; an
entry document should probably be opened in an editing/publishing
application.  This is not really possible if we use a MIME parameter
to distinguish the two document types.

-- 
Dave

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 15 Dec 2006 14:08:42 +0100

>> ;type=feed must also be used....)

Did anyone check how widely deployed the entry documents actually are? And  
how much support there is for them?

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: David Powell <[email-masked]>
Date: Fri, 15 Dec 2006 13:09:24 +0000

I've always interpreted a kind of inheritance relationship between
MIME types.

It's never wrong to label an Excel file, an XML document, or an Atom
Feed as application/octet-stream, because all of those types ARE
octet-streams.  It is just not as helpful as it could be.

Likewise, it is never wrong to label an Atom Feed, as application/xml.
It just isn't being optimally helpful.

I think that you have to interpret MIME types this way, otherwise a
generic XML processing application which labelled content as
application/xml would be standards compliant until the day that the
Atom RFC was published when it would become un-compliant overnight
without anyone touching the code. I don't think that that is the way
that standards are supposed to work.

So likewise, I see no harm in inventing application/atomentry+xml.
Sure, applications can still use application/atom+xml for entries,
they just aren't being as helpful as ones that use the more explicit
MIME type.

-- 
Dave

---

From: "Joe Gregorio" <[email-masked]>
Date: Fri, 15 Dec 2006 09:30:56 -0500

> your co-chairs would probably do a hasty consensus grab.</co-chair-mode>

+1 to what Bob said.

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: "Hugh Winkler" <[email-masked]>
Date: Fri, 15 Dec 2006 11:12:48 -0600

> I've always interpreted a kind of inheritance relationship between

It's telling that James felt it natural to choose the name "type" for
the parameter. Because it really is naming a new type of document.

In programming, whenever I find myself sticking a member named "type"
into some class definition, I usually have to admit that I'm hacking
in a new subclass definition and subverting the type system. That's
what defining the "type" parameter is doing.

Hugh

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 15 Dec 2006 14:16:14 -0500

> the parameter. Because it really is naming a new type of document.

What would be better than "type?" Might "root" work better?

It seems to me that "application/atom+xm;type=entry" describes "an Atom
document whose root element is `<entry/>'." The type of the document is
"atom" but it is a "kind" or "type" of atom document that has an <entry/>
element as it's root. Unfortunately, "type" is being used to mean two
completely different things in this context.

Would you be happier if the proposal was for the following?

    application/atom+xml;root=entry
    application/atom+xml;root=feed

One argument for using "root" is that it might be a usage that would be
useful with other mediatypes which have more than one possible root element.
Also, using "root" as the parameter name would ensure that folk don't get
confused into thinking that there is any kind of subtyping going on here --
specifying ";type=root" is simply providing meta-data which describes a
constrained use of the general atom type -- it is no different from doing
something like saying: "I won't except any feeds that don't have <icon/>
elements." or, "This feed contains no more than 256 entry elements." If one
is being exceptionally formal or overly pedantic, I can see how you might
argue that a feed constrained to fewer than 257 entries is somehow a
sub-type of sub-class of the more general atom type. But, since every
distinct instance of the atom type can be described in similar manners, it
would mean that every atom instance is a "subtype." In some contexts, this
observation might be useful. I don't think, however, that such precision is
useful in the realm for which we normally are designing Atom...

bob wyman

---

From: "Hugh Winkler" <[email-masked]>
Date: Fri, 15 Dec 2006 13:38:42 -0600

> What would be better than "type?" Might "root" work better?

No, my point was that "type" is right on the money; it correctly
describes what you're doing... defining a new mime type, but
overloading the parameter mechanism to do so.

>
>
> It seems to me that "application/atom+xm;type=entry" describes "an Atom document whose root element is `<entry/>'." The type of the document is "atom" but it is a "kind" or "type" of atom document that has an <entry/> element as it's root. Unfortunately, "type" is being used to mean two completely different things in this context.
>

No.

> One argument for using "root" is that it might be a usage that would be useful with other mediatypes which have more than one possible root element. Also, using "root" as the parameter name would ensure that folk don't get confused into thinking that there is any kind of subtyping going on here -- specifying ";type=root" is simply providing meta-data which describes a constrained use of the general atom type -- it is no different from doing something like saying: "I won't except any feeds that don't have <icon/> elements." or, "This feed contains no more than 256 entry elements." If one is being exceptionally formal or overly pedantic, I can see how you might argue that a feed constrained to fewer than 257 entries is somehow a sub-type of sub-class of the more general atom type. But, since every distinct instance of the atom type can be described in similar manners, it would mean that every atom instance is a "subtype." In some contexts, this observation might be useful. I!
  don't think, however, that such precision is useful in the realm for which we normally are designing Atom...

Straw man: I didn't even remotely imply that all uses of mime
parameters is the same as subclassing. In this case, yes, as betrayed
by the natural choice of language.

When James's proposal came up, I happened to have just constructed
some server code (not Atom-specific) to dispatch PUT and POST based on
the mime type of the request entity. You just do a simple string match
on the bit in front of the semicolon, and dispatch based on that. It's
very easy to parameterize that mechanism: any plugin can declare it
handles "application/atom+xml". It's not such a big deal if the
handler for "application/atom+xml" has to further dispatch based on
the parameters, but you can see it's duplicative. The reason for the
duplication is a little imperfection in the modelling. If the WG
decides other considerations outweigh this one, programmers will
handle it. No biggie.

But lots of mime type dispatch code lives in browsers, and in servers,
and most of the mime.types-ish files you see never have a semicolon in
them. (James is correct that you can put the parameter in mime.types
for Apache, but of course that is a case of dispatching based on file
extension, not on mime type).

Hugh

---

From: Geoffrey Sneddon <[email-masked]>
Date: Fri, 15 Dec 2006 22:51:45 +0000

> and they would get subscribed to a feed that doesn't update, or they'd

This is my real issue with just using a MIME type parameter - feed  
readers normally just ignore an unknown MIME type parameter, so we'd  
have the same issue (entry documents showing up with feed documents).  
Creating a MIME type would get around this issue - I think this is  
really just a time when we have to step back and look at where we  
are, and choose what to do in this situation, regardless of what is  
technically correct.

- Geoffrey Sneddon

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 16 Dec 2006 01:01:09 +0100

On Fri, 15 Dec 2006 13:47:05 +0100, David Powell <[email-masked]>  
wrote:

> pointing to a feed and an Atom Entry document.

My thought on this is that that's actually broken. If not according to RFC  
4287 or anything else, it's most likely wrong semantics involved. Ether  
the current HTML document is an alternate representation of the Atom  
Entry, or it is an alternate representation of the Feed.

In any case, the relation type 'feed' would be better suited for the feed  
reference and 'alternate' would suit the Entry reference if the Entry  
indeed was an alternate representation of the HTML document.

Alternate representation of web site front pages are typically Feeds,  
alternate representations of article pages are typically Entries. There's  
very few cases where a Feed and an Entry can be alternate representations  
of the same resource.

---

From: John Panzer <[email-masked]>
Date: Fri, 15 Dec 2006 16:31:29 -0800

Asbjørn Ulsberg wrote:
>
> On Fri, 15 Dec 2006 13:47:05 +0100, David Powell 
> <[email-masked]> wrote:
>
> My thought on this is that that's actually broken. If not according to 
> RFC 4287 or anything else, it's most likely wrong semantics involved. 
> Ether the current HTML document is an alternate representation of the 
> Atom Entry, or it is an alternate representation of the Feed.
Or both.  Millions of blog entry pages have both an entry and a set of 
comments on that entry.  Yes, it's stretching the concept of 'alternate' 
a long, long way.
>
> In any case, the relation type 'feed' would be better suited for the 
> feed reference and 'alternate' would suit the Entry reference if the 
> Entry indeed was an alternate representation of the HTML document.
Agreed, in an ideal world.

-- 
Abstractioneer <http://feeds.feedburner.com/aol/SzHO>John Panzer
System Architect
http://abstractioneer.org

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 16 Dec 2006 15:30:02 +0100

> comments on that entry.  Yes, it's stretching the concept of 'alternate'

Yes, it's a long stretch. RFC 4685 specifies how to build that  
relationship; rel="alternate" is not the appropriate solution.

> Agreed, in an ideal world.

Considering that the 'feed' relationship is being baked in WHATWG, I don't  
think that ideal world is such a utopia.

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Dec 2006 12:27:07 -0800

Ok, so we've had more than just a few people put up their hands and say
"what Bob said".  This week I'll go ahead write up an initial draft of
this using the type param option while we wait for the co-chairs to do
their hasty consensus grab :-)

- James

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 19 Dec 2006 22:31:00 +0100

> their hasty consensus grab :-)

«What James said.» ;)