Re: PaceEntryMediatype

[Bill de hOra]

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

Re: PaceEntryMediatype

[Bill de hOra]

Sylvain Hellegouarch wrote:


I still don't understand the meaning of equivalence between an entry
document and a single-entry-feed document. 


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

cheers
Bill

Re: PaceEntryMediatype

[Sylvain Hellegouarch]

Bob Wyman wrote:
> On 12/10/06, Eric Scheid <[EMAIL PROTECTED]> 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.

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

Re: PaceEntryMediatype

[Bob Wyman]

On 12/10/06, Eric Scheid <[EMAIL PROTECTED]> 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

Re: PaceEntryMediatype

[Eric Scheid]

On 11/12/06 2:26 PM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:

> Adding an optional parameter that indicated an entry or
> a feed would be a more elegant solution:
> 
>  application/atom+xml;type=entry
>  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.

Re: Fwd: PaceEntryMediatype

[Bob Wyman]

On 12/8/06, James M Snell <[EMAIL PROTECTED]> wrote:


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.



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

Re: PaceEntryMediatype

[Jan Algermissen]

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

On 12/8/06, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote:


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.


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

Re: PaceEntryMediatype

[Henry Story]

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   
  containing no entries to a collection end point.  
Though that is very similar to POSTing an  I think the  
distinction is worth preserving at that point.


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

Henry

On 8 Dec 2006, at 21:40, Mark Baker wrote:



On 12/8/06, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote:


On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen
<[EMAIL PROTECTED]> 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.


As it can to a feed with one 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.


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.

Re: PaceEntryMediatype

[Mark Baker]

On 12/8/06, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote:


On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen
<[EMAIL PROTECTED]> 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.


As it can to a feed with one 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.


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.

Re: Fwd: PaceEntryMediatype

[Asbjørn Ulsberg]

On Fri, 08 Dec 2006 18:52:05 +0100, James M Snell <[EMAIL PROTECTED]>  
wrote:



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.


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.


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

Re: PaceEntryMediatype

[Asbjørn Ulsberg]

On Thu, 07 Dec 2006 20:37:22 +0100, James M Snell <[EMAIL PROTECTED]>  
wrote:



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.


Indeed. +1.

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

Re: PaceEntryMediatype

[Asbjørn Ulsberg]

On Thu, 07 Dec 2006 20:15:48 +0100, Henry Story <[EMAIL PROTECTED]>  
wrote:


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.


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)



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

- an html version of a blog post
- an  representation of that blog post
- a  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 .


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.

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.


So do I.

On the other hand having different mime types for every document format  
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.


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

Re: PaceEntryMediatype

[Asbjørn Ulsberg]

On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen  
<[EMAIL PROTECTED]> 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.


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

Re: PaceEntryMediatype

[Jan Algermissen]

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

Not quite.  What I'm implying is that not all applications have the  
need

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

Re: Fwd: PaceEntryMediatype

[James M Snell]

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

Fwd: PaceEntryMediatype

[Bob Wyman]

On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote:



> The key problem with "application/atom+xml;type=entry" is that at least
> one major browser (Firefox 2.0) still treats it as a feed and shows the
> "subscribe" link. So while the type parameter is a potentially more
> elegant solution, the new media type approach would likely be far less
> disruptive.
   I don't understand the logic behind saying that it would be "far less
disruptive" to rely on the type parameter in lieu of creating new media
types. Personally, I think the type parameter is the solution to this
alleged "problem"... It appears to me that the disruption that would be
avoided by orphaning atom entries behind a "weird" new media-type is nothing
more than the effort of a minor update in a future revision of Firefox.
Prior to that update, behavior would be as it is today and frankly, that
isn't a really big problem since, as far as I can see, there haven't been
many reports of harm being caused by hordes of people accidently trying to
subscribe to atom entries.


The issues being discussed in this thread seem to be largely
hypothetical at best. Nobody has actually established that any harm is
currently being done as a result of the "ambiguity" of having both atom
document types share a single atom media type. The discussion would be a
great deal more engaging if someone could cite an actual history of issues.
Barring discovery of real, pressing problems, I think we should take the
more conservative approach of using the disambiguation tools provided by the
media-type specification -- i.e. use the type parameter. We've got more
important issues to focus on...
James suggests: "the type parameter is [a] potentially more elegant
solution." Elegance is goodness. Let's insist on elegant solutions in the
absence of compelling reasons to be inelegant.

bob wyman

Re: Fwd: PaceEntryMediatype

[James M Snell]

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

Fwd: PaceEntryMediatype

[Bob Wyman]

On 12/5/06, James M Snell <[EMAIL PROTECTED]> 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

Re: PaceEntryMediatype

[Mark Baker]

On 12/6/06, James M Snell <[EMAIL PROTECTED]> wrote:



Mark Baker wrote:
> [snip]
> 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.
>

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.


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.

Re: PaceEntryMediatype

[Asbjørn Ulsberg]

On Thu, 07 Dec 2006 13:58:55 +0100, Jan Algermissen  
<[EMAIL PROTECTED]> wrote:



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


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:






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.


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

Re: PaceEntryMediatype

[James M Snell]

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:
> 
> 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  representation of that blog post
> - a  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:
>> On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote:
>>
>>>
>>> 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?
>>>
>>
>> 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
>>
>>
>>
>> and not
>>
>>
>>
>> Eh?
>>
>> Jan
> 
> 
> 
> 
> On 6 Dec 2006, at 11:42, Jan Algermissen wrote:
>> On Wednesday, December 06, 2006, at 08:30PM, "Antone Roundy"
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:

  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:
>>
>> 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.
> 
> I completely agree.
> 
> 
>> On 6 Dec 2006, at 14:26, Jan Algermissen wrote:
 To make that decision, the agent has to look at the representation and
 the it is insignificant overhead to see if the thing returnes 
 or .

>>>
>>> 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
>>>
>>
>> Ok, HEAD would save the extra payload, butI still think the reason
>> for subscribing is NOT how the representation at the other end looks,
>> it is based on the link semantics.
> 
> 

Re: PaceEntryMediatype

[Henry Story]

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  representation of that blog post
- a  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:

On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote:



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?



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

   

and not

   

Eh?

Jan





On 6 Dec 2006, at 11:42, Jan Algermissen wrote:
On Wednesday, December 06, 2006, at 08:30PM, "Antone Roundy"  
<[EMAIL PROTECTED]> wrote:


On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:


 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:


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.


I completely agree.



On 6 Dec 2006, at 14:26, Jan Algermissen wrote:
To make that decision, the agent has to look at the  
representation and

the it is insignificant overhead to see if the thing returnes 
or .



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




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

Re: PaceEntryMediatype

[Jan Algermissen]

On Thursday, December 07, 2006, at 10:18AM, "Daniel E. Renfer" <[EMAIL 
PROTECTED]> wrote:

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

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


>
>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/
>
>On 12/7/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:
>>
>>
>> On Dec 7, 2006, at 8:41 AM, Sylvain Hellegouarch wrote:
>>
>> > Considering you seem to only discuss their value from a feed reader
>> > 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
>>
>>
>
>
>

Re: PaceEntryMediatype

['A. Pagaltzis']

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

Exactly.

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[Daniel E. Renfer]

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/

On 12/7/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:



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

> Considering you seem to only discuss their value from a feed reader
> 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

RE: PaceEntryMediatype

[Franklin Tse]

> What do browsers do with this?

> 

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.

> And what with this?

> 

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 .

Franklin Tse

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis
Sent: Thursday, December 07, 2006 16:14
To: atom-syntax@imc.org
Subject: Re: PaceEntryMediatype


* Jan Algermissen <[EMAIL PROTECTED]> [2006-12-07 08:25]:
> As an analogy: HTML browsers look for stylesheets where it says
> 
>
> 
> and not
> 
>
> 
> Eh?

What do browsers do with this?



And what with this?



Is their behaviour right? Wrong? Why?

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

Re: PaceEntryMediatype

[Thomas Broyer]

[CC'ing the WHATWG list]

2006/12/7, Jan Algermissen:


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?


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.


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



and not



Eh?


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  in the  of the page, where actually it
uses no rel="" at all).
So why the hell is it using rel="alternate"? (in a  in the
 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  and  had a default value (let's say
rel="related"), then this value could be used in the required rel=""
attribute of  when linking to feeds which are neither
rel="alternate" or rel="feed" (with the definition given above, *not*
the one from HTML5):
  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

Re: PaceEntryMediatype

[A. Pagaltzis]

* Jan Algermissen <[EMAIL PROTECTED]> [2006-12-07 08:25]:
> As an analogy: HTML browsers look for stylesheets where it says
> 
>
> 
> and not
> 
>
> 
> Eh?

What do browsers do with this?



And what with this?



Is their behaviour right? Wrong? Why?

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[Jan Algermissen]

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


Considering you seem to only discuss their value from a feed reader
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

Re: PaceEntryMediatype

[Sylvain Hellegouarch]

Jan Algermissen wrote:
> 
> 
> 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
>> label 'em differently and move on.
>>
> 
> 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

> 
> Jan
> 
> 
>> - James
>>
>> Jan Algermissen wrote:
>>>
>>> On Dec 6, 2006, at 11:30 PM, James M Snell wrote:
>>>


 Jan Algermissen wrote:
> [snip]
> So they should be fixed, should they not? They seem to only have
> implemented half a media type.
>

 The half they're interested in.  Why aren't they interested in the
 other
 half?
>>>
>>>
>>> Ha! Forget about the media type - let's drop entry documents.
>>>
>>> Jan
>>>

 - James
>>>
>>>
>>

Re: PaceEntryMediatype

[Jan Algermissen]

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
label 'em differently and move on.



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



- James

Jan Algermissen wrote:


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




Jan Algermissen wrote:

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



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

half?



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

Jan



- James

Re: PaceEntryMediatype

[Jan Algermissen]

On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote:



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?



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

   

and not

   

Eh?

Jan






Regards,
--
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[A. Pagaltzis]

* Jan Algermissen <[EMAIL PROTECTED]> [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.
> 
> IMHO, there is something going wrong somewhere - and it ain't
> the media type.

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,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[Antone Roundy]

On Dec 6, 2006, at 4:26 PM, Jan Algermissen wrote:
Most feed readers knows how to handle feeds, but have no idea how  
to handle entries.


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.

Re: PaceEntryMediatype

[James M Snell]

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

- James

Jan Algermissen wrote:
> 
> On Dec 6, 2006, at 11:30 PM, James M Snell wrote:
> 
>>
>>
>> Jan Algermissen wrote:
>>> [snip]
>>> So they should be fixed, should they not? They seem to only have
>>> implemented half a media type.
>>>
>>
>> The half they're interested in.  Why aren't they interested in the other
>> half?
> 
> 
> Ha! Forget about the media type - let's drop entry documents.
> 
> Jan
> 
>>
>> - James
> 
> 

Re: PaceEntryMediatype

[Jan Algermissen]

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




Jan Algermissen wrote:

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



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

half?



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

Jan



- James

Re: PaceEntryMediatype

[Jan Algermissen]

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

On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen  
<[EMAIL PROTECTED]> wrote:



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.


Sorry, I do not understand what you mean.




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?


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





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?


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.




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

the it is insignificant overhead to see if the thing returnes 
or .


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


Ok, HEAD would save the extra payload, butI 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 ).  
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.





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.


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


[good discusion anyhow :-)]

Jan



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

Re: PaceEntryMediatype

[James M Snell]

Jan Algermissen wrote:
> [snip]
> So they should be fixed, should they not? They seem to only have
> implemented half a media type.
> 

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

- James

Re: PaceEntryMediatype

[Asbjørn Ulsberg]

On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen  
<[EMAIL PROTECTED]> wrote:



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
the it is insignificant overhead to see if the thing returnes 
or .


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.

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

Re: PaceEntryMediatype

[James M Snell]

Andreas Sewe wrote:
> [snip]
> 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.
> 

In consider that a feature.

- James

Re: PaceEntryMediatype

[Bill de hOra]

Antone Roundy wrote:


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  
or .


...

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


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

Re: PaceEntryMediatype

[Jan Algermissen]

On Wednesday, December 06, 2006, at 08:30PM, "Antone Roundy" <[EMAIL 
PROTECTED]> wrote:
>
>On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:
>> 
>>  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:

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


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

Re: PaceEntryMediatype

[Antone Roundy]

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  or .


...

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

Re: PaceEntryMediatype

[Jan Algermissen]

>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?


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  or .

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

Re: PaceEntryMediatype

[Asbjørn Ulsberg]

On Wed, 06 Dec 2006 05:22:24 +0100, Mark Baker <[EMAIL PROTECTED]> wrote:


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.


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?


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

Re: PaceEntryMediatype

[Andreas Sewe]

James M Snell wrote:

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.


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

Re: PaceEntryMediatype

[James M Snell]

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

Andreas Sewe wrote:
> James M Snell wrote:
>> 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.
> 
> 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
> 
> 

Re: PaceEntryMediatype

[Bill de hOra]

Mark Baker wrote:


Isn't that just a case of people not implementing the whole spec
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
feed documents?


Anything based on Atom Protocol will be making a distinction.

cheers
Bill

Re: PaceEntryMediatype

[Kyle Marvin]

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

On 12/6/06, Andreas Sewe <[EMAIL PROTECTED]> wrote:



James M Snell wrote:
> 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.

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

Re: PaceEntryMediatype

[Andreas Sewe]

James M Snell wrote:
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.


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

Re: PaceEntryMediatype

[fantasai]

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'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


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

Re: PaceEntryMediatype

[James M Snell]

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

fantasai wrote:
> [snip]
> 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
>   
> without implying
>   
> and without dropping the 'type' attribute entirely (which was the other
> solution pointed out on the whatwg list).
> 
> ~fantasai
> 
> 

Re: PaceEntryMediatype

[fantasai]

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
  
without implying
  
and without dropping the 'type' attribute entirely (which was the other
solution pointed out on the whatwg list).

~fantasai

Re: PaceEntryMediatype

[A. Pagaltzis]

* Mark Baker <[EMAIL PROTECTED]> [2006-12-04 21:35]:
> 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 // 

Re: PaceEntryMediatype

[Sylvain Hellegouarch]

>
> On 12/5/06, James M Snell <[EMAIL PROTECTED]> wrote:
>> Mark Baker wrote:
>> > [snip]
>> > 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?
>> >
>>
>> 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.
>
> 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.

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

Re: PaceEntryMediatype

[Eric Scheid]

On 6/12/06 5:06 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:

>> 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. > /> ?
>> 
> 
> 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.

Re: PaceEntryMediatype

[James M Snell]

Eric Scheid wrote:
> [snip]
> 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++)?
> 

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.

> If an agent found an entry document, and then later returned to find a feed
> 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?

> 
> 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.  /> ?
> 

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

- James

Re: PaceEntryMediatype

[Eric Scheid]

On 6/12/06 4:32 PM, "Mark Baker" <[EMAIL PROTECTED]> wrote:

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

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.

Re: PaceEntryMediatype

[James M Snell]

Mark Baker wrote:
> [snip]
> 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.
> 

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
> feed documents?
> 

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

- James

Re: PaceEntryMediatype

[Mark Baker]

On 12/5/06, James M Snell <[EMAIL PROTECTED]> wrote:

Mark Baker wrote:
> [snip]
> 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?
>

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.


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.

Re: PaceEntryMediatype

[Eric Scheid]

On 6/12/06 3:52 PM, "James M Snell" <[EMAIL PROTECTED]> wrote:

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

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.  ?

e.

Re: PaceEntryMediatype

[James M Snell]

Mark Baker wrote:
> [snip]
> 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?
> 

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

Re: PaceEntryMediatype

[Mark Baker]

On 12/5/06, James M Snell <[EMAIL PROTECTED]> wrote:

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.


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.

Re: PaceEntryMediatype

[Mark Baker]

On 12/5/06, Jan Algermissen <[EMAIL PROTECTED]> wrote:

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


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.

Re: PaceEntryMediatype

[James M Snell]

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:
> 
> On Dec 5, 2006, at 9:15 PM, James M Snell wrote:
> 
>>
>> When I process this entry,
>>
>> http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0
>>
> 
> Funny, Safari switches to feed://www.google.com :-)
> 
> And then says it cannot process the entity (presumably because it is an
> ).
> 
> Jan
> 
> 
> 
> 

Re: PaceEntryMediatype

[Bill de hOra]

James M Snell wrote:

When I process this entry,

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

Re: PaceEntryMediatype

[Bill de hOra]

Mark Baker wrote:


On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote:

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


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


Mark,

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

cheers
Bill

Re: PaceEntryMediatype

[Jan Algermissen]

On Dec 5, 2006, at 9:15 PM, James M Snell wrote:



When I process this entry,

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


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

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


Jan

Re: PaceEntryMediatype

[James M Snell]

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

Mark Baker wrote:
> On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote:
>> All I can go on is evidence of how folks are actually using 'em... and
>> they ain't using 'em as aliases. :-)
> 
> Ok, I'll take empirical evidence too 8-)  Point the way ...
> 
> Mark.
> 

Re: PaceEntryMediatype

[Jan Algermissen]

On Dec 4, 2006, at 10:12 PM, Mark Baker wrote:



On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote:
All I can go on is evidence of how folks are actually using 'em...  
and

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


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





Mark.

Re: PaceEntryMediatype

[Mark Baker]

On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote:

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


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

Mark.

Re: PaceEntryMediatype

[Sylvain Hellegouarch]

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

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

Re: PaceEntryMediatype

[James M Snell]

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

- James

Mark Baker wrote:
> 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.
> 
> On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote:
>> 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.
>> >
>>
> 

Re: PaceEntryMediatype

[Mark Baker]

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.

On 12/4/06, James M Snell <[EMAIL PROTECTED]> wrote:

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

Re: PaceEntryMediatype

[James M Snell]

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

Re: PaceEntryMediatype

[Asbjørn Ulsberg]

On Fri, 01 Dec 2006 19:42:20 +0100, Kyle Marvin <[EMAIL PROTECTED]> wrote:


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.


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.


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

Re: PaceEntryMediatype

[Asbjørn Ulsberg]

On Wed, 29 Nov 2006 20:03:22 +0100, Thomas Broyer <[EMAIL PROTECTED]>  
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»

Re: PaceEntryMediatype

[Thomas Broyer]

2006/12/2, Antone Roundy:


Now that this has sunk in, it makes a lot of sense--the @rel value
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 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).


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


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


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.


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

Re: PaceEntryMediatype

[Mark Baker]

On 12/2/06, Daniel E. Renfer <[EMAIL PROTECTED]> wrote:

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.


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

Mark.

Re: PaceEntryMediatype

[James M Snell]

Jan Algermissen wrote:
> [snip]
> 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)?
> 

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

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

-1.

> 
> 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?
> 

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

Re: PaceEntryMediatype

[Jan Algermissen]

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

Re: PaceEntryMediatype

[Sylvain Hellegouarch]

Daniel E. Renfer wrote:
> 
> 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/
> 


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

Re: PaceEntryMediatype

[Daniel E. Renfer]

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 PROTECTED]> 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


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.

Crazy busy and largely silent, but not completely awol,

-- Kyle

On 12/1/06, Mark Baker <[EMAIL PROTECTED]> wrote:
>
> Urgh, sorry for my tardiness; I'm falling behind on my reading.
>
> On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> 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;
>
> 
>
> Not particularly useful for subscription (or anything else for that
> matter) is it?  This would be better;
>
> 
>
> Autodiscovery should ideally be based primarily on link types, and
> only secondarily - as an optimization - on media types.  Even this
> should work;
>
> 
>
> Mark.
>

Re: PaceEntryMediatype

[Antone Roundy]

On 12/1/06, Mark Baker <[EMAIL PROTECTED]> wrote:

On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
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.


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.

Re: PaceEntryMediatype

[Lisa Dusseault]

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.


Crazy busy and largely silent, but not completely awol,

-- Kyle 


On 12/1/06, Mark Baker <[EMAIL PROTECTED]> wrote:

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

On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> 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;




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



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



Mark.

Re: PaceEntryMediatype

[James M Snell]

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
> 
> 

Re: PaceEntryMediatype

[Kyle Marvin]

On 12/1/06, James M Snell <[EMAIL PROTECTED]> wrote:


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.



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

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.



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

Re: PaceEntryMediatype

[Ernest Prabhakar]

Hi James,

On Dec 1, 2006, at 11:25 AM, James M Snell wrote:

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.


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.

Re: PaceEntryMediatype

[James M Snell]

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
> "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!
> 

Re: PaceEntryMediatype - rel-type instead

[Ernest Prabhakar]

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.

Re: PaceEntryMediatype

[Kyle Marvin]

On 12/1/06, James M Snell <[EMAIL PROTECTED]> wrote:



Kyle Marvin wrote:
> [snip]
> 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.
>

Not necessarily.

Consider:

  
  
  

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?



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.

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:

  
  
  

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.



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

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.



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!

Re: PaceEntryMediatype

[James M Snell]

Kyle Marvin wrote:
> [snip]
> 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.
> 

Not necessarily.

Consider:

  
  
  

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:

  
  
  

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

Re: PaceEntryMediatype

[Kyle Marvin]

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

On 12/1/06, Mark Baker <[EMAIL PROTECTED]> wrote:



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

On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> 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;



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



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



Mark.

Re: PaceEntryMediatype

[Mark Baker]

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

On 11/30/06, Thomas Broyer <[EMAIL PROTECTED]> 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;



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



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



Mark.

Re: PaceEntryMediatype

[Eric Scheid]

On 1/12/06 5:21 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:

> 5) Create a new media type for entry documents, and use @rel values
> to solve issues that doesn't solve:
> 
> +/- Messy territory
> 
> 
> If we were starting from scratch, I'd probably vote for #1.  Since
> we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have
> to think about #5 more first.

Starting from scratch, idealised, I'd want different media types (or params)
for entry documents and feed documents, and link type which clearly
indicates "this is for subscription", as distinct from "this is an alternate
representation", "this is an archive", etc.

Using the two mechanisms together allows combinations such as "here is a
feed you can subscribe to of the comments for this entry" and "here is a
feed document listing related resources, but since it won't likely be
updated don't bother subscribing".

I'd like to be able to use a lot of the link types we currently use for html
(directory, help, toc, related, next, etc) to refer to resources which
happen to be serialised in the atom feed document format, and feel safe in
knowing they won't be automagically treated as being subscription feeds.

e.

Re: PaceEntryMediatype - Options

[Ernest Prabhakar]

Hi Antoine,

On Nov 30, 2006, at 10:21 AM, Antone Roundy wrote:


Summary of thoughts and questions:


Thanks -- this is incredibly helpful.  However, might I suggest a  
couple more options?


6) Change expectations, not the spec.

Consumers must poll the feed to inspect the metadata, and Servers  
must accept both.


7) Disallow entry-only documents

Require all Atom documents to have a feed wrapper in order to be  
parsed properly. This is basically #4 + procrastination. :-)


I'm not saying these are necessarily _good_ options, but I'd like to  
be sure that whatever we do propose is superior to either of these;  
i.e., is the use of entry-only documents important enough to justify  
all this work?


Thanks,
-enp




*** Problems with the status quo ***

A) Consumers don't have enough information (without retrieving the  
remote resource) to determine whether to treat a link to an Atom  
document as a link to a live feed, a feed archive, or an entry.   
(Is it appropriate to poll the link repeatedly?  How should  
information about the link be presented to the user?)


B) APP servers can't communicate whether they will accept feed  
documents or only entry documents.



*** Possible solutions ***

1) Add a type parameter to the existing media type:

+ With the exception of a few details, the documents are all  
exactly the same format (does it contain a feed element, or does it  
start at the entry element, is it a "live" feed document or an  
archive, etc.), so a single media type makes the most sense  
(definitely for live feeds vs. archives, less certainly for feeds  
vs. entries).


- Some existing applications will ignore the parameter and may  
handle links to non-live-feeds inappropriately


- Some existing applications may not recognize application/atom 
+xml;type=feed as something appropriate to handle the same way they  
handle application/atom+xml now.


? I haven't been following development of the APP, so forgive my  
ignorance, but can parameters be included in the accept element?



2) Create (a) new media type(s) (whether like application/atomentry 
+xml or application/atom.entry+xml):


+ Applications that currently treat all cases of application/atom 
+xml the same would ignore non-feed links until they were updated  
to do something appropriate with the new media type.


- Differentiating between live feeds and archives by media type  
seems really wrong since their formats are identical.  This isn't  
as big a negative for entry documents, but it still seems  
suboptimal to me.


- If a media type were created for archive documents, would APP  
accept including application/atom+xml imply acceptance of archive  
documents too?  Neither yes nor no feels like a satisfying answer.



3) Use @rel values to differentiate:

- That territory is already a bit of a mess, what with "feed" vs.  
"alternate" vs. "alternate feed" vs. "feed alternate" -- why make  
it worse?


+ That territory is already a bit of a mess, what with "feed" vs.  
"alternate" vs. "alternate feed" vs. "feed alternate" -- why not  
work on all these messy problems in the same place?


- That wouldn't help with the APP accept issue.


4) Create a new media type for entry documents, and add a parameter  
to application/atom+xml to differentiate between live and archive  
feeds (and for any other documents that have the identical format,  
but should be handled differently in significant cases).


- Doesn't prevent existing apps that ignore the parameter from  
polling archive documents.


+ Does solve the rest of the problems without the negatives of #2  
above.



5) Create a new media type for entry documents, and use @rel values  
to solve issues that doesn't solve:


+/- Messy territory


If we were starting from scratch, I'd probably vote for #1.  Since  
we're not, I'd vote for #4 first, and perhaps #5 second, but I'd  
have to think about #5 more first.


Antone

Re: PaceEntryMediatype

[James M Snell]

Excellent summarization Antone, thank you.

Antone Roundy wrote:
> [snip]
> ? I haven't been following development of the APP, so forgive my
> ignorance, but can parameters be included in the accept element?
> 

I'd have to double check the definition of "media-range" but the
original intent was that parameters would be allowed but likely rarely used.

> [snip]
> 4) Create a new media type for entry documents, and add a parameter to
> application/atom+xml to differentiate between live and archive feeds
> (and for any other documents that have the identical format, but should
> be handled differently in significant cases).
> 
> [snip]
> 
> If we were starting from scratch, I'd probably vote for #1.  Since we're
> not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think
> about #5 more first.
> 

I personally don't care so much about differentiating archive feeds. At
this point I'm thinking that some combination of 4 and 5 would be best.

- James

Re: PaceEntryMediatype

[Antone Roundy]

Summary of thoughts and questions:

*** Problems with the status quo ***

A) Consumers don't have enough information (without retrieving the  
remote resource) to determine whether to treat a link to an Atom  
document as a link to a live feed, a feed archive, or an entry.  (Is  
it appropriate to poll the link repeatedly?  How should information  
about the link be presented to the user?)


B) APP servers can't communicate whether they will accept feed  
documents or only entry documents.



*** Possible solutions ***

1) Add a type parameter to the existing media type:

+ With the exception of a few details, the documents are all exactly  
the same format (does it contain a feed element, or does it start at  
the entry element, is it a "live" feed document or an archive, etc.),  
so a single media type makes the most sense (definitely for live  
feeds vs. archives, less certainly for feeds vs. entries).


- Some existing applications will ignore the parameter and may handle  
links to non-live-feeds inappropriately


- Some existing applications may not recognize application/atom 
+xml;type=feed as something appropriate to handle the same way they  
handle application/atom+xml now.


? I haven't been following development of the APP, so forgive my  
ignorance, but can parameters be included in the accept element?



2) Create (a) new media type(s) (whether like application/atomentry 
+xml or application/atom.entry+xml):


+ Applications that currently treat all cases of application/atom+xml  
the same would ignore non-feed links until they were updated to do  
something appropriate with the new media type.


- Differentiating between live feeds and archives by media type seems  
really wrong since their formats are identical.  This isn't as big a  
negative for entry documents, but it still seems suboptimal to me.


- If a media type were created for archive documents, would APP  
accept including application/atom+xml imply acceptance of archive  
documents too?  Neither yes nor no feels like a satisfying answer.



3) Use @rel values to differentiate:

- That territory is already a bit of a mess, what with "feed" vs.  
"alternate" vs. "alternate feed" vs. "feed alternate" -- why make it  
worse?


+ That territory is already a bit of a mess, what with "feed" vs.  
"alternate" vs. "alternate feed" vs. "feed alternate" -- why not work  
on all these messy problems in the same place?


- That wouldn't help with the APP accept issue.


4) Create a new media type for entry documents, and add a parameter  
to application/atom+xml to differentiate between live and archive  
feeds (and for any other documents that have the identical format,  
but should be handled differently in significant cases).


- Doesn't prevent existing apps that ignore the parameter from  
polling archive documents.


+ Does solve the rest of the problems without the negatives of #2 above.


5) Create a new media type for entry documents, and use @rel values  
to solve issues that doesn't solve:


+/- Messy territory


If we were starting from scratch, I'd probably vote for #1.  Since  
we're not, I'd vote for #4 first, and perhaps #5 second, but I'd have  
to think about #5 more first.


Antone

Re: PaceEntryMediatype

[James M Snell]

Bill de hOra wrote:
> 
> "Well it's all octets so in one sense the processing is the same."
> [snip]

Btw, My apologies if my original comment about the xml parsing came
across as being snarky; that was not the intention.  The point I was
making was that how these things are "processed" depends entirely on how
you intend to use 'em.  So far I've seen no evidence that anyone intends
to use Entry Documents in the same way they use Feed Documents.

- James

Re: PaceEntryMediatype

[Bill de hOra]

Mark Baker wrote:


[..] it it's
better than the alternative of many more specific Atom-related media
types, which atomentry+xml might set a precedent for.


One question and one observation. The question: how will this set a 
precedent? The observation: if we really want to avoid this problem 
(assuming there is a problem), then RDF was the answer, not a pretence 
of uniformity.


cheers
Bill