Subject: Re: PaceEntryMediatype

From: "Mark Baker" <[email-masked]>
Date: Fri, 1 Dec 2006 11:50:05 -0500

Urgh, sorry for my tardiness; I'm falling behind on my reading.

On 11/30/06, Thomas Broyer <[email-masked]> wrote:
> I'd prefer basing autodiscovery on the media types and not at all on
> the relationships.

All a media type tells you (non-authoritatively too) is the spec you
need to interpret the document at the other end of the link.  That has
very little to do with the reasons that you might want to follow the
link, subscribe to it, etc..  Which is why you need a mechanism
independent from the media type.  Like link types.

Consider hAtom.  If you went by media types alone, you'd be confronted with;

<link type="text/html" href="hatom.html" />

Not particularly useful for subscription (or anything else for that
matter) is it?  This would be better;

<link rel="feed" type="text/html" href="hatom.html" />

Autodiscovery should ideally be based primarily on link types, and
only secondarily - as an optimization - on media types.  Even this
should work;

<link rel="feed" href="hatom.html" />

Mark.

---

From: "Kyle Marvin" <[email-masked]>
Date: Fri, 1 Dec 2006 11:17:04 -0600

I'm still listening to the debate, but Mark's argument resonates with me.
It seems like 'content-type' is more about the expected syntax of the
resource at the other end of the wire, not it's semantic meaning.  I don't
see Atom feeds and entries as syntactically different enough to warrant
unique media types, there's lots of existing parsers that seem able to
navigate this split just fine already.

I expect that if you associated a 'rel' value with links that point to
"application/atom+xml", whether it is expected to be a feed or an entry
would probably be part of the 'rel' description and thus not ambiguous at
all.   I think the discussion started because of the aforementioned issues
with the HTML5 link semantics, which is what should probably be fixed.

On top of that, the procedural and back compat issues associated with
splitting the mime type now just don't seem to make it a win to me.

Crazy busy and largely silent, but not completely awol,

-- Kyle

---

From: James M Snell <[email-masked]>
Date: Fri, 01 Dec 2006 09:53:36 -0800

Kyle Marvin wrote:
> [snip]
> would probably be part of the 'rel' description and thus not ambiguous
> at all.   I think the discussion started because of the aforementioned
> issues with the HTML5 link semantics, which is what should probably be
> fixed.
> 

Not necessarily.

Consider:

  <link rel="alternate" type="application/atom+xml" href="feed.xml" />
  <link rel="alternate" type="application/atom+xml" href="archive.xml" />
  <link rel="alternate" type="application/atom+xml" href="entry.xml" />

What is the purpose of using alternate links? What is a UA supposed to
do with 'em? Why did I as a content publisher choose to use the
"alternate" link relation? Are all of these links of equal value to all
UA's?  Are they all expected to be processed in the same basic way?
Should an "archive" feed be treated the same way as a "subscription" feed?

Consider this use case:

In IBM's Activities implementation, each of our "Activity" collections
are entries in a top level master collection.  Every "Activity" has
several representations: An Atom entry, An Atom feed, A RSS feed, A HTML
page, etc.  On the html page I want to be able to link to each of the
various representations as alternates.  I also want folks to be able to
subscribe to the Atom feed and allow the folks who are building
APP-enabled editing tools to autodiscover the edit uri of the entry.  I
don't want UIs to show a subscription link to the Atom entry representation.

What I want is something like this:

  <link rel="alternate subscribe"
        type="application/atom+xml"
        href="feed.xml" />
  <link rel="alternate edit"
        type="application/atom.entry+xml"
        href="entry.xml" />
  <link rel="alternate subsribe"
        type="application/rss+xml"
        href="rss.xml" />

Given these links I have all of the information I need:

  * There are three alternate representations: An Atom Entry, An Atom
Feed and an RSS Feed.
  * There are two links I can subscribe to: An Atom Feed and an RSS Feed
  * There is one edit link

Note that this clearly separates the purpose of the link (rel) from the
resource type.  I don't care what the value of the type attribute is, if
rel includes the keyword "subscribe" (or "feed", doesn't matter) then I
know I can subscribe to that resource.  If the rel contains the keyword
"alternate" I know it's an alternate representation, no other semantics
are implied.  Each of the keywords in the rel attribute are completely
orthogonal to one another.

Note also that there is a clear separation between the Atom Feed and
Entry types.  These are different document types intended for different
audiences and deserve different media types.

- James

---

From: "Kyle Marvin" <[email-masked]>
Date: Fri, 1 Dec 2006 12:42:20 -0600

> Should an "archive" feed be treated the same way as a "subscription" feed?

This points out that the above rel+type don't carry sufficient semantic
meaning to help a UA decide what to do with them.   I don't think anyone on
this thread is disagreeing with that.   This discussion (as I understand it)
is about what to do given that ambiguity.   You can either get more specific
with the rel value, with the content-type, or with both.

> orthogonal to one another.

So you've solved the above problem by changing both the rel value and the
content-type (in a few cases).  I'd propose that changing the rel value
(alone) would a sufficient solution.  The above "rel" values provide
sufficient information with some implied expectations about feed vs. entry
resource and potential usage of the href.  The implied nature could be
explicit if these rel values were enumerated somewhere (for example, you
subscribe to feeds, and you edit entries).

> audiences and deserve different media types.

I see the separation but I'm still missing a clear justifiication for it.  I
don't see content-type as having anything to do with the "audience".  It's
about what media format you'd get back if you dereference the href and rel
is about how you can interpret/interact with it.   I feel like the primary
audience for content-type is likely to be used in selecting some type of
parser when retrieving the resource.  Orthogonal to this, the "rel" value
assigns some semantic meaning to the resource (what does the entry or feed
describe) and might also specify what interaction model you might expect via
the href (ex. "edit" implies APP edit semantics on an entry resource).

Cheers!

---

From: Ernest Prabhakar <[email-masked]>
Date: Fri, 1 Dec 2006 10:54:23 -0800

On Dec 1, 2006, at 10:42 AM, Kyle Marvin wrote:
> I see the separation but I'm still missing a clear justifiication  
> for it.  I don't see content-type as having anything to do with the  
> "audience".  It's about what media format you'd get back if you  
> dereference the href and rel is about how you can interpret/ 
> interact with it.   I feel like the primary audience for content- 
> type is likely to be used in selecting some type of parser when  
> retrieving the resource.  Orthogonal to this, the "rel" value  
> assigns some semantic meaning to the resource (what does the entry  
> or feed describe) and might also specify what interaction model you  
> might expect via the href (ex. "edit" implies APP edit semantics on  
> an entry resource).

+1 to what Kyle said

-- Ernie P.

---

From: James M Snell <[email-masked]>
Date: Fri, 01 Dec 2006 11:25:36 -0800

You're right that the differentiation in the content-type is of less
importance but without it there's no way for me to unambiguously
indicate that a resource has both an Atom Feed representation and an
Atom Entry representation.  The best I could do is say "This things has
two Atom representations".  Keep in mind that I want to be able to
differentiate the types of alternate representations available without
having to look at any of the other rel keywords.

- James

Kyle Marvin wrote:
> [snip]
> I see the separation but I'm still missing a clear justifiication for
> it.  I don't see content-type as having anything to do with the
> dereference the href and rel is about how you can interpret/interact
> with it.   I feel like the primary audience for content-type is likely
> to be used in selecting some type of parser when retrieving the
> resource.  Orthogonal to this, the "rel" value assigns some semantic
> meaning to the resource (what does the entry or feed describe) and might
> also specify what interaction model you might expect via the href (ex.
> "edit" implies APP edit semantics on an entry resource).
> 
> Cheers!
>

---

From: Ernest Prabhakar <[email-masked]>
Date: Fri, 1 Dec 2006 11:35:12 -0800

Hi James,

> having to look at any of the other rel keywords.

I understand that this is *what* you want, but I'm still unclear "why."

 From where I sit, Kyle's argument makes sense: keep the syntax in  
content-type, and the semantics in rel-type.  This seems both simpler  
and more consistent with how the web works today. No?  Or is there  
some overriding reason for ignoring rel-type?

-- Ernie P.

---

From: "Kyle Marvin" <[email-masked]>
Date: Fri, 1 Dec 2006 13:39:54 -0600

On 12/1/06, James M Snell <[email-masked]> wrote:
> Atom Entry representation.

I can see that it's possible to have two different representations for the
same resource (GData does this too) but a key question is whether they have
the same relation (semantic meaning/purpose relative to the linking
content).   In your earlier example, they did not (subscription vs. edit).

The best I could do is say "This things has
> having to look at any of the other rel keywords.

Can you explain why you want this?   I'm not trying to be relentless I just
want to make sure I'm not missing something important while pushing back.

-- Kyle

---

From: James M Snell <[email-masked]>
Date: Fri, 01 Dec 2006 14:05:04 -0800

I could but after the discussions this week I'm not sure its worth it.

Yes, everything can be done using different rel values; the content-type
thing is more just an annoyance than anything else. I'll just make sure
that I never link my Atom entry documents using "alternate" (even tho
that's what they are).

- James

Kyle Marvin wrote:
> [snip]
> Can you explain why you want this?   I'm not trying to be relentless I
> just want to make sure I'm not missing something important while pushing
> back.
> 
> -- Kyle
> 
>

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 1 Dec 2006 18:27:25 -0800

Supporting data or ideas: Some interesting links, semantically  
speaking, don't even have a fixed MIME type (or not just one,  
anyhow).  If we wanted to add link relations for photo shares on  
WebDAV repositories, or personal calendars on CalDAV repositories,  
you'd want to point to the URL to the appropriate WebDAV collection,  
which could return results in HTML (response to GET without any  
special stuff), XML (response to PROPFIND), or iCalendar (in the  
CalDAV case).  Not sure how to fully convey all of that, but at least  
not overloading MIME type with semantic meaning helps the situation.

Lisa

On Dec 1, 2006, at 9:17 AM, Kyle Marvin wrote:

> I'm still listening to the debate, but Mark's argument resonates  
> with me.  It seems like 'content-type' is more about the expected  
> syntax of the resource at the other end of the wire, not it's  
> semantic meaning.  I don't see Atom feeds and entries as  
> syntactically different enough to warrant unique media types,  
> there's lots of existing parsers that seem able to navigate this  
> split just fine already.
>
> I expect that if you associated a 'rel' value with links that point  
> to "application/atom+xml", whether it is expected to be a feed or  
> an entry would probably be part of the 'rel' description and thus  
> not ambiguous at all.   I think the discussion started because of  
> the aforementioned issues with the HTML5 link semantics, which is  
> what should probably be fixed.
>
> On top of that, the procedural and back compat issues associated  
> with splitting the mime type now just don't seem to make it a win  
> to me.
>
> <link type="text/html" href=" hatom.html" />
>
> <link rel="feed" type="text/html" href="hatom.html " />
>
> <link rel="feed" href=" hatom.html" />
>
> Mark.
>
>

---

From: Antone Roundy <[email-masked]>
Date: Fri, 1 Dec 2006 21:41:48 -0600

> independent from the media type.  Like link types.

Now that this has sunk in, it makes a lot of sense--the @rel value  
says "you can subscribe to that", "that is an alternative  
representation of this", "that is where you'd go to edit this", and  
so on.  The media type helps the user agent figure out whether it has  
the capability to do those things.  For example, a feed reader that  
only handles RSS could ignore subscription links to resources of type  
"application/atom+xml" (ie. not present the subscription option to  
the user).  The "subscribe to hAtom feed" case where @type is "text/ 
html" might be a little difficult to make a decision on, because  
there's no indication of what microformat is being used by the  
"feed" (or even if there's a microformat in use at all--maybe it  
really is just an HTML page, and "subscribing" to it just means  
"watch for changes to the entire document").  But in the case of bare  
syndication formats, things should be clear enough.

So if it really is possible to do option 5 (new media type for entry  
documents, and @rel values to solve the rest of the issues), and do  
it cleanly, then that'd be my first choice.  If that's doomed (due to  
a need to be backwards compatible with existing practice) to be a  
mess of ambiguities and counter-intuitivities (eg. "alternate" means  
"subscribe" when combined with a syndication type, except when it  
might really mean "alternate" because it points to a feed archive  
document, but anything with "feed" in it always means "subscribe"...)  
then oh my.

One problem that I hadn't really thought clearly about till right now  
is that understanding the nature of the think linked TO may require  
some understanding of the nature of the thing linked FROM.  For  
example, an "alternate" link from a typical blog homepage to its feed  
really does point to the same thing in an alternative format.  Both  
are live documents in which new data gets added to the top, and old  
data drops off the bottom.  But if you don't know that the webpage is  
a live document, you wouldn't know whether the link pointed to a  
static or live document.  "alternate" is perfectly accurate, but it's  
not helpful enough.  "subscribe" would be much more explicit.

Which raises the question of how to point to a static alternative  
representation of the data currently found in the document.   
"alternate" WOULD be a good word to use for that except that it's  
already being used to point to live feeds.  An option that would  
almost surely cause confusion would be to use "alternative" for  
static alternative representations.  The meaning of "static" wouldn't  
exactly be intuitively clear.  Maybe something more long-winded like  
(oh no! hyphenation!) "static-alternate" would do.  Or would "static  
alternate" (and "alternate static" and "static foo alternate",etc.,  
or perhaps "archive alternate", etc.) be better?  For backwards  
compatibility (at least with UAs that don't expect only one value in  
@rel), "subscribe alternate" (and "alternate subscribe", etc.) could  
be used rather than simply "subscribe".

BTW, am I remembering correctly that "feed" is being promoted for use  
the way I'm considering "subscribe" above?  If it's not already in  
use, I'd thinK "subscribe" would be much better than "feed", because  
"feed" could as easily mean "archive feed" as "subscription feed"-- 
it's just not explicit enough.

But perhaps this discussion all belongs in a different venue anyway...

But before I end, what about the question of a different media type  
for entry documents?  For the APP accept element issue, it sounds  
like maybe they do.  But for autodiscovery, maybe they don't.   
Perhaps neither @type nor @rel is the place to distinguish, for  
example, between the edit links for entries, their parent feeds,  
their per-entry comment feeds, monolithic comment feeds, etc.  (A  
media type for entry documents would only help with one of those).   
Perhaps that is the domain of @title (title="Edit this entry", etc.)   
Do UAs really need to know the difference, or do only the users need  
to know?  Would making that information machine readable be worth the  
pain involved (rel="edit monolithic parent comments"???)

Okay, that's all I can take for now.

---

From: "Daniel E. Renfer" <[email-masked]>
Date: Sat, 2 Dec 2006 03:34:03 -0500

The difference between a collection of entries and a single entry is
an important one. Sure, once you get inside the Entry, everything is
the same, but knowing ahead of time that you are requesting a single
Entry assists in processing. If I'm getting an
application/atom.entry+xml I know to use my stylesheet for only a
single Entry, whereas when I'm getting an application/atom+xml
resource, I know I have a collection containing 1 or more Entries.
It's the difference between having a variable, or a list of variables.

Imagine a system that uses conneg to give atom representations of a
file system. I could request http://www.example.com/db/foo/ and
depending on what I put in my accept could determine whether I'm
getting back the collection of contents of foo/ or if I'm getting the
information on the foo/ folder. There are times when you need to
differentiate between the two types when rel="" values are not
available.

I agree with James that there should also be a different rel="" value
to tell the UA what to do with it, but you still need that different
type to signal the difference in what it actually is.

Since most UA's out there don't really deal with single atom entries
as it is right now, and most parsers will have to accept that they
might get back only a single entry from an application/atom+xml and
the ones that don't understand how to work with a single Entry will
just ignore the application/atom.entry+xml link anyway, the impact
isn't all that great to clear up this difference in semantics now and
for good.

Daniel E. Renfer
http://kronkltd.net/

On 12/1/06, Lisa Dusseault <[email-masked]> wrote:
>
>
> Supporting data or ideas: Some interesting links, semantically speaking,
> don't even have a fixed MIME type (or not just one, anyhow).  If we wanted
> to add link relations for photo shares on WebDAV repositories, or personal
> calendars on CalDAV repositories, you'd want to point to the URL to the
> appropriate WebDAV collection, which could return results in HTML (response
> to GET without any special stuff), XML (response to PROPFIND), or iCalendar
> (in the CalDAV case).  Not sure how to fully convey all of that, but at
> least not overloading MIME type with semantic meaning helps the situation.
>
> Lisa
>
>

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sat, 02 Dec 2006 08:54:05 +0000

> isn't all that great to clear up this difference in semantics now and

I wholeheartedly agree with you here. The problem is that so far most of
the discussion has been carried from the client side of things without
trying to understand the limit of the server side. There are cases where
not having a specific media type (or at least a way within the media
type to distinguish them) will be a problem. Maybe the impact of those
issues is not worth the trouble but if application/atom+xml leads us to
the same situation of the unusable application/xml media type then I
predict quite mess.

My issue here is that most of the discussion has been centered around
how an Atom document was consumed until now. With the versatility of
Atom and the power of APP it is more than likely that new use of those
formats will show up. They may or may not benefit from having several
media types. But they will certainly not be hurt by having the choice.
Therefore I do believe a new media type should be brought up.

- Sylvain

---

From: Jan Algermissen <[email-masked]>
Date: Sat, 2 Dec 2006 16:08:32 +0100

Maybe this perspective helps:

Is there any other media type that covers more than one document type  
(root element in the case of XML, but could also be non-XML mime types)?

It would be interesting to see how those (if any) deal with the  
issue. An example would maybe be iCalendar, Ithink.

Also: If feeds and entries get their own media types, then a feed  
(consisting essentially of a bunch of entry documents comes pretty  
close to a multipart/related message - which would make the very  
existence of the feed media type questionable.

And another thought: HTML has in a sense also two processing models  
within a single mime type (normal body and frames) and does not have  
a substantial problem with that, does it?

Jan

---

From: James M Snell <[email-masked]>
Date: Sat, 02 Dec 2006 09:28:24 -0800

> (root element in the case of XML, but could also be non-XML mime types)?

application/xml

> It would be interesting to see how those (if any) deal with the issue.
> An example would maybe be iCalendar, Ithink.
> 

application/xhtml+xml
application/atom+xml
...

> (consisting essentially of a bunch of entry documents comes pretty close
> to a multipart/related message - which would make the very existence of
> the feed media type questionable.
> 

-1.

> within a single mime type (normal body and frames) and does not have a
> substantial problem with that, does it?
> 

Different issue.  Frames and body are both used by the same types of
clients for the same purpose (rendering a UI).  They just lead to
different results.

- James

---

From: "Mark Baker" <[email-masked]>
Date: Sat, 2 Dec 2006 22:32:34 -0500

On 12/2/06, Daniel E. Renfer <[email-masked]> wrote:
> Entry assists in processing.

But then you're talking about a different resource than the feed, and
so should use a different URI than the feed URI.

Mark.

---

From: "Thomas Broyer" <[email-masked]>
Date: Sun, 3 Dec 2006 13:14:21 +0100

2006/12/2, Antone Roundy:
> says "you can subscribe to that",

Why would I subscribe? is it an alternate representation of what I'm
looking at? or the feed containing the article I'm looking at? or a
totally distinct resource that might interest me if I'm interested in
what I'm looking at (think about blogrolls and the "people who bought
this also bought that and that" links)?

By saying "you can subscribe to that", you're not describing a
relation. Maybe you're describing a facet of the resource the link
points to, but is this objective or subjective? If it's meant to be
objective, then the media type is enough (am I *able* to subscribe to
such a thing), or maybe there's a need for another kind of metadata (I
proposed a new 'subscribable' attribute on the WHATWG list).

> The media type helps the user agent figure out whether it has
> the user).

And if an UA has the capability to subscribe to something, why
couldn't it provide a mean to subscribe, whichever the relationship?
What would be important is to reflect the relationship on the UI so
the user have all the information available to choose whether he
*wants* to subscribe.

> The "subscribe to hAtom feed" case where @type is "text/
> "watch for changes to the entire document").

...or it's an HTML5 page making use of the new <article> element...

> not helpful enough.  "subscribe" would be much more explicit.

Why should it be automated?
When you go read a web site every morning because you know it's
"live", it's not automated. What you could automate is how to go read
that site (e.g. use it as your browser's "start page", or include it
in a bunch of bookmarks you "open in tabs" every morning).
There's not always a need to automate everything. Things like "whether
it'd be interesting to subscribe to something" are better handled by
humans than computers.

-- 
Thomas Broyer

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 03 Dec 2006 22:01:00 +0100

On Wed, 29 Nov 2006 20:03:22 +0100, Thomas Broyer <[email-masked]>  
wrote:

> I'd largely prefer augmenting the existing media type with a 'type'  
> parameter:
>  - application/atom+xml => either feed or entry (as defined in RFC4287)
>  - application/atom+xml;type=feed => feed
>  - application/atom+xml;type=entry => entry

+1.

> How about defining a "tree" similar to the */vnd.* one?
>  - application/atom+xml => feed or entry document
>  - application/atom.categories+xml => category document
>  - application/atom.service+xml => service document
> ...and of course, if this proposal is finally accepted:
>  - application/atom.entry+xml => entry document

I think 'type=*' is a cleaner solution, but both serves the same purpose  
so I'm not religious about which solution we choose. But I agree that  
distinguishing between entries, feeds and every other atom resource is  
indeed useful. +1.

> As for Tim's concerns, I'd also prefer having it done outside the APP.

Yep.

> Also, the APP draft would need to be updated to remove the "entry"
> special value for app:accept, as it would be equivalent to the new or
> revised media type (app:accept=application/atom+xml;type=entry or
> app:accept=applicationAtom.entry+xml)

Of course.

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 03 Dec 2006 22:12:51 +0100

On Fri, 01 Dec 2006 19:42:20 +0100, Kyle Marvin <[email-masked]> wrote:

> meaning to help a UA decide what to do with them.   I don't think anyone  
> on this thread is disagreeing with that.   This discussion (as I  
> understand it) is about what to do given that ambiguity.   You can  
> either get more specific with the rel value, with the content-type, or  
> with both.

The problem with baking the necessary information for this particular use  
case inside the 'rel' value is that we possibly need a million different  
'rel' values for a million diffierent use cases, or what we'll see is  
semantic overloading where 'rel' values are abused to mean different  
things in different use cases and that again will hurt interoperability.

Instead, we can let consumers define their own use cases upon the given  
content type and not push our pre-defined use cases (in the form of 'rel'  
values) down their throat because we're too reluctant to expand the MIME  
type of atom with a 'type' attribute (or something similar). Are we  
confident enough about Atom's entire spectre of use cases to say that  
different 'rel' values are sufficient?

I think not. Give consumers the correct content type of the resource  
instead, and they can themselves decide what to do with it, on the base of  
a more general 'rel' value that don't dictate what they can and can't do  
with it. 'rel' values are not sufficient to solve this issue imo. We need  
something less fine-grained and more generic. We need to define this at  
the HTTP level.

---

From: James M Snell <[email-masked]>
Date: Mon, 04 Dec 2006 11:23:09 -0800

And therein lies the problem: entry documents are NOT aliases for
single-entry feeds.

- James

Mark Baker wrote:
> [snip]
> True, but if entry documents are more or less aliases for single-entry
> feeds, why would anybody need to negotiate for one or the other?  I
> suggest that would have to be pretty obscure use case. 8-)
> 
> Mark.
>

---

From: "Mark Baker" <[email-masked]>
Date: Mon, 4 Dec 2006 15:15:19 -0500

I'd be happy to believe you James, if I could find where in the spec
that was stated.

If it looks like an alias, and acts like an alias ... 8-)

Mark.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 04 Dec 2006 20:32:54 +0000

> I'd be happy to believe you James, if I could find where in the spec

Neither does it state they are a 1-to-1 relationship.

> If it looks like an alias, and acts like an alias ... 8-)

Calling them aliases won't make them necessarily aliases.
I find unfortunate that RFC  4287 doesn't actually precise that
particular point. We only have one media type and no clear definition of
the distinction between an entry element and an entry document.

So we have this discussion.

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Mon, 04 Dec 2006 12:35:05 -0800

All I can go on is evidence of how folks are actually using 'em... and
they ain't using 'em as aliases. :-)

- James

---

From: "Mark Baker" <[email-masked]>
Date: Mon, 4 Dec 2006 16:12:59 -0500

> they ain't using 'em as aliases. :-)

Ok, I'll take empirical evidence too 8-)  Point the way ...

Mark.

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 5 Dec 2006 21:04:39 +0100

> Ok, I'll take empirical evidence too 8-)  Point the way ...

Question: what does it mean (what do we have to look for) to use them  
as aliases??

Jan

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Dec 2006 12:15:57 -0800

When I process this entry,

http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0

What is the implied feed?  Where do I get the implied feeds metadata?
Title? ID? Anything?  If the entry contained an atom:source element you
might be able to assume that a logical feed is implied but absent any
other evidence, this is a standalone entry document that can be
processed without any assumption that a feed exists.

- James

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 5 Dec 2006 22:10:50 +0100

> basic/10ge5k2k7c488algfbau5q9qc0

Funny, Safari switches to feed://www.google.com.... :-)

And then says it cannot process the entity (presumably because it is  
an <entry>).

Jan

---

From: Bill de hOra <[email-masked]>
Date: Tue, 05 Dec 2006 21:09:03 +0000

> Ok, I'll take empirical evidence too 8-)  Point the way ...

Mark,

since you introduced it, what's an "alias", exactly?

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Tue, 05 Dec 2006 21:11:09 +0000

> http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0

I had problems subscribing to that entry in bloglines. Will somebody 
file a bug?

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Dec 2006 13:16:23 -0800

Indeed.  The application was written to expect a feed because of the
content-type but gets an entry instead and blows up.

- James

Jan Algermissen wrote:
> And then says it cannot process the entity (presumably because it is an
> <entry>).
> 
> Jan
> 
> 
> 
>

---

From: "Mark Baker" <[email-masked]>
Date: Tue, 5 Dec 2006 23:22:24 -0500

> Question: what does it mean (what do we have to look for) to use them

It wasn't the most illustrative choice of words, but what I'm looking
for is evidence that an entry is interpreted differently if it's found
in an entry document, than if it were found in a feed document.  If we
turn up multiple interoperable examples of that, then a new media type
is warranted because it's really two formats masquerading as one.

Mark.

---

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

> processed without any assumption that a feed exists.

Ok, but I don't see that this would necessitate a new media type.
It's just an entry without a feed.  You'd use the same code path to
process that entry whether it were found in an entry or feed document,
right?

Sorry if I wasn't clear what I was looking for earlier by my use of
the word "alias".

Mark.

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Dec 2006 20:52:10 -0800

> process that entry whether it were found in an entry or feed document,

Not necessarily.  Sure, it might be the same parser code, but not
necessarily the same bit of code using the parser.  Look at the way
Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry
documents versus Feed documents.  The majority of applications that most
frequently handle Atom Feed Documents have no idea how to deal with Atom
Entry Documents and I would wager that most applications that understand
how to process Atom Entry Documents and Atom Feed Documents typically
don't fall into the same category as most feed readers.

- James

---

From: Eric Scheid <[email-masked]>
Date: Wed, 06 Dec 2006 16:13:17 +1100

> don't fall into the same category as most feed readers.

If an agent found an entry document, should it assume that it's a feed with
one entry (so far) and allocate resources accordingly (ie. allow for
cardinality of n++)?

If an agent found an entry document, and then later returned to find a feed
containing multiple entries, would it consider that a problem?

Would an agent finding multiple atom:content elements inside the one entry
consider that a problem (other than it being a spec violation)?

Are XML processors optimised for the fact that any given attribute can only
occur once per element, and not twice or more .. eg. <foo attr="1" attr="2"
/> ?

e.

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 6 Dec 2006 00:32:01 -0500

> don't fall into the same category as most feed readers.

Isn't that just a case of people not implementing the whole spec
though?  FWIW, if that practice is widespread, then I think the group
should consider deprecating entry documents.  Minting a new media type
won't help.

Or, are there applications which only process entry documents and not
feed documents?

Mark.

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Dec 2006 21:58:55 -0800

> should consider deprecating entry documents.  Minting a new media type

The interesting question is *why* haven't those applications implemented
support for Entry Documents.  My guess is that Entry documents aren't
particularly interesting to their use cases which is likely because they
serve a different purpose.

Entry documents serve an extremely useful purpose in the Atom Publishing
Protocol.  They serve a significantly less useful purpose for your
typical feed reader.  That doesn't make them worthy of deprecation; it
just means entry documents are different than feed documents.

> Or, are there applications which only process entry documents and not

Wrong question.  APP clients process both entry documents and feed
documents but do so for entirely different reasons than feed readers.

- James

---

From: Eric Scheid <[email-masked]>
Date: Wed, 06 Dec 2006 17:03:11 +1100

> Or, are there applications which only process entry documents and not

That would be unusual. I can imagine though that an application would easily
be designed to expect only entry documents for specific situations. An
editor application, for example, would know how to handle collection feeds
and entry documents, but would reasonably not be expected to know what to do
if it retrieved a feed document when attempting to edit a specific entry
(especially if it PUT/POSTed the entry as an entry document in the first
place).

Similarly, if an atom:entry element was wrapped inside some other unexpected
XML document (eg. RSS 1.0) ... should applications be prepared to cope with
that?
e.

---

From: James M Snell <[email-masked]>
Date: Tue, 05 Dec 2006 22:06:11 -0800

> one entry (so far) and allocate resources accordingly (ie. allow for

No. In particular, if an atom:source element is not included there is no
way of knowing anything about the implied feed; no atom:id, no
atom:updated, no atom:title, none of the minimal bits of information the
atom spec requires for a feed.  An implied feed would serve no purpose.

> containing multiple entries, would it consider that a problem?

That obviously depends on how the code was written.  If it's an APP
client that's expecting to edit an Atom entry then, yeah, it'll quite
likely be a problem.

Now reverse it.  If an agent (e.g. firefox) finds a feed document and
then later returned to find an entry, would it consider that a problem?

> occur once per element, and not twice or more .. eg. <foo attr="1" attr="2"

Ok, you lost me on these last two. I'm not sure what you're getting at.

- James

---

From: Eric Scheid <[email-masked]>
Date: Wed, 06 Dec 2006 17:34:41 +1100

> Ok, you lost me on these last two. I'm not sure what you're getting at.

It's just the cardinality question in a different context. Argument by
analogy.

e.

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Wed, 6 Dec 2006 07:36:18 -0000 (GMT)

Mark,

Since the beginning you seem to solely focus on what feed readers do or
don't do. Suggesting deprecating the entry document on the APP list is
quite missing the point really.

If people keep seeing Atom as a RSS alternative then there is a big
communication failure from the Atom folks.

Atom feeds are actually less worthy than Atom entries which should have
been pushed even harder as the first class citizen within the RFC.

The Atom entry element is the one carrying the information and is the one
that needs a media-type on its own, or at least a way to mint that
media-type to make  it clear to UAs what they're dealing with. In fact I
will be really interested to hearing from folks who write APP client
extensions for Firefox, Opera or else. Certainly they will tell us that
they don't care about Atom feeds as much as they do about Atom entries.

The thing is that adding a new media-type now would not impact thoroughly
current implementations if for instance we were to say that
application/atom+xml is for Atom feed and application/atomentry+xml was
newly introduced for Atom entry. I actually do not understand why people
get so reluctant at it.

- Sylvain

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 6 Dec 2006 08:52:32 +0100

> If it looks like an alias, and acts like an alias ... 8-)

It doesn’t.

    For resource creation this specification only defines cases
    where the POST body has an Atom Entry entity declared as an
    Atom media type ("application/atom+xml"), or a non-Atom
    entity declared as a non-Atom media type. It does not specify
    any request semantics or server behavior in the case where
    the POSTed media-type is "application/atom+xml" but the body
    is something other than an Atom Entry. In particular, what
    happens on POSTing an Atom Feed Document to a Collection
    using the "application/atom+xml" media type is undefined.

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

---

From: fantasai <[email-masked]>
Date: Wed, 06 Dec 2006 03:18:07 -0500

Mark Baker wrote:
> 
> The real problem here AIUI - at least in the context of HTML 5's
> inferred rel="feed" bit - is not just entry documents, it's any Atom
> document which wouldn't normally be considered a "feed" by a typical
> user; something that most people would be interested in subscribing
> to.  An example I gave on the whatwg list was an MHTML-like (MIME
> multipart) package, but there are many other possible examples of
> course; not all RFC 4287 feed documents are "feeds" in this sense.
> 
> If HTML 5 (and current practice) doesn't change, but we defer to them
> for the specification of autodiscovery, then a new media type would be
> one way forward.  But it should be reusable for all non-"feed" (i.e.
> from a user POV, as above) Atom documents, not just entry documents;
> perhaps application/atom-no-feed+xml.  It's an ugly hack, but it's
> better than the alternative of many more specific Atom-related media
> types, which atomentry+xml might set a precedent for.

Note that HTML 5's special handling of alternate+Atom is triggered on a
literal value for the 'type' attribute:

  # If the 'alternate' keyword is used with the 'type' attribute set to the value
  # 'application/rss+xml' or the value 'application/atom+xml', then the user
  # agent must treat the link as it would if it had the 'feed' keyword specified
  # as well.

That means rel="feed" won't be implied on an Atom Entry document whether the
new MIME type syntax is chosen to be
   application/atom.entry+xml
or
   application/atom+xml;type=entry

It also won't be implied on an Atom feed document if the syntax
   application/atom+xml;type=feed
or
   application/atom+xml;type=archive
is used, as was suggested earlier. This gives us a way to say
   <link rel="alternate" href="[..]" type="[atom]">
without implying
   <link rel="alternate feed" href="[..]" type="[atom]">
and without dropping the 'type' attribute entirely (which was the other
solution pointed out on the whatwg list).

~fantasai

---

From: James M Snell <[email-masked]>
Date: Wed, 06 Dec 2006 00:27:36 -0800

Actually, for the form "application/atom+xml;type=entry" it's more
likely that browsers will completely ignore the type param as they do
currently.

- James

---

From: fantasai <[email-masked]>
Date: Wed, 06 Dec 2006 03:27:49 -0500

Thomas Broyer wrote:
> 
> 2006/11/29, James M Snell:
>> Create a new media type for Atom Entry Documents: 
>> application/atomentry+xml
>>
>> Deprecate the use of application/atom+xml for Entry Documents.
> 

I also think this is a nicer solution. It reflects that the two document
types are fundamentally the same format. If there's no practical reason
to have two actually separate MIME types, I think it would make more sense
to differentiate entry and feed documents like this.

~fantasai

---

From: Andreas Sewe <[email-masked]>
Date: Wed, 06 Dec 2006 10:58:09 +0100

> likely that browsers will completely ignore the type param as they do

Well, if a browser ignores a media type's parameters, it will have to
face the consequences: In the case of "application/atom+xml;type=entry"
it would get "application/atom+xml" which means 'either an Atom Feed or
Entry Document'; if it cannot handle Atom Entry Documents without
breaking, it does not properly implement RFC 4287. But your point that
*current* browsers silent discard a "type" parameter on
"application/atom+xml" is moot anyway since the *current* Atom RFC
specifies no such parameter.

That being said, an *optional* type parameter offers the cleanest
solution to distinguishing between the following three cases:

   1) Either an Atom Feed or Entry Document
   2) An Atom Feed Document
   3) An Atom Entry Document

If RFC 4287 had defined separate media types for the latter two cases,
we wouldn't have this problem, of course: "Accept:
application/atomfeed+xml, application/atomentry+xml" would cover the
first case just fine.

But since the RFC sadly doesn't I am extremely reluctant to either
deprecating the use of "application/atom+xml" for Atom Entry Documents
or to introducing three media types overall when an optional parameter
suffices.

So, James, what is wrong with "application/atom+xml;type=[entry|feed]"?
(A slim majority on this list seems to prefer it over defining separate
media types.)

Regards,

Andreas Sewe

---

From: "Kyle Marvin" <[email-masked]>
Date: Wed, 6 Dec 2006 08:06:54 -0600

I feel like this whole discussion about whether an entry is logically
equivalent to a feed is a little bit of a red herring.   To me, the
important justification for forking the Atom content type comes from a
belief that this is useful information that you need *before* you
retrieve/process the target document.

I think we can all agree that parsing/syntax alone isn't enough to justify
this;  there are many existing Atom parsing impls that can handle the
current approach just fine, and lots of counter examples of other MIME types
that do even more overloading of multiple semantic content types under a
single syntactic content type (ex "text/xml").

Something which can't handle the current range of potential Atom document
contents for "application/atom+xml" doesn't seem like a strong argument
either.   We all know it's _possible_, it's just that in some contexts (like
feed reading) it hasn't been considered _interesting_ to implement entry
handling.  I don't think a new MIME type fixes this, there are lots of real
world cases of software developers who only implement a subset of a spec
that they find is interesting or useful, it's always gonna happen but often
gets fixed.

I'm still looking for one or two use cases where having the distinction
between whether a referenced document points to a feed or an entry is a
vital thing.   I can honestly say from the GData side we haven't seen this
need yet, but that doesn't mean it exists.   A link relation mght imply the
content type (ex 'subscribe') or might be a logical relation that can apply
to multiple content-types (as Lisa noted), but in the latter case what
benefits do feed vs. entry doc distinction buy you?

-- Kyle

---

From: Bill de hOra <[email-masked]>
Date: Wed, 06 Dec 2006 15:44:36 +0000

Mark Baker wrote:

> though?  

Not really. The RFC defines the structure, not so much the interaction 
model around feeds (which is driven by UIs more than anything else, so I 
can buy into it being somewhat arbitrary)

> Or, are there applications which only process entry documents and not

Anything based on Atom Protocol will be making a distinction.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Wed, 06 Dec 2006 08:25:52 -0800

The key problem I have with the ;type=param is that it's optional and
likely to be ignored by a good number of implementations (which ends up
buying us nothing in terms of interop).  A separate media type is less
ideal but has greater practical value in that it addresses the problem
immediately.

- James

---

From: Andreas Sewe <[email-masked]>
Date: Wed, 06 Dec 2006 18:11:03 +0100

> ideal but has greater practical value in that it addresses the problem

Understood.

I don't think, however, that a separate media type for Entry Documents 
will solve more problems than it causes:

Applications which adhere to RFC 4287 and accept both Feed and Entry 
Documents labeled as "application/atom+xml" won't recognize 
"application/atomentry+xml"; they will have to be updated.

But, honestly, I would rather see those buggy applications updated which 
break whenever they encounter an Entry Document labeled correctly as 
"application/atom+xml". That's a bug waiting to be fixed anyway, whether 
we immediately deprecate the labeling of Entry Documents 
"application/atom+xml" or not; some Entry Documents have already escaped 
into the wild.

Regards,

Andreas Sewe

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 06 Dec 2006 18:17:06 +0100

> is warranted because it's really two formats masquerading as one.

To turn it a bit around: Would you ever want to subscribe to a single Atom  
Entry? If not, wouldn't it be good to know that it was an Atom Entry and  
not an Atom Feed before you started subscribing to it?

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 06 Dec 2006 10:14:04 -0800

>not an Atom Feed before you started subscribing to it?

This is misleading wording (and maybe part of the overall problem)!

Following a link is not the same thing as subscribing to something. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Your agent then decides if subscribing to that resource is a good idea. To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes <feed> or <entry>.

Anyhow, why not monitor a single entry? I think this is far more a user agent configuration issue than it is a problem of the media type being returned.

FWIW, I think the question of media type (or the feed-ness of some resource) and the issue of whether to subscribe or not are completely orthogonal.

Maybe I want to monitor a single media resource; an Atom media entry would be an ideal thing to do so (I'd rather look at the meta data than at the media resource upon each poll).

 I'd say: stick with the one media type that is currently there - there is no problem, just misconception about what it means to subscribe.

Jan

---

From: Antone Roundy <[email-masked]>
Date: Wed, 6 Dec 2006 13:11:17 -0600

On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:
> Following a link is not the same thing as subscribing to something.  
> The act of subscribing is a local activity performed by the user  
> agent. What you do when you follow the link to a feed is a GET.  
> Your agent then decides if subscribing to that resource is a good  
> idea. To make that decision, the agent has to look at the  
> representation and the it is insignificant overhead to see if the  
> thing returnes <feed> or <entry>.
>
> ...
>
> Maybe I want to monitor a single media resource; an Atom media  
> entry would be an ideal thing to do so (I'd rather look at the meta  
> data than at the media resource upon each poll).
>
>  I'd say: stick with the one media type that is currently there -  
> there is no problem, just misconception about what it means to  
> subscribe.

A few reasons why a user agent might want to be able to tell the  
difference between a link to a feed and a link to an entry beforehand  
is in order to:

1) be able to ignore the link to the entry (ie. not present it to the  
user) if the user agent doesn't handle entry documents (rather than  
presenting it as a "subscribe" link, only to have to say "sorry, it's  
not a feed" after the user tries to subscribe).

2) be able to say "subscribe" to links to feeds, and "monitor" links  
to entries (the user may not be interested in monitoring a single  
entry for changes--if they can't tell that that's what the link is  
for, they may end up needlessly doing so but think that they've added  
another feed to their subscription list).

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 06 Dec 2006 11:42:40 -0800

>difference between a link to a feed and a link to an entry beforehand  

But that is an issue of linking semantics, not link target media types. I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types.

IMHO, there is something going wrong somewhere - and it ain't the media type.

Jan

---

From: Bill de hOra <[email-masked]>
Date: Wed, 06 Dec 2006 21:07:34 +0000

Antone Roundy wrote:
>> agent. What you do when you follow the link to a feed is a GET. Your 
>> agent then decides if subscribing to that resource is a good idea. To 
>> make that decision, the agent has to look at the representation and 
>> the it is insignificant overhead to see if the thing returnes <feed> 
>> or <entry>.
>>
>> ...
>>
>> Maybe I want to monitor a single media resource; an Atom media entry 
>> would be an ideal thing to do so (I'd rather look at the meta data 
>> than at the media resource upon each poll).
>>
>> there is no problem, just misconception about what it means to subscribe.
> 
> difference between a link to a feed and a link to an entry beforehand is 
> in order to:
> 
> 2) be able to say "subscribe" to links to feeds, and "monitor" links to 
> entries (the user may not be interested in monitoring a single entry for 
> changes--if they can't tell that that's what the link is for, they may 
> end up needlessly doing so but think that they've added another feed to 
> their subscription list).

3) to open an entry in an editing app.

Datapoint:  double clicking on an Atom Entry file in Ubuntu results  in 
the following:

[[[
The filename 
"LE1100_1254262_1_4E760C4E-36D9-065D-7AF7-FB168427888D_1081337005687.xml" 
indicates that this file is of type "XML document". The contents of the 
file indicate that the file is of type "Draft journal entry". If you 
open this file, the file might present a security risk to your system.

Do not open the file unless you created the file yourself, or received 
the file from a trusted source. To open the file, rename the file to the 
correct extension for "Draft journal entry", then open the file 
normally. Alternatively, use the Open With menu to choose a specific 
application for the file.
]]]

I believe this is because I had drivel installed at one point. Double 
clicking on an Atom Feed document opens it in Firefox. I'm kind of 
surprised by this, but thinking about it, you don't really write feeds, 
but you do write entries.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Wed, 06 Dec 2006 13:43:27 -0800

> "application/atomentry+xml"; they will have to be updated.

In consider that a feature.

- James

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 06 Dec 2006 23:01:31 +0100

> This is misleading wording (and maybe part of the overall problem)!

Perhaps, but it describes one of the most important use-cases with feeds  
-- which won't be the one with entries.

> Following a link is not the same thing as subscribing to something.

Of course not.

> The act of subscribing is a local activity performed by the user agent.
> What you do when you follow the link to a feed is a GET.

Yep. But why would you do the GET in the first place? In what use case  
scenario would you put GET-ing an URI that returns an Atom Entry compared  
to one that returns an Atom Feed?

> Your agent then decides if subscribing to that resource is a good idea.

How does it decide? By parsing the whole document first, e.g. content  
sniffing?

> To make that decision, the agent has to look at the representation and

Not if the resource needn't be GET in the first place. If the whole  
operation can be decided upon the Content-Type returned in a HEAD request,  
or even better; by the value in the @type attribute of whatever element  
referring to this resource, the client won't have to do a GET at all on  
resources it doesn't know how to handle properly. Most feed readers knows  
how to handle feeds, but have no idea how to handle entries.

When pointed at a URI they can say "Hey, I can't subscribe to this!" if  
the Content-Type is 'text/html', 'application/octet-stream' or whatever,  
but if the Content-Type is 'application/atom+xml', they think "Hey, this  
is a feed I can subscribe to!" and will in most cases fail because what  
they're trying to subscribe to isn't an Atom Feed but an Atom Entry.

Knowing before the GET whether the resource can be subscribed to (or  
whatever you may want to do with either entries or feeds separately) or  
not is useful information. And please note that "subscribe" is used here  
as a single use-case for the endless amounts of use-cases that will differ  
for Atom Feeds and Atom Entries.

> Anyhow, why not monitor a single entry?

That's of course possible, but you will be monitoring indirectly if you're  
subscribing to a feed that has that entry and changes to that entry gets  
re-published to the same feed. However, that's not the issue at hand here.

> I think this is far more a user agent configuration issue than it is a
> problem of the media type being returned.

I disagree.

> FWIW, I think the question of media type (or the feed-ness of some  
> resource) and the issue of whether to subscribe or not are completely  
> orthogonal.

They are and they aren't.

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 6 Dec 2006 23:26:10 +0100

On Dec 6, 2006, at 11:01 PM, Asbjørn Ulsberg wrote:

> Perhaps, but it describes one of the most important use-cases with  
> feeds -- which won't be the one with entries.

Sorry, I do not understand what you mean.

>> agent.
> Yep. But why would you do the GET in the first place? In what use  
> case scenario would you put GET-ing an URI that returns an Atom  
> Entry compared to one that returns an Atom Feed?

Again, sorry, I am unable to see what you are trying to tell me. Can  
you explain?

>> idea.
> How does it decide? By parsing the whole document first, e.g.  
> content sniffing?

Not sniffing, but parsing. This would be done anyhow, no? You get  
back a doc element object, look at the name of the root elemet and  
dispatch.

> operation can be decided upon the Content-Type returned in a HEAD  
> request, or

Ok, HEAD would save the extra payload, but....I still think the  
reason for subscribing is NOT how the representation at the other end  
looks, it is based on the link semantics.

> even better; by the value in the @type attribute of whatever  
> element referring to this resource, the client won't have to do a  
> GET at all on resources it doesn't know how to handle properly.

This would be against Web arch: Content-Type is authoritative and can  
well overide whatever the type attribute says or said a year ago.

> Most feed readers knows how to handle feeds, but have no idea how  
> to handle entries.

So they should be fixed, should they not? They seem to only have  
implemented half a media type.

>
> When pointed at a URI they can say "Hey, I can't subscribe to this!"

What about chaging that to have them open a 'select plugin for this  
media type' dialog? How come the desire for making the user agent  
rely on a certain, rather limited circumstance (getting a <feed>).  
Shouldn't Web agents be more actively-trying?

> if the Content-Type is 'text/html', 'application/octet-stream' or  
> whatever, but if the Content-Type is 'application/atom+xml', they  
> think "Hey, this is a feed I can subscribe to!"

Then they implemented the RFC incorrectly I'd say.

> and will in most cases fail because what they're trying to  
> subscribe to isn't an Atom Feed but an Atom Entry.

Again, why be so defensive? If your browser behaved like that you'd  
kick it out (I'd do so at least).
>
> Knowing before the GET whether the resource can be subscribed to  
> (or whatever you may want to do with either entries or feeds  
> separately) or not is useful information.

Ok, but it is simply not authoritative.

> And please note that "subscribe" is used here as a single use-case  
> for the endless amounts of use-cases that will differ for Atom  
> Feeds and Atom Entries.

That is one of the concerns I have: subscribing is just *one* use  
case...and not even an Atom specific one.

> That's of course possible, but you will be monitoring indirectly if  
> you're subscribing to a feed that has that entry and changes to  
> that entry gets re-published to the same feed. However, that's not  
> the issue at hand here.
>
>> resource) and the issue of whether to subscribe or not are  
>> completely orthogonal.
>

Then, in what sense are they not orthogonal???

[good discusion anyhow :-)]

Jan

---

From: James M Snell <[email-masked]>
Date: Wed, 06 Dec 2006 14:30:27 -0800

> implemented half a media type.

The half they're interested in.  Why aren't they interested in the other
half?

- James

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 6 Dec 2006 23:37:08 +0100

> The half they're interested in.  Why aren't they interested in the  

Ha! Forget about the media type - let's drop entry documents.

Jan

---

From: James M Snell <[email-masked]>
Date: Wed, 06 Dec 2006 14:44:20 -0800

I certainly hope you're kidding about dropping entry docs.  Let's just
label 'em differently and move on.

- James

---

From: Antone Roundy <[email-masked]>
Date: Wed, 6 Dec 2006 17:17:21 -0600

On Dec 6, 2006, at 4:26 PM, Jan Algermissen wrote:
> So they should be fixed, should they not?

If the purpose of a feed reader is to subscribe to feeds and bring  
new and updated entries to the user's attention, then if they don't  
also handle the monitoring of single entry documents (interesting to  
some people in some cases, but I doubt interesting to most people),  
that's not necessarily something that needs fixing.

> They seem to only have implemented half a media type.

...or they've implemented all of what should be covered by one media  
type.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 7 Dec 2006 07:43:46 +0100

* Jan Algermissen <[email-masked]> [2006-12-06 20:55]:
> But that is an issue of linking semantics, not link target
> media types. I'd expect the user agent to look for links with
> 'here is a feed' semantics instead of looking for (arbitrary)
> links to certain media types.
> 

It seems pointless for atom:link to have a type attribute at all
then. You should be able to decide anything you need to decide by
GETting the resource (and sometimes parsing it). Why did we add
such a useless feature to the spec?

Regards,

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 7 Dec 2006 08:22:50 +0100

> such a useless feature to the spec?

I am pretty sure it wasn't added for being able to tell people:  
"Look, at the other end of this link is a feed".

Seriously: how many feed readers are out there that base the decision  
wheter something is subscribeable on the type attribute of a link  
rather then on the link type?

As an analogy: HTML browsers look for stylesheets where it says

    <link rel="stylesheet" type="text/css" href="/style.css" />

and not

    <link rel="alternate" type="text/css" href="/style.css" />

Eh?

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 7 Dec 2006 08:27:41 +0100

On Dec 6, 2006, at 11:44 PM, James M Snell wrote:

>
> I certainly hope you're kidding about dropping entry docs.

Sure, yes. But your wording IMHO seemed to imply that what feed  
readers do should guide a decision. So, given they are not interested  
in the entries, dropping them is not too farfetched, is it?

> Let's just

I still do not see the use cases justifying a new media type - it  
might be the right thing to do but for the time being it looks like a  
workaround.

Jan

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 07 Dec 2006 07:41:19 +0000

Jan Algermissen wrote:
> Sure, yes. But your wording IMHO seemed to imply that what feed readers
> do should guide a decision. So, given they are not interested in the
> entries, dropping them is not too farfetched, is it?
> 
> 
>> Let's just
> I still do not see the use cases justifying a new media type - it might
> be the right thing to do but for the time being it looks like a workaround.

Considering you seem to only discuss their value from a feed reader
point of view, I'm not surprised you don't see the use for at least
minting the current media-type, let alone an entirely new one.

I think at this stage having further discussion won't help anymore and I
would like the WG-chairmans and editors to tell us what they think about
this issue because we aren't going anywhere right now.

- Sylvain

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 7 Dec 2006 08:55:13 +0100

On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote:

> point of view

Hmm, strange. Feed readers are actually the last thing I am thinking  
about wrt Atom (no intention to show disrespect for the blogosphere  
of course).

Jan

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 7 Dec 2006 09:13:45 +0100

>    <link rel="alternate" type="text/css" href="/style.css" />

What do browsers do with this?

    <link rel="stylesheet" href="/style.css" />

And what with this?

    <link rel="stylesheet" type="text/plain" href="/style.css" />

Is their behaviour right? Wrong? Why?

Regards,

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 7 Dec 2006 09:31:32 +0100

[CC'ing the WHATWG list]

> rather then on the link type?

Every one?
Oh, they also look at the rel="alternate", but I'm pretty sure they
won't "process" the link if the 'type' attribute is absent, and they
don't "process" it if it's present with a value different from the
Atom or RSS media type.

>     <link rel="alternate" type="text/css" href="/style.css" />

Let's take two files, index.html and style.css. Now, let's describe
the relationship between them.
What is style.css wrt index.html? a stylesheet that browsers should
use to present index.html.
What is index.html wrt style.css? a page that uses style.css as a stylesheet.
The relation really *is* "stylesheet" (when taken from the page to the
stylesheet), whether it is written in CSS, XSLT->XSL-FO, DSSSL, etc.

Now, let's take a "blog entry page" and the "blog feed" and try to
describe the relationship between them.
What is the blog entry page wrt the blog feed? a resource that is
being or has been linked from the feed as one of its "items". If you
see a feed as a set of entries not restricted to the limited set
exposed by its representations, the entry is still part of the feed.
What is the blog feed wrt the blog entry page? a feed (set of entries,
bla bla bla) which is linking or has been linking to the entry page as
one of its "items".
The relation in this case is "feed" (when taken from the entry page to
the feed; note that rel="feed" here is *not* the same as the one from
the current HTML5 draft). What's clear is that it is not "alternate",
as used today for feed autodiscovery.
This rel="feed" is IMO useful because that's what people are generally
looking at when they want to "subscribe to a site" and are not already
looking at an "HTML feed": where's the feed which contains this item?

Last example, in two parts:
Let's start with Mozillazine's homepage and its Atom0.3 feed; they are
clearly rel="alternate" representations of the same thing: a feed (set
of entries, bla bla bla). The HTML version also contains sidebars with
additional information, but they're not part of the "main content".

Now, let's take, say the Mozilla.org homepage. It is linking to
Mozillazine and its feed. I don't know how we could describe the
relationship between Mozilla.org and Mozillazine and that's not the
point here, so let's call it "X".
If Mozilla.org is linking to Mozillazine using rel="X" and given that
Mozillazine's homepage and Atom0.3 feed are alternates; Mozilla.org
should also be linking to Mozillazine's Atom0.3 feed using rel="X"
(which it does in an <a> in the <body> of the page, where actually it
uses no rel="" at all).
So why the hell is it using rel="alternate"? (in a <link> in the
<head> section).
As Mozillazine's Atom0.3 feed is an alternate representation of the
Mozillazine's homepage, does it mean that Mozilla.org and Mozillazine
also are rel="alternate"? I'd say no, however that's what
rel="alternate" implies (it has been re-enforced in HTML5 that
rel="alternate" is transitive).

If rel="" on <a> and <area> had a default value (let's say
rel="related"), then this value could be used in the required rel=""
attribute of <link> when linking to feeds which are neither
rel="alternate" or rel="feed" (with the definition given above, *not*
the one from HTML5):
   <link rel="related" href="http://www.mozilazine.org/atom.xml"
         type="application/atom+xml" title="Mozillazine News">

My last point: if the rel="feed" as described above seems useless,
then I'm not opposed to having a rel="feed" "marker" as defined in the
current HTML5 draft, with an addition: that this "feed" marker be
"combinable" with any link rel: rel="feed alternate", rel="feed up",
rel="feed index", etc. (and at the condition that it is explicitely
defined as a "marker" and not as a relationship; rel="prefetch" and
rel="nofollow" would also need this distinction).

-- 
Thomas Broyer

---

From: "Franklin Tse" <[email-masked]>
Date: Thu, 7 Dec 2006 16:46:05 +0800

> <link rel="stylesheet" href="/style.css" />

Browsers should get the /style.css, check the Content-Type field of the HTTP Response Header and determine whether they support the stylesheet or not.

> <link rel="stylesheet" type="text/plain" href="/style.css" />

If browsers support text/plain as a stylesheet, they should get the /style.css and use the Content-Type field of the HTTP Response Header to confirm whether they really support the stylesheet.

If browsers do not support text/plain as a stylesheet, they should just simply ignore <link rel="stylesheet" type="text/plain" href="/style.css" />.

Franklin Tse

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of A. Pagaltzis
Sent: Thursday, December 07, 2006 16:14
To: [email-masked]
Subject: Re: PaceEntryMediatype

And what with this?

Regards,

---

From: "Daniel E. Renfer" <[email-masked]>
Date: Thu, 7 Dec 2006 03:57:20 -0500

People in this thread keep asking for a use case where one would want
to have a separate mediatype for both feeds and entry documents, so
here is my attempt at providing one.

I view a web page (blog post) that defines the proper link tags to
both the Atom Entry for the current post, and the Atom Feed for all
the posts on that blog. These links have the proper type and rel
information attached to each respective links. No problem there, the
browser can decide what to do with those links based off rel
information alone.

Now, in the template of this page, the author also includes standard
html anchors to these two resources for the benefit of users using a
browser that doesn't understand Atom Entries let alone Atom Feeds.
He's linked the feed to a png image of the standard feed icon, and a
similar image for the Entry. These anchors have @href attributes, but
no @type or @rel information.

I have two programs on my system; A feed reader, which I use to
subscribe to Atom Feeds, but has a very limited support for Entry
documents; and an APP Editor, which allows me to create and edit Atom
Entries, but has limited support for Feeds.

If I click on one of these two links on the page, I want that resource
to be handled by it's respective program. If these two documents were
each to be served with a different mediatype, then it is trivial to
tell my OS/Browser to send the Feeds to my feed reader, but send my
Entries to my editor.

As it stands right now, there would be no way to do this aside from
having a third program taking in both, sniffing the content and
sending the document to the appropriate program. This is a horrible
solution.

The @rel attribute is still useful. The @rel exists to tell the
browser what to do with the document, the @type exists to say what
that document actually IS.

I dislike the idea of using ;type=[feed|entry] mostly because I'm
afraid that this information will far too likely be either diregarded
or dropped. Also, once Entries become their own type, the next logical
step would be to have something like:

application/atom.entry+xml;type=xhtml
application/atom.entry+xml;type=html
application/atom.entry+xml;type=text
application/atom.entry+xml;type=markdown
etc...

Of course, let's reach a consensus on this issue before that
particular can of worms gets opened up.

Daniel E. Renfer
http://kronkltd.net/

---

From: "'A. Pagaltzis'" <[email-masked]>
Date: Thu, 7 Dec 2006 10:51:41 +0100

* Franklin Tse <[email-masked]> [2006-12-07 10:00]:
> If browsers do not support text/plain as a stylesheet, they
> should just simply ignore <link rel="stylesheet"
> type="text/plain" href="/style.css" />.

Exactly.

Regards,

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 07 Dec 2006 04:58:55 -0800

>tell my OS/Browser to send the Feeds to my feed reader, but send my

Ok, that is IMO heading in the right direction. This example makes sense 
because it strongly emphasizes a difference between feeds and entries,
saying feeds are for viewing collections and entries are more or less for
editing web resources (if we include the media resource case).

If the Atom specs never considered feed readers to be dealing with individual
entries  anyhow (at least that is the impression I get by now) then having
a new media type does indeed make sense.

Question to Atom editors and others involved with the specs: What was the intention
behind having entry documents in Atom in the first place?

Thanks,
Jan

---

From: Henry Story <[email-masked]>
Date: Thu, 7 Dec 2006 11:15:48 -0800

Just to say that I strongly agree with Jan's points below. We should  
work to use the link relation type properly, and not get dazzled by  
the current misuse of the alternate relation.

I have been wondering if there would not be a case for different mime  
types if one wanted to place a number of representations at the same  
url.

One could for example have the following at the same place:

- an html version of a blog post
- an <entry> representation of that blog post
- a <feed> for the history of changes to that blog post

That would suggest having different media types because one could not  
place them at the same location if one only has application/atom 
+xml . That does not decide the issue as to whether it is a good idea  
to do so.

For the moment I find the application/atom+xml;type=entry application/ 
atom+xml;type=feed more appealing than the other new media types by  
the way.

On the other hand having different mime types for every document  
format is also crazy. If someone invents a doc to describe cats, and  
someone else a doc to describe mice, are they going to need a new  
mime type? And what about a doc to describe policemen, and a doc to  
describe people? We could end up quickly with an infinite number of  
mime types which clearly would not help interoperability.

Henry

On 6 Dec 2006, at 23:22, Jan Algermissen wrote:
> Seriously: how many feed readers are out there that base the  
> decision wheter something is subscribeable on the type attribute of  
> a link rather then on the link type?
>

On 6 Dec 2006, at 11:42, Jan Algermissen wrote:
> But that is an issue of linking semantics, not link target media  
> types. I'd expect the user agent to look for links with 'here is a  
> feed' semantics instead of looking for (arbitrary) links to certain  
> media types.
>

I completely agree.

> On 6 Dec 2006, at 14:26, Jan Algermissen wrote:
>> Not if the resource needn't be GET in the first place. If the  
>> whole operation can be decided upon the Content-Type returned in a  
>> HEAD request, or
>>
>
> reason for subscribing is NOT how the representation at the other  
> end looks, it is based on the link semantics.

---

From: James M Snell <[email-masked]>
Date: Thu, 07 Dec 2006 11:37:22 -0800

Content types are only useful when they help to differentiate how a
document is to processed.  If it was all about the format we could have
just used application/xml all along.  IMHO, There is already sufficient
evidence that entry documents and feed documents are processed
differently and thus deserve different content types.

- James

Henry Story wrote:
> work to use the link relation type properly, and not get dazzled by the
> current misuse of the alternate relation.
> 
> types if one wanted to place a number of representations at the same url.
> 
> place them at the same location if one only has application/atom+xml .
> That does not decide the issue as to whether it is a good idea to do so.
> 
> For the moment I find the application/atom+xml;type=entry
> application/atom+xml;type=feed more appealing than the other new media
> types by the way.
> 
> On the other hand having different mime types for every document format
> is also crazy. If someone invents a doc to describe cats, and someone
> else a doc to describe mice, are they going to need a new mime type? And
> what about a doc to describe policemen, and a doc to describe people? We
> could end up quickly with an infinite number of mime types which clearly
> would not help interoperability.
> 
> Henry
> 
> 
>> I am pretty sure it wasn't added for being able to tell people: "Look,
>> at the other end of this link is a feed".
>>
>> Ok, HEAD would save the extra payload, but....I still think the reason
>> for subscribing is NOT how the representation at the other end looks,
>> it is based on the link semantics.
> 
>

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 07 Dec 2006 20:39:12 +0100

> editing web resources (if we include the media resource case).

Yay, the discussion is progressing! :)

> If the Atom specs never considered feed readers to be dealing with  
> individual entries  anyhow (at least that is the impression I get by
> now) then having a new media type does indeed make sense.

Yes indeed.

> Question to Atom editors and others involved with the specs: What was  
> the intention behind having entry documents in Atom in the first place?

I don't remember all about the original discussion, but here's three of my  
entries from back in the days:

<http://www.imc.org/atom-syntax/mail-archive/msg04647.html>
<http://www.imc.org/atom-syntax/mail-archive/msg04386.html>
<http://www.imc.org/atom-syntax/mail-archive/msg08599.html>

Although the topics in which the messages appear are unrelated, they all  
talk about the same thing, namely having Atom Entries as first-class web  
citizens. Back then, reaching this goal was enough of a struggle; defining  
Atom Entries' own MIME type was unthinkable.

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 7 Dec 2006 22:29:36 -0500

> serve a different purpose.

Makes sense.  I forgot that entry documents were used for creation in APP.

But serving different purposes does not necessitate a different media
type.  Both Firefox and Googlebot are voracious consumers of text/html
documents, yet for very different purposes.

Mark.

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 8 Dec 2006 12:06:12 -0500

On 12/5/06, James M Snell <[email-masked]> wrote:
>>Mark Baker wrote:
>> It's just an entry without a feed.  You'd use the same code
>> path to process that entry whether it were found in an entry
>> or feed document, right?
> Not necessarily... The majority of applications that most
> frequently handle Atom Feed Documents have no idea how
> to deal with Atom Entry Documents and I would wager that
> most applications that understand how to process Atom Entry
> Documents and Atom Feed Documents typically don't fall into
> the same category as most feed readers.
    What you seem to be implying is that the majority of applications that
process Atom Feed documents are not, in fact, supporting extremely important
parts of the atom specification. I believe that any properly constructed
Atom Feed parser will contain all the code needed to parse the most complex
Atom Entry document. And, an entry document with an atom:source is
semantically equivelant to an atom:feed with a single entry...  The problem
here is that people insist on building Atom parsers that aren't capable of
handling more semantics than legacy RSS. What we should be doing is
encouraging people to exploit Atom and use its features -- atom:source among
others -- that aren't supported by RSS.
     For a parser that properly handles the case of an atom:entry appearing
within atom:feed, it should be trivially simple code to recognize  and
handle an entry without a feed wrapper. I think there are even cases where
this makes sense -- and you would even want to subscribe to such a thing:
    Consider a "feed" that communicates "current weather" or "current stock
price", etc. We wouldn't be surprised if such a "feed" never contained more
than a single entry. We also wouldn't be surprised if the publisher of this
single entry feed decided that he wanted to sign the entry in this
single-entry-feed and was thus forced to insert all of the feed data into
the entry's atom:source. Of course, once you've got a single-entry Atom feed
which contains a signed entry, you have all the feed data duplicated -- so,
it wouldn't be surprising to see authors of such feeds argue that they
shouldn't be forced to waste bits on duplicated feed data when an atom entry
document provides exactly what they need.
    In any case, while it appears reasonable (and sometimes efficient) for
people to subscribe to Entry documents, I don't think we should do anything
disruptive unless someone can establish actual harm being caused by the
current state of affairs.

bob wyman

---

From: James M Snell <[email-masked]>
Date: Fri, 08 Dec 2006 09:52:05 -0800

I'm fine with the type parameter approach so long as it is effective.
By effective I mean: Will existing implementations actually take the
time to update their behavior to properly handle the optional type
parameter.

- James

Bob Wyman wrote:
>[snip]
>      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

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 8 Dec 2006 12:03:28 -0500

On 11/30/06, James M Snell <[email-masked]> 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

---

From: James M Snell <[email-masked]>
Date: Fri, 08 Dec 2006 09:49:39 -0800

Bob Wyman wrote:
>[snip]
>     What you seem to be implying is that the majority of applications
> that process Atom Feed documents are not, in fact, supporting extremely
> important parts of the atom specification. I believe that any properly
>[snip]

Not quite.  What I'm implying is that not all applications have the need
to implement the entire specification.  Atom Entry Documents and Atom
Feed Documents are each very useful but for different reasons.

> constructed Atom Feed parser will contain all the code needed to parse
> the most complex Atom Entry document. And, an entry document with an
> atom:source is semantically equivelant to an atom:feed with a single
> entry...  The problem here is that people insist on building Atom
> parsers that aren't capable of handling more semantics than legacy RSS.
> What we should be doing is encouraging people to exploit Atom and use
> its features -- atom:source among others -- that aren't supported by RSS.

+1 on all points.

>      For a parser that properly handles the case of an atom:entry
> appearing within atom:feed, it should be trivially simple code to
> recognize  and handle an entry without a feed wrapper. I think there are
> even cases where this makes sense -- and you would even want to
> subscribe to such a thing:

Trivial, yes.  That's not really the issue for me.

>[snip]
>     In any case, while it appears reasonable (and sometimes efficient)
> for people to subscribe to Entry documents, I don't think we should do
> anything disruptive unless someone can establish actual harm being
> caused by the current state of affairs.
> 

The fact that I cannot link to an Atom Entry Document from a browser
without it trying (and failing) to process it as a Feed Document is harmful.

- James

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 8 Dec 2006 23:48:06 +0100

On Dec 8, 2006, at 6:49 PM, James M Snell wrote:

> to implement the entire specification.

At this point it would be a really good idea to be clear about the  
original
intention of the specification and then propably align the specs with  
that
as opposed to having software that only implements half of a specs.
People out there might be caused to think this is good practice....

Jan

---

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

On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen  
<[email-masked]> wrote:

> But that is an issue of linking semantics, not link target media types.

Wrong. The link relation 'alternate' is perfectly valid for both Entry and  
Feed documents, depending on what type of resource they are linked from.  
An index page of a website can have an 'alternate' relation to an Atom  
Feed, while an individual article page (or "entry" page) can have an  
'alternate' relation to an Atom Entry. Both link relations are identical,  
but the client has absolutely no clue before it GETs the URI whether what  
sits on the other end is an Atom Feed or an Atom Entry.

Let's take Firefox as an example of a feed reader. When you browse to a  
page saying it has 'alternate' resources, you get a nice little orange  
"subscribe" button in the address field. Pushing it makes you a subscriber  
of that alternate resource. On an index page, that's fine, because the  
"alternate" resource is an Atom Feed. However, on an individual article  
page, Firefox will still display the "subscribe" button although it  
doesn't support subscribtion to the resource and subscribing to it in the  
first place doesn't make much sense.

Wouldn't it be a better experience to not get the "subscribe" button on  
the article page at all? Or do you prefer that it's there and that you  
need to press it and get an error message (that you most probably won't  
understand if you're not a technical user like you and me) to know that  
you can't subscribe to this alternate resource after all? What do you  
think?

> I'd expect the user agent to look for links with 'here is a feed'  
> semantics instead of looking for (arbitrary) links to certain media  
> types.

The 'alternate' relation is fine for both uses. However, the WHATWG  
propsed 'feed' relation is a bit more explicit on the "subscribe to me"  
part. Still, an Atom Feed can be 'alternate' of an index page just as an  
Atom Entry can be 'alternate' of an article page. People shouldn't be  
forced to use the 'feed' relation, and I highly doubt that the widely  
deployed 'alternate' relation can be replaced that easilly.

---

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

> current misuse of the alternate relation.

This problem isn't only with link relations. Or, if it is, it demands that  
all existing and future link relations remain different for Feed and Entry  
documents, since the use cases and processing of the documents will  
differ. Although the relations themselves might actually be the same,  
semantically speaking, they need to be named differently because  
processing an entry with that relation is different from processing a feed  
with that relation. Should we expand the relations with a 'type' attribute  
instead? (/irony)

> place them at the same location if one only has application/atom+xml .

Another good example.

> That does not decide the issue as to whether it is a good idea to do so.

I think it adds more weight to the "we need a new MIME type" scale.

> atom+xml;type=feed more appealing than the other new media types by the  
> way.

So do I.

> is also crazy.

A new MIME type is useful when the processing of the resource differs and  
at least knowing this beforehand is substantial information. Knowing this  
for Atom Entry documents is substantial imo.

---

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

> differently and thus deserve different content types.

Indeed. +1.

---

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

> time to update their behavior to properly handle the optional type

Seeing how eager most applications have been to implement Atom support, I  
believe the answer to this question is "yes". I'm optimistic at least.

---

From: "Mark Baker" <[email-masked]>
Date: Sat, 9 Dec 2006 00:40:22 -0500

On 12/8/06, Asbjørn Ulsberg <[email-masked]> wrote:
> 'alternate' relation to an Atom Entry.

As it can to a feed with one entry.

> Both link relations are identical,

Nor should it need to distinguish, just like it doesn't need to
distinguish between a feed with multiple entries, versus one with one
entry.

Mark.

---

From: Henry Story <[email-masked]>
Date: Fri, 8 Dec 2006 22:16:41 -0800

I can see a reason to distinguish more strongly between a feed and an  
entry. And this is with regards to creating new collections.

The best way I see to create a new collection would be to POST a   
<feed> </feed> containing no entries to a collection end point.  
Though that is very similar to POSTing an <entry> I think the  
distinction is worth preserving at that point.

I am not sure if this has any bearing on mime types though.

Henry

---

From: Jan Algermissen <[email-masked]>
Date: Sat, 9 Dec 2006 12:57:57 +0100

On Dec 9, 2006, at 6:40 AM, Mark Baker wrote:

On 12/8/06, Asbjørn Ulsberg <[email-masked]> wrote:

> Nor should it need to distinguish

Asbjørn, the link is to the resource, not a particular representation  
of it.
The media type is just a hint, what you get upon a GET can vary and
your client should prepare for that.

You can make use of that hint, but it does in no way tell you what the
actual media type is you'll get upon a GET; it is not authoritative,
the Content-Type header is.

What you can rely on is that the server uses the correct link  
relation. IOW,
that the server informs you about the relationship correctly, that it  
does not
tell you X is an alternate of A if it isn't.

Something else:

Suppose there were two representation formats for atom feeds one in  
XML and
one in some space optimized text format. Conceptually they server up  
the same
information - what type goes into the type attribute?

And yet in other words:

Media type are telling you hw to process a representation, not of  
what kind the
resource is (resources are not typed, BTW).

Jan

---

From: Henry Story <[email-masked]>
Date: Sat, 9 Dec 2006 10:27:15 -0800

On 9 Dec 2006, at 03:57, Jan Algermissen wrote:
> Asbjørn, the link is to the resource, not a particular  
> representation of it.

This is a problem that has been concerning me for a while.

In Atom Owl I have been toying with representing a link relation as  
pointing to a representation, by thinking of it as follows
or in N3

[] :alternate [ a :Content;
                 a:type "text/html";
                 a:length 600;
                 :src <http://eg.info/post1>;
               ] .

[] :entry [ a :Content;
             a:type "application/atom+xml";
             a:length 700;
             :src <http://eg.info/post1>;
           ] .

This way of doing things is looking at representations as linking to  
each other, and that is probably what a lot of people dealing with  
representations are thinking. I like it, but I am also finding it  
very difficult to decide the issue.

The other way of seeing things is to apply the properties to the  
resources.  If we look at this from a web architectural point of view  
with a URI "http://eg.info/post1" naming a resource (the circle  
below) which returns two representations, one in html and one in xml  
we get the following diagram.

I have changed the name of the relations to make a point that we are  
not here trying to decide which of a:type or b:type is correct. They  
are both equally valid relations. But as is clear from the above  
diagram the value of the b:length relation is slightly lost.  
Attaching the b:length relation to the resource cannot help decide  
the issue of which representation to choose, since we don't know  
which representation that length is associated with.

In N3 we could express the above graph as

<http://eg.info/post1> b:length 700, 600;
                        b:type "text/html", "application/atom+xml";
                        b:alternate <http://eg.info/post1>;
                        b:entry <http://eg.info/post1>.

> that the server informs you about the relationship correctly, that  
> it does not
> one in some space optimized text format. Conceptually they server  
> up the same

Now I completely agree with you that I think that both mime type and  
link relation type are very important. For some reason different  
people in this group only want to see part of the elephant. If we  
don't know how another document is linked to the current one, the  
information is not particularly helpful. We might as well have used  
an <a href="">...</a> anchor. We would get a little metadata there  
through the containing text, but this would not be very machine  
processable.

> resource is (resources are not typed, BTW).

I think one can make a case that a media type is a class of  
representations. Resources can be typed by the way.
For example see my foaf name. The following is true:

<http://bblfish.net/people/henry/card#me> a foaf:Person .

I am a person. (And to some that may come as a revelation. ;-)

Henry

> Jan

Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
Foaf name: http://bblfish.net/people/henry/card#me

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 9 Dec 2006 19:46:50 -0500

> time to update their behavior to properly handle the optional type

It would be useful to define better what is meant by "properly handle the
optional type parameter." Those that don't understand the parameter should
simply continue to operate on the current assumption that they can't really
be sure if they are reading a feed or an entry until they read the first few
bytes. Those that do understand the meaning of the optional parameter will
be writing code in the future and we can hope that if they become aware of
the type parameter and decide to care about it, they will have sufficient
awareness to do whatever they do in a "proper" manner.

The only case where I can see a problem would be those folk who match
against the existing media type as an opaque string and don't have any code
to handle opional type parameters. Such sloppy code would be broken by the
use of the optional type parameters since the presence of the parameter
would break the simple string matches used by these coders. However, I must
admit that I don't have much sympathy for such folk. Making basic design
decisions to adress the concerns of these sloppy folk is something like the
old prejudice against using XML attributes since it tended to make it harder
to create sloppy, regex based parsers... In any case, the alternative
proposal, create a new media type for entries, would tend to confuse people
who have their code written properly today --- those whose code understands
that the existing atom mediatype can be used for both a feed and and entry.
What we would be doing by creating a new media type is break the code of the
folk who paid attention to the spec in order to preserve the code of those
who didn't read the spec (or those who refused to see Atom as anything other
than some twisted form of RSS...) This doesn't make sense to me. We should
use the type parameter if anything is changed here.

bob wyman

---

From: James M Snell <[email-masked]>
Date: Sun, 10 Dec 2006 11:12:53 -0800

Bob Wyman wrote:
> against the existing media type as an opaque string and don't have any
> code to handle opional type parameters. Such sloppy code would be broken
> by the use of the optional type parameters since the presence of the
> parameter would break the simple string matches used by these coders.

Well, quite a few don't even seem to account for uppercase or mixed case
media types.

> However, I must admit that I don't have much sympathy for such folk.

Ditto

> Making basic design decisions to adress the concerns of these sloppy
> folk is something like the old prejudice against using XML attributes
> since it tended to make it harder to create sloppy, regex based
> parsers... In any case, the alternative proposal, create a new media
> type for entries, would tend to confuse people who have their code
> written properly today --- those whose code understands that the
> existing atom mediatype can be used for both a feed and and entry. What
> we would be doing by creating a new media type is break the code of the
> folk who paid attention to the spec in order to preserve the code of
> those who didn't read the spec (or those who refused to see Atom as
> anything other than some twisted form of RSS...) This doesn't make sense
> to me. We should use the type parameter if anything is changed here.
> 

Like I said before, I'm definitely not against the type param approach
so if that's what the majority of folks want, then I'm happy with that.

- James

---

From: Bill de hOra <[email-masked]>
Date: Sun, 10 Dec 2006 21:10:21 +0000

Bob Wyman wrote:

> entry...  

Yet that's an optional semantic (which we could argue means it's not 
semantically significant). This argument that entries are feed aliases 
all feels like coulda woulda shoulda to me. I mean was this not 
discussed and dealt with during the RFC's development?

cheers
Bill

---

From: "Bob Wyman" <[email-masked]>
Date: Sun, 10 Dec 2006 17:28:35 -0500

On 12/10/06, Bill de hOra <[email-masked]> wrote:
>
> This argument that entries are feed aliases

This was, in fact, discussed on frequent occasions, but with different
terminology. Personally, I don't like this "alias" terminology... What we're
talking about here is equivalence. The term "alias" is usually used in the
context of naming. If we were to use a term other than "equivalence" I think
it would be better to talk about "feed proxies" since a "proxy" is often
used to indicate one thing that can stand for another thing.

The semantic equivalence between an atom:feed and an atom:entry (if it
contains an atom:source) is an essential requirement for the proper
functioning of aggregators and for streamers (such as those anticipated by
"Atom over XMPP" [1]).

In part, the need for this equivalence originates in the *wise* decision to
avoid supporting the recursive hell that would have resulted from permitting
"feeds of feeds." The problem being addressed is that some systems need to
present "feeds" which are composed of entries extracted from other feeds.
This is a non-trivial problem since some of the semantics of an entry is
derived from data external to the entry -- i.e. data recorded in feed-global
elements. Since we cannot say a prioi what part of the feed's data is
relevant to proper interpretation of the entry, we must have a mechanism for
including in an entry enough data so that the entry is, in fact,
semantically equivalent to a feed containing a single entry.

There are at least four elements of the Atom syntax specification that are
relevant here. First, is that discussed above. We have the atom:source
element which allows feed data to be encapsulated within an entry. Second,
the atom syntax states that there should be no semantics implied by the
order between items in a feed. This second element is important in that it
permits an entry to be isolated from a feed without any loss of data or
semantics. If inter-entry order within a feed was significant, then we would
have to support "Feeds of Feeds" when producing aggregate feeds. We couldn't
simply extract a single entry, we'd have to insert all entries "around" the
extracted entry in order to preserve the information content of the
extracted entry.

I believe the equivelance between an entry and a single-entry feeds is also
strengthened by the fact that we have the top-level atom:entry in the first
place. An atom entry is not "complete" without feed data, thus, if we
support an atom:entry in isolation, we're implying that it must be possible
to construct an entry which is semantically equivalent to a singe-entry
feed.

I should also mention that the support for signing an entry within a signed
feed is also important to the aggregation and streaming cases while also
strengthening the ability of an entry to serve as a proxy for a single-entry
feed. If we weren't supporting aggregate feeds, there would be less of a
requirement to support signed entries in signed feeds.

The following aspects of the atom-syntax spec work together to make "proper"
aggregation and streaming possible without supporting "Feeds of Feeds":

    1) atom:source as a place to stash feed data
    2) Refusal to permit derivation of semantics from inter-entry sequence
    3) atom:entry as a top-level element
    4) support for signing entries which are contained in signed feeds

Although most aggregators still don't do aggregation "properly" we at least
have defined in Atom what they need if they get around to it... (We're still
stuck with people who insist on seeing equivalence between RSS and Atom.
They insist on building things the "RSS way" and then import their broken
methods into their Atom implementations. RSS, of course, does NOT provide
proper support for aggregate feeds.)

To summarize: Yes, I think this business of an entry being semantically
equivalent to a single-entry feed was discussed at great length during
development of the RFC. Those involved in the discussions will remember that
I personally argued this case on a regular (sometimes too regular...) basis.

bob wyman

[1]
http://www.xmpp.org/internet-drafts/draft-saintandre-atompub-notify-05.html

---

From: "Joe Gregorio" <[email-masked]>
Date: Sun, 10 Dec 2006 22:26:28 -0500

> a new media type does indeed make sense.

Adding an optional parameter that indicated an entry or
a feed would be a more elegant solution:

> behind having entry documents in Atom in the first place?

Having entries as documents on their own was critical
for the Atom Publishing Protocol, where you GET/PUT/POST/DELETE
Entry Documents in the course of updating a collection.

  -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Eric Scheid <[email-masked]>
Date: Mon, 11 Dec 2006 15:11:49 +1100

>  application/atom+xml;type=feed

I certainly agree it would be more elegant.

A more pragmatic solution would be to go with "application/atom.entry+xml"
... if WHATWG don't update their spec, we're safe; if anyone has implemented
per the current draft WHATWG spec, we're safe; if any implementations use
naïve string matching, we're safe. The only danger is if someone has
implemented APP per the moving target which is Draft-[n++] ... they should
revise their test implementations as the draft updates, and certainly update
once it reaches RFC status, so no sympathies there.

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 11 Dec 2006 00:07:20 -0500

On 12/10/06, Eric Scheid <[email-masked]> wrote:
> The only danger [of defining a new media type] is if someone has
implemented
> APP per the moving target which is Draft-[n++] ... they should
> revise their test implementations as the draft updates, and certainly
> update once it reaches RFC status, so no sympathies there.

The impact here is not just limited to APP implementations. If a new media
type is defined, it will undoubtedly appear in other contexts as well. Given
the current definition of the atom syntax, it is perfectly reasonable for an
"aggregator" to treat a single entry as the semantic equivelant of a
single-entry feed. If a new media type is defined, such an application would
end up having to be modified. That's not right... APP is not the only
context within which Atom is used.

bob wyman

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 11 Dec 2006 07:44:47 +0000

> context within which Atom is used.

I still don't understand the meaning of equivalence between an entry
document and a single-entry-feed document. I have read your other
message and I'm still nowhere near an understanding of it. In fine if
you accept that an entry document is just equivalent to a
single-entry-feed you have to detail precisely how this equivalence
takes place and can be measured. Is it based on the atom:id? If yes is
it on the atom:id of the entry or the feed? Is it based on its metadata?
Again which ones since an entry embedded in a feed can overwrite the
feed metadata. You should also explain why we have entry document at all
if they are equivalent to single-entry-feed ones.

Moreover you claim that it's going to break implementations. Which ones?
How? Why? Can't those applications be updated?

Why shouldn't APP be set straight because of those applications? There
is a large feeling on the WG that there could be a use for distinction
at the message level. We all acknowledge that could be disruptive but I
don't think I can agree that it would bring down a all set of applications.

You say those in favor haven't brought good use cases but neither have you.

- Sylvain

---

From: Bill de hOra <[email-masked]>
Date: Mon, 11 Dec 2006 10:03:26 +0000

Bob Wyman wrote:

> The impact here is not just limited to APP implementations. If a new 
> media type is defined, it will undoubtedly appear in other contexts as 
> well. Given the current definition of the atom syntax, it is perfectly 
> reasonable for an "aggregator" to treat a single entry as the semantic 
> equivelant of a single-entry feed. 

I don't agree. atom:source is optional, and even then that does not 
cater for situations where entries have been annotated downstream.

> If a new media type is defined, such 
> an application would end up having to be modified. That's not right... 
> APP is not the only context within which Atom is used.

What matters is whether atom:feed is the only context within which 
atom:entry is used, and/or whether atom:entry is an atom:feed in 
masquerade. After who knows how many posts and having gone back to the 
RFC, as I see it, neither of those is true or supported by the spec. 
There'll have to be another rationale presented for not spinning out a 
new media type.

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Mon, 11 Dec 2006 10:04:17 +0000

Sylvain Hellegouarch wrote:

> document and a single-entry-feed document. 

You don't need to; it doesn't exist. This is string theory for syndication.

cheers
Bill