To clarify my +1 to Ship it: At AOL, we are using Atom internally as
a data exchange format (and just converted to 1.0 syntax). We are using
an early version of the introspection document as well, but only for
limited internal use as it's nonstandard and likely to change. When the
dust
On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote:
PaceAnchorSupport and PaceDifferentRelValue don't seem very useful,
and they weren't proposed by implementors. The spec is extremely
well-written and reflects existing behavior.
Can we please un-expire this:
: Tuesday, January 24, 2006 10:09 AM
To: Robert Sayre
Cc: Atom Syntax; Phil Ringnalda; Mark Pilgrim
Subject: Re: finishing autodiscovery, like now
On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote:
PaceAnchorSupport and PaceDifferentRelValue don't seem very useful,
and they weren't proposed
+1 to ship it.
--
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer
* Robert Sayre [EMAIL PROTECTED] [2006-01-19 18:25]:
PaceAnchorSupport and PaceDifferentRelValue don't seem very
useful, and they weren't proposed by implementors. The spec is
extremely well-written and reflects existing behavior.
They’re trying to do something useful, but in the wrong way. Both
On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
But we already have a name for doing that: it¹s called ³linking
to something.² Now, it¹d be useful to encourage people to add
`type` attributes to their `a` links, so tools could find them
just by looking at the page without
Quoting Eric Scheid [EMAIL PROTECTED]:
On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
But we already have a name for doing that: it¹s called ³linking
to something.² Now, it¹d be useful to encourage people to add
`type` attributes to their `a` links, so tools could find them
just by
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
The existing behaviour is based on the various incarnations of RSS where the
only document type involved are feeds. RFC 4287 introduces a new document
type, the Atom Entry Document, which autodiscovery-01 fails to take into
consideration. That
Eric Scheid wrote:
On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
But we already have a name for doing that: it¹s called ³linking
to something.² Now, it¹d be useful to encourage people to add
`type` attributes to their `a` links, so tools could find them
just by looking at the
Hi Eric,
* Eric Scheid [EMAIL PROTECTED] [2006-01-19 21:10]:
Here is a link to a resource:
link type=application/atom+xml href=... /
Please explain how a tool can decide whether that is a link to a
atom:feed document, or is a link to an atom:entry document?
this is an excellent point. How
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
The existing behaviour is based on the various incarnations of RSS where the
only document type involved are feeds. RFC 4287 introduces a new document
type, the Atom Entry Document, which autodiscovery-01 fails to take into
consideration. That
On 1/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
The existing behaviour is based on the various incarnations of
RSS where the only document type involved are feeds. RFC 4287
introduces a new document type, the Atom Entry Document, which
autodiscovery-01 fails to take into consideration. That
On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote:
Of course, if we spec only things which include feed in the rel
value as being appropriate for aggregators, and all others as not, we
still would need to wait three or four years for existing use of
alternate alone to die down before any
Why wouldn't this work?
rel=alternate feed
rel=alternate entry
rel=alternate replies (see [1])
[1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-03.txt
Phil Ringnalda wrote:
On 1/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
The existing behaviour is based on the
On 20/1/06 7:52 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Here is a link to a resource:
link type=application/atom+xml href=... /
Please explain how a tool can decide whether that is a link to a
atom:feed document, or is a link to an atom:entry document?
this is an excellent point.
On 20/1/06 7:57 AM, James M Snell [EMAIL PROTECTED] wrote:
Here is a link to a resource:
link type=application/atom+xml href=... /
Please explain how a tool can decide whether that is a link to a atom:feed
document, or is a link to an atom:entry document?
This is a general
On 1/19/06, James M Snell [EMAIL PROTECTED] wrote:
Why wouldn't this work?
rel=alternate feed
rel=alternate entry
rel=alternate replies (see [1])
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
I.e. the values are all
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
PaceDifferentRelValue addresses this. It suggests using feed as an @rel
value to indicate the referenced resource is a feed (ie. is not an entry
doc) which can be subscribed to.
The spec already does this without a new rel value.
It doesn't
* Phil Ringnalda [EMAIL PROTECTED] [2006-01-19 22:30]:
I am trying to think of a scenario where I'd want to
autodiscover an entry document (as opposed to simply linking
to it) and the inability to distinguish between feed and entry
documents is causing a problem, but I can't come up with
* Eric Scheid [EMAIL PROTECTED] [2006-01-19 23:10]:
PaceDifferentRelValue addresses this. It suggests using feed
as an @rel value to indicate the referenced resource is a feed
(ie. is not an entry doc) which can be subscribed to. It doesn't
rule out continuing to use alternate for those cases
A. Pagaltzis wrote:
(Hm, what happened to James Snell’s profile extension?)
In progress. I decided to hold off in favor of a few other higher
priority items. Expect a draft on this either later this month or next.
- James
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
The purpose of Atom autodiscovery is for clients who know the URI of a
web page to find the location of that page's associated Atom feed.
Not an entry but a feed. The autodiscovery is unambiguous on what such
a link points to.
On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Okay, so you have two alternates: one with comments, one without.
That would be `rel=alternate` in both cases, with
`title=Entry` in one of them and `title=Entry with comments`
in the other.
This is semantically weak, I know.
On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
And someone else still uses Atom in yet another clever way.
Which is precisely why [EMAIL PROTECTED]alternate,@type=atom+xml] is an
*ambiguous* way of discovering atom Feeds ...
It¹s just impossible to specify enough precise
On 20/1/06 8:52 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
Why wouldn't this work?
rel=alternate feed
rel=alternate entry
rel=alternate replies (see [1])
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
I.e. the values
On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote:
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
https://mail.google.com/mail/
I.e. the values are all orthogonal.
Though at this point in this discussion, someone is always
On 20/1/06 8:31 AM, Robert Sayre [EMAIL PROTECTED] wrote:
First person to need the feature has to spec alternate entry instead
of making everyone change to alternate feed.
How is speccing alternate entry helpful?
That would *still* be considered an autodiscovery link to a feed,
according the
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
That would *still* be considered an autodiscovery link to a feed,
according the current autodiscovery spec. That's the problem right there.
It's not a problem. It works now, and no one is going to run out and
change the running code. If someone
Eric Scheid wrote:
Yes, but that would mean that it *would* work, not that it *wouldn't*. Being
orthogonal means that those three links are equivalent to these six links
rel=alternate href=1
rel=alternate href=2
rel=alternate href=3
rel=feed href=1
rel=entry href=2
rel=replies
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
The purpose of Atom autodiscovery is for clients who know the URI of a
web page to find the location of that page's associated Atom feed.
Not an entry but a feed. The
On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote:
On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote:
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
https://mail.google.com/mail/
I.e. the values are all orthogonal.
On 20/1/06 12:32 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote:
Though at this point in this discussion, someone is always duty-bound
to point out that the only use of link that HTML actually specifies,
for stylesheets, treats them as not
Joe Gregorio wrote on 1/19/2006, 5:29 PM:
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
The purpose of Atom autodiscovery is for clients who know the URI
of a
web page to find the location of that page's
On 1/19/06, John Panzer [EMAIL PROTECTED] wrote:
What autodiscovery links should I do on a web page that displays a
single blog entry, like this one?
http://journals.aol.com/panzerjohn/abstractioneer/entries/1238
Actually on my blog each page has a feed associated with
it that is a feed of
On 20/1/06 1:55 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
What autodiscovery links should I do on a web page that displays a
single blog entry, like this one?
http://journals.aol.com/panzerjohn/abstractioneer/entries/1238
Actually on my blog each page has a feed associated with
it that
35 matches
Mail list logo
