On Thu, 7 Dec 2006, Martin Atkins wrote:
> >
> > Feeds for this site
> >
> >Status feed
> >News feed
> >Links feed
> >
>
> This makes a lot more sense to me. When that orange button lights on up
> on my browser's toolbar, I tend to think of it as "subscribe to this
> page", not "s
On Thu, 7 Dec 2006, Alexey Feldgendler wrote:
> >>>
> >>>
> >>>Feeds for this site
> >>>
> >>>
> >>>
> >>>This page links to the three feeds for this site.
> >
> > status.xml is just a resource that provides a syndication feed. It is
> > not necessarily associated with a p
On Sat, 09 Dec 2006 04:01:14 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
Why is it useful for a browser to make a list of a bunch of random feeds
that have no relation to one another or to the current page?
Well they sort of have a relation -- they're feeds that the author thinks
the user w
On Fri, 8 Dec 2006, Martin Atkins wrote:
> Ian Hickson wrote:
> >
> > Then the browser wouldn't take these links and make them available in a
> > "list of feeds" interface, which is the problem we are trying to solve.
>
> Why is it useful for a browser to make a list of a bunch of random feeds
>
Ian Hickson wrote:
Then the browser wouldn't take these links and make them available in a
"list of feeds" interface, which is the problem we are trying to solve.
Why is it useful for a browser to make a list of a bunch of random feeds
that have no relation to one another or to the current
On Fri, 08 Dec 2006 04:31:25 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
Feeds for this site
This page links to the three feeds for this site.
>>> status.xml is just a resource that provides a syndication feed. It is not
>>> necessarily associ
On Thu, 7 Dec 2006, Alexey Feldgendler wrote:
>>>
>>>
>>>Feeds for this site
>>>
>>>
>>>
>>>This page links to the three feeds for this site.
>>
>> status.xml is just a resource that provides a syndication feed. It is not
>> necessarily associated with a particular Web page
On Thu, 7 Dec 2006, Thomas Broyer wrote:
>
> 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="fee
Alexey Feldgendler wrote:
On Wed, 06 Dec 2006 22:42:06 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
In your example, what's the relation between status.xml and this page?
status.xml is just a resource that provides a syndication feed. It is not
necessarily associated with a p
On Wed, 06 Dec 2006 22:42:06 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
>>> I mean that the feed might contain items that were never part of the page
>>> linking to the feed. For example, this page:
>>>
>>>
>>>Feeds for this site
>>>
>>>
>>>
>>>This page links to the thr
[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
On Wed, 6 Dec 2006, Alexey Feldgendler wrote:
> On Tue, 05 Dec 2006 00:54:04 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
>
> > I mean that the feed might contain items that were never part of the page
> > linking to the feed. For example, this page:
> >
> >
> >Feeds for this site
> >
On Tue, 05 Dec 2006 00:54:04 +0600, Ian Hickson <[EMAIL PROTECTED]> wrote:
> I mean that the feed might contain items that were never part of the page
> linking to the feed. For example, this page:
>
>
>Feeds for this site
>
>
>
>This page links to the three feeds for this
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
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
Thomas Broyer wrote:
There's no need to fetch every link if you base your assumptions on
the type="" attribute (and *only* the type="" attribute, not the
combination with any special rel="" attribute value).
How does this solution deal with, e.g. hAtom?
http://microformats.org/wiki/hatom
The
On Mon, 4 Dec 2006, Thomas Broyer wrote:
>
> There's no need to fetch every link if you base your assumptions on the
> type="" attribute (and *only* the type="" attribute, not the combination
> with any special rel="" attribute value). If you don't use the type=""
> attribute on s, you'll have
Le 3 déc. 2006 à 18:49, Ian Hickson a écrit :
On Sun, 3 Dec 2006, Thomas Broyer wrote:
What I mean is that "being syndication feed" is not a property of a
relationship, it's a property of one end of the relationship (the
resource the link "starts from" or "points to"); so it has nothing
to d
2006/12/4, Ian Hickson:
On Sun, 3 Dec 2006, Thomas Broyer wrote:
>
> What I mean is that "being syndication feed" is not a property of a
> relationship, it's a property of one end of the relationship (the
> resource the link "starts from" or "points to"); so it has nothing to do
> with the rel=""
On Sun, 3 Dec 2006, Thomas Broyer wrote:
> >
> > Oh. If you just mean that you don't think there should be a way to say
> > that a particular document is a syndication feed, then I disagree. I
> > would assert that the popularity of feed readers such as Bloglines,
> > Google Reader, and so forth
2006/12/2, Ian Hickson:
On Sat, 2 Dec 2006, Thomas Broyer wrote:
>
> And what is a "syndication feed", if not something that's
> "subscribable"?
>
> I mean, there is no definition of "syndication feed", neither of "feed
> autodiscovery" (what's the purpose of "feed autodiscovery", if not to
> sub
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
2006/12/1, Mark Baker:
Urgh, sorry for my tardiness; I'm falling behind on my reading.
On 11/30/06, Thomas Broyer 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 inter
On Sat, 2 Dec 2006, Thomas Broyer wrote:
> 2006/12/1, Ian Hickson:
> > On Fri, 1 Dec 2006, Thomas Broyer wrote:
> > >
> > > A summary of my problem with HTML5's autodiscovery: - there
> > > shouldn't be a 'rel' value for "subscribability", subscribability is
> > > a matter of whether and how an U
2006/12/1, Ian Hickson:
On Fri, 1 Dec 2006, Thomas Broyer wrote:
>
> A summary of my problem with HTML5's autodiscovery:
> - there shouldn't be a 'rel' value for "subscribability",
> subscribability is a matter of whether and how an UA can process
> content from a particular media type
Agreed. T
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 Fri, 1 Dec 2006, 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.
Assuming that
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 b
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
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
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
On 12/1/06, Kyle Marvin <[EMAIL PROTECTED]> wrote:
I'm still listening to the debate, but Mark's argument resonates with me.
Yes, Mark is starting to convince me as well.
--
Robert Sayre
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 t
On Fri, 1 Dec 2006, Thomas Broyer wrote:
>
> A summary of my problem with HTML5's autodiscovery:
> - there shouldn't be a 'rel' value for "subscribability",
> subscribability is a matter of whether and how an UA can process
> content from a particular media type
Agreed. The spec doesn't mention s
2006/11/30, Ian Hickson:
On Thu, 30 Nov 2006, Thomas Broyer wrote:
>
> I'd prefer basing autodiscovery on the media types and not at all on the
> relationships. A "feed" relationship would only help finding the "living
> resource" (similar to rel="current" in the Atom Relationship Registry)
> if
On Thu, 30 Nov 2006, Thomas Broyer wrote:
>
> I'd prefer basing autodiscovery on the media types and not at all on the
> relationships. A "feed" relationship would only help finding the "living
> resource" (similar to rel="current" in the Atom Relationship Registry)
> if you're not already "on"
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
t
37 matches
Mail list logo
