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
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
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
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,
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
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
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
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
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,
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 Algermissen [EMAIL PROTECTED] [2006-12-07 08:25]:
As an analogy: HTML browsers look for stylesheets where it says
link rel=stylesheet type=text/css href=/style.css /
and not
link rel=alternate type=text/css href=/style.css /
Eh?
What do browsers do with this?
link
[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
=stylesheet type=text/plain href=/style.css /.
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
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
* Franklin Tse [EMAIL PROTECTED] [2006-12-07 10:00]:
If browsers do not support text/plain as a stylesheet, they
should just simply ignore link rel=stylesheet
type=text/plain href=/style.css /.
Exactly.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
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,
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
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
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
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
* 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
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
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
* 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
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
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
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
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,
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
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,
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
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
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
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
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?
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
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
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
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,
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
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.
-
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
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.
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
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
-
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
* Mark Baker [EMAIL PROTECTED] [2006-11-29 20:10]:
An entry document is, AFAICT, little more than shorthand for
a feed with one entry, minus the feed-specific metadata. It's
processing is a subset of feed processing. If the processing or
content model of entry is extended, it applies to both
* James M Snell [EMAIL PROTECTED] [2006-11-29 17:40]:
http://www.intertwingly.net/wiki/pie/PaceEntryMediatype
+1
* Thomas Broyer [EMAIL PROTECTED] [2006-11-29 20:35]:
I'd largely prefer augmenting the existing media type with
a 'type' parameter:
- application/atom+xml = either feed or
Jan Algermissen wrote:
Hi James,
On Nov 29, 2006, at 5:16 PM, James M Snell wrote:
== Status ==
Proposed
== Rationale ==
The fact that one media type is used for both Feed and Entry documents
has repeatedly come up as a problem on more than one occasion.
I took that to
On Nov 29, 2006, at 7:22 PM, James M Snell wrote:
One such problem occurs in atom:link and atom:content elements.
Specifically:
atom:link type=application/atom+xml href=a.xml /
atom:content type=application/atom+xml src=b.xml /
Given no other information I have no way of knowing
Thomas Broyer wrote:
James M Snell wrote:
Create a new media type for Atom Entry Documents:
application/atomentry+xml
Deprecate the use of application/atom+xml for Entry Documents.
-0.5.
Using a type parameter seems like a more elegant solution -- and
achieves the same effect.
I'd
James M Snell wrote:
Mark Baker wrote:
[snip]
Yes, but more than that. An entry document is, AFAICT, little more
than shorthand for a feed with one entry, minus the feed-specific
metadata. It's processing is a subset of feed processing. If the
processing or content model of entry is
A. Pagaltzis wrote:
* Mark Baker [EMAIL PROTECTED] [2006-11-29 20:10]:
An entry document is, AFAICT, little more than shorthand for
a feed with one entry, minus the feed-specific metadata. It's
processing is a subset of feed processing. If the processing or
content model of entry is extended,
On Nov 30, 2006, at 2:13 AM, Jan Algermissen wrote:
On Nov 29, 2006, at 7:22 PM, James M Snell wrote:
One such problem occurs in atom:link and atom:content elements.
Specifically:
atom:link type=application/atom+xml href=a.xml /
atom:content type=application/atom+xml src=b.xml /
Given no
Thomas Broyer wrote:
snip
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
/snip
+1
On 11/29/06, Thomas
Mark Baker wrote:
Interesting, thanks. But serving different purposes doesn't
necessitate a new media type. What's important is how the two types
of documents are interpreted.
How does your processing of an entry document differ from the
processing of a feed containing (only) that same
2006/11/30, Mark Baker:
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.
On 11/30/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote:
How does your processing of an entry document differ from the
processing of a feed containing (only) that same entry? If processing
the entry is a subset of processing the feed, then you probably don't
need a new media type.
Well
Well, it's all XML parsing so in one sense the processing is the same.
The key difference arises in how the various documents are used. In my
experience, Atom Entry Documents are nearly the exclusive territory of
APP Clients and push notification services (e.g. Atom over XMPP) while
Feeds
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.
-
Jan Algermissen wrote:
[snip]
Are there other problems you had in mind when writing the Pace?
Well, there are the issues that came up with regards to the APP accept
element; the issues regarding whether Atom Feeds can be posted to an APP
collection; the issue in the collection of
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.
Of course it does. Any program interested in consuming information is
going to
Mark Baker wrote:
[snip]
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
Well it's all octets so in one sense the processing is the same.
I have to agree with James.
The right questions in my mind is this - how is processing an entry
different from processing a feed with that and 42 entries?
The idea that an entry is a degenerate feed is interesting, but
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
1 - 100 of 119 matches
Mail list logo
