* 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),
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
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
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:
-
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
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
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
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 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
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
Sorry for being so imprecise. I was assuming so too. I don't know why
I did not make it clearer.
But if there were others who misread this and there are enough of
them, we can also do it on Wednesday 13th.
Henry
On 6 Dec 2006, at 10:14, Terris Linenbach wrote:
It is unclear reading this
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
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
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
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
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
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
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
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
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
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
Hi,
I'm sending entries over XMPP packaged up as feeds. A question that has
come up - should the feed's atom:id change each time a feed is sent, or
should it remain the same for all feeds issued from a client?
cheers
Bill
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
Depends... is the client expected to process each discreet set of
entries as part of a single logical set or is each discreet set expected
to be processed as it's own complete set? The former would be
equivalent to the way most feed readers work today. The latter would be
equivalent to
FYI,
I've posted an update to the proposed Atom bidi spec.
http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-02.txt
Refresher: this adds a dir attribute to Atom Common Attributes that is
used to specify the base direction of text in Atom documents.
Changes: this draft has two
I'll be there around 6:30ish; hope to see whoever is coming. Wish I
had an Atom logo to wear.
Henry Story wrote:
Sorry for being so imprecise. I was assuming so too. I don't know why
I did not make it clearer.
But if there were others who misread this and there are enough of
them, we can
* 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
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
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
29 matches
Mail list logo
