subject:"RE\: Autodiscovery"


On 11/5/05 1:41 AM, Robert Sayre [EMAIL PROTECTED] wrote:

 I don't understand what the feed relation indicates. What benefit
 does it have over
 
 a href=... type=application/atom+xml.../a

It indicates that the @href resource is a feed in the sense that it is a
source of notifications of updated content (and is the place to watch for
updates the current page) to which one might wish to subscribe, and
furthermore it suggests that the resource of @type=application/atom+xml is
an Atom Feed Document, and not an Atom Entry Document.

Links you might *not* want to use @rel=feed on would be...

a href=...example of a broken feed/a
a href=...archives for June 2002/a
a href=...Tom's feed, very interesting/a

Without @rel=feed, a browser with autodiscovery support might well suggest
those links as being worthy of subscription. (The third case iffy -- I rule
it not @rel=feed because Tom is quite unlikely to include an entry which
is an alternate for this particular page).

e.

Re: Autodiscovery paces

2005-05-10 Thread Thomas Broyer

Eric Scheid wrote:
On 11/5/05 1:41 AM, Robert Sayre [EMAIL PROTECTED] wrote:
I don't understand what the feed relation indicates. What benefit
does it have over
a href=... type=application/atom+xml.../a
It indicates that the @href resource is a feed in the sense that it is a
source of notifications of updated content (and is the place to watch for
updates the current page) to which one might wish to subscribe, and
furthermore it suggests that the resource of @type=application/atom+xml is
an Atom Feed Document, and not an Atom Entry Document.
Links you might *not* want to use @rel=feed on would be...
a href=...example of a broken feed/a
a href=...archives for June 2002/a
a href=...Tom's feed, very interesting/a
Without @rel=feed, a browser with autodiscovery support might well suggest
those links as being worthy of subscription. (The third case iffy -- I rule
it not @rel=feed because Tom is quite unlikely to include an entry which
is an alternate for this particular page).
IMO, autodiscovery should occur only when a @rel (or @rev) is provided 
(and, ideally, understood). Don't forget HTML does not define a default 
value for @rel or @rev when they are not provided.

This is a link to an Atom document:
a href=... type=application/atom+xml.../a
These are links to Atom documents which indicate a relation between the 
containing document and the feed pointed to by the @href and should 
therefor trigger autodiscovery:
Linking to the news feed from the news page:
a href=... rel=alternate type=application/atom+xml.../a
Linking to the news feed from another page (e.g. the Mozilla home):
a href=... rel=related type=application/atom+xml.../a

--
Thomas Broyer

Re: Autodiscovery paces

2005-05-10 Thread Robert Sayre


There's no reason for any of the ideas in this thread to be in the
same draft as the concepts outlined in autodiscovery-01. Stamp Out
Creativity Now.

I'm strongly opposed to letting this draft turn into a vast metropolis
of bikesheds, where we have 60-message threads on the right way to use
HTML @rel values. The WG has limited resources and time. Those
resources are most needed by the protocol draft. Bolting fancy new
appendages on the autodiscovery draft is a waste of time. You don't
need a standards action to add a link relation. Just do it.

Robert Sayre

Re: Autodiscovery paces


On 11/5/05 2:24 AM, Graham [EMAIL PROTECTED] wrote:

 http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue
 
 -1
 
 I mainly don't see the point of changing it.

The point is that just using 'alternate' is hideously ambiguous, and leads
to interoperability problems because you cannot rely on the value of @type
to accurately guess whether @href points to a feed or some other document.

In the history of feed autodiscovery, the exact syntax was corrected within
days of being first announced. Since then it's become popular, even without
official documentation in a specification. During that time people have come
to realise that there is a problem with 'alternate' ... consider that
pre-spec time as being a beta test period ... and now that we are on the
verge of releasing a fully documented specification it is our last real
opportunity to fix any mistakes.

Robert says anyone can mint new @rel types, but seriously, in the face of
popular usage of 'alternate' being backed up by a RFC specification, does
anyone think 'feed' would have a chance?

Put it in the spec and we are saying use of 'alternate' is flawed, the
preferred option is 'feed', and it will have more potency.

 Also, while alternate
 expressly says the feed corresponds in some way to the content of the
 current page, feed simply says here is a feed of some kind, and
 isn't a relationship at all.

Depends on how you read the word 'feed'. It can indicate a relationship,
that being this is the feed in which an entry representing this page (or
portion thereof) was once found, and may again be found.

I, like some, feel uncomfortable with those usage of autodiscovery links to
point to just any feed, from any page. Links to feed resource documents are
not necessarily links to feeds.

e.

Re: Autodiscovery paces


On 11/5/05 1:20 PM, Eric Scheid [EMAIL PROTECTED] wrote:

 Also, while alternate
 expressly says the feed corresponds in some way to the content of the
 current page, feed simply says here is a feed of some kind, and
 isn't a relationship at all.
 
 Depends on how you read the word 'feed'. It can indicate a relationship,
 that being this is the feed in which an entry representing this page (or
 portion thereof) was once found, and may again be found.
 
 I, like some, feel uncomfortable with those usage of autodiscovery links to
 point to just any feed, from any page. Links to feed resource documents are
 not necessarily links to feeds.

On reflection, I thought I'd better check what the spec says...
http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

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. 

There is also this in section 6

   The order of the autodiscovery elements is significant.
The first element SHOULD point to the publisher's preferred
feed for the document.

... thus [1] auto-discovery is *not* for the general case of linking to just
*any* feed resource, but specifically the one associated to the current
page/site. Which is a specific relationship, one we can name 'feed' (or
'fred', or 'barney' ... but 'feed' gets my vote).

e.

[1] I conclude ... and so might any reader of the spec who is ignorant of
the full backstory.

Re: Autodiscovery paces


On 11/5/05 1:18 AM, Mark Pilgrim [EMAIL PROTECTED] wrote:

 http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue
 
 +0.  Part of my newfound personal definition of a life well-lived is
 to never again argue about semantics, markup, or the correct way to
 use them.  This Pace will break every aggregator on the planet, but
 then again, so will Atom 1.0 feeds, so... +0.

:-)

My belief is that RSS/Atom is at the point of crossing the chasm [1] and
going mainstream, and as such if we want the momentum to continue we should
be mindful of two things:

  * adding features/functions/tweaks which appeal to geeks and
other 'insiders' is counter-productive

  * not fixing any warts or bugs which non-geeks won't understand
why they get broken behaviour is counter-productive.

There is thus a filter to be applied to any suggestions for improvements.

Changing 'alternative' to 'feed' fits the second criteria, but adding a/
fits the first. So, +1 to PaceDifferentRelValue, -1 to PaceAnchorSupport.

e.

[1] http://en.wikipedia.org/wiki/Crossing_the_Chasm

Re: Autodiscovery - different cases should use different rel

2005-05-06 Thread Eric Scheid


On 6/5/05 1:07 PM, Nikolas 'Atrus' Coukouma [EMAIL PROTECTED] wrote:

 Hrm. This is an interesting point. I'm not too concerned about find
 every feed, regardless of relevance because I think only search engines
 will be interested in it, especially if all the other cases are marked.

finding every feed is not my concern either.

 They can bear to check the feed and see what the root element is.

this won't work ... see below.

 This also makes rel=alternate seem like an even worse choice for
 *feed* autodiscovery because it would make sense to link to an atom
 *entry* as rel=alternate from the page for an individual entry.

absolutely!

 I really don't think @rel is the place to address concerns about type.
 That's really the job of @type (of course). If we need to declare more
 mime-types, then so be it.

Just to throw more fuel on the fire:

It is quite conceivable for an Atom Feed Document (AFD) to contain a set of
entries which won't grow or be updated, such as an AFD which contains all
postings for a calendar period, or an AFD which contains one entry for each
chapter of a book, and so on.

Thus, neither mime-types nor root-element-sniffing will be reliable enough
to discover the resource which is appropriate for subscribing to - ie.
discovering which Atom Feed Document is the one which will be updated as
time goes by in the usual sliding window manner, and not the monthly archive
that page happens to be contained within.


e.

Re: Autodiscovery

2005-05-06 Thread Sjoerd Visscher

fantasai wrote:
The difference between link and a is that
  - link applies to the document as a whole: it indicates a relationship
between this document and the href destination.
  - a is a contextual link: it indicates a relationship between the
linking context and the href destination.
They have different purposes. It is imho perfectly reasonable to limit
autodiscovery to links only. It is also perfectly reasonable to link
to feeds with a, and expect that the UA will recognize it as a feed
rather than a generic XML document.
Like I wrote before, this is not how HTML 4.01 (or XHTML 2.0 for that 
matter) defines the rel attribute on a hyperlink:

This attribute describes the relationship from the current document to 
the anchor specified by the href attribute. The value of this attribute 
is a space-separated list of link types.

--
Sjoerd Visscher
http://w3future.com/weblog/

Re: Autodiscovery - different cases should use different rel

2005-05-06 Thread fantasai

Nikolas 'Atrus' Coukouma wrote:
fantasai wrote:
Actually, I think start is the best fit. The main feed is often not a
table of contents to the entire weblog, but something partial. It is,
however, the starting point of the collection.
Actually, I disagree with start because of the first sentence in the
HTML spec:
Refers to the first document in a collection of documents.
This indicates that start should point to the first post in a weblog.
end would be the most recent (not that end exists in the HTML spec)
I think first here should not be taken as chronological, but as
foremost. This would make it consistent with the second sentence:
This link type tells search engines which document is considered by the
author to be the starting point of the collection.
This is a completely different meaning and I'm not sure why it's bundled
with the first. According to this, start pointing to the homepage is fine.

BTW, you might want to take a look at
 http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html
 http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html
No offense, but with all the tripod ads, I would have much preferred a
link to the Hypertext links in HTML draft [1].
Sorry.
Section four is what I want. It's not indexed alphabetically and
doesn't combine other documents, but it's the covers everything
pretty well.
[1] http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt
Not quite everything. Some of the values (like start) are not
covered in that draft.
~fantasai

Re: Autodiscovery - different cases should use different rel

2005-05-06 Thread Nikolas 'Atrus' Coukouma

Eric Scheid wrote:

On 6/5/05 1:07 PM, Nikolas 'Atrus' Coukouma [EMAIL PROTECTED] wrote:

Hrm. This is an interesting point. I'm not too concerned about find
every feed, regardless of relevance because I think only search engines
will be interested in it, especially if all the other cases are marked.

finding every feed is not my concern either.

They can bear to check the feed and see what the root element is.

this won't work ... see below.

This also makes rel=alternate seem like an even worse choice for
*feed* autodiscovery because it would make sense to link to an atom
*entry* as rel=alternate from the page for an individual entry.

absolutely!

I really don't think @rel is the place to address concerns about type.
That's really the job of @type (of course). If we need to declare more
mime-types, then so be it.

Just to throw more fuel on the fire:

It is quite conceivable for an Atom Feed Document (AFD) to contain a set of
entries which won't grow or be updated, such as an AFD which contains all
postings for a calendar period, or an AFD which contains one entry for each
chapter of a book, and so on.

Thus, neither mime-types nor root-element-sniffing will be reliable enough
to discover the resource which is appropriate for subscribing to - ie.
discovering which Atom Feed Document is the one which will be updated as
time goes by in the usual sliding window manner, and not the monthly archive
that page happens to be contained within.

This warrants groaning. I think it's safe to say that user agents
shouldn't subscribe to entry docments. Feeds may be worth bothering with.

Source: (HTML/XHTML)
Clearly the friendlier end to do autodiscovery on. Remember, the goal
here is to indicate that the URI from @href is worth subscribing to. I'm
running out of attributes to abuse.
From the XHTML Link Module: [1]
charset, href, hreflang, media, rel, rev, type
Link Module: [2]
target

All of these are listed in the 4.01 spec[3]. There's also the slim
chance of using XLink's link semantics [4]. They seem to be mostly
redundant with @target.

Speaking of @target, I'm currently favoring it because it's used for
indicating where a link whould be loaded. This makes a hair more sense
with today's browser-feed integration.

Destination: (Atom)
The only way I can see to indicate that a feed is alive and worth
subscribing to (assuming existing Atom spec) is to include cache control
(Expires or Cache-Control headers).

[1]
http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/abstract_modules.html#s_targetmodule
[2]
http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/abstract_modules.html#s_linkmodule
[3] http://www.w3.org/TR/html4/struct/links.html#h-12.3
[4] http://www.w3.org/TR/xlink/#link-semantics

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery discussion editorship

2005-05-06 Thread Mark Pilgrim


On 5/5/05, Tim Bray [EMAIL PROTECTED] wrote:
 The discussion in recent days has been lively but unstructured.  If I
 were forced to make a consensus call right now, I'm pretty sure I
 wouldn't be able to pick out any one spec change that I could say
 clearly has consensus.

The one suggestion I did see, which should be acted on immediately, is
to update the references section to point to the newest versions of
the XML and URI specs (and associated link changes throughout the
text).

-- 
Cheers,
-Mark

Re: Autodiscovery

2005-05-06 Thread Sjoerd Visscher

Nikolas 'Atrus' Coukouma wrote:
Using @rel with any linking element is perfectly valid and has been for
years.
@rel not being supported for anything other than the link element itself
has also been an outstanding bug for just as long. There's lot of debate
attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20).
Can we agree that this should be supported, but currently isn't? Unless
there's a compelling reason not to, I think we might as well allow
autodiscovery via either element. Any implementation guide should
recommend duplicating the information in the interest of autodiscovery
actually working.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399
Yes, absolutely, that was my point. As David Baron says in Bugzilla: 
The spec was designed with the idea that any application that looked at 
rel/rev on LINK elements should do the same for A elements.

--
Sjoerd Visscher
http://w3future.com/weblog/

RE: Autodiscovery

2005-05-06 Thread Bob Wyman


Sjoerd Visscher wrote:
 [HTML 4.01 says:] This attribute describes the relationship from
 the current document to the anchor specified by the href attribute.
 The value of this attribute is a space-separated list of link types.
But, if you copy HTML from one document to another, or you construct
an HTML document from parts, you risk carrying a tags with rel attributes
from one document to another. If I quote some HTML in a new HTML document
and the quoted HTML includes rel=alternate in an a tag, are we really
saying that the presence of rel=alternate in the quoted text establishes a
relation of the new HTML document as a whole?
Personally, I think there is a serious scoping problem here. We've
got attributes of separable components of a page establishing metadata for
the page as a whole. Not good.

bob wyman

Re: Autodiscovery in a as well as link

2005-05-06 Thread Phil Ringnalda

Nikolas 'Atrus' Coukouma wrote:
Using @rel with any linking element is perfectly valid and has been for
years.
@rel not being supported for anything other than the link element itself
has also been an outstanding bug for just as long. There's lot of debate
attached to at least one Mozilla bug (#57399 [1] - filed on 2000-10-20).
Can we agree that this should be supported, but currently isn't? Unless
there's a compelling reason not to, I think we might as well allow
autodiscovery via either element. Any implementation guide should
recommend duplicating the information in the interest of autodiscovery
actually working.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399
-1 to saying in the spec that you can use either element, and in the 
guide saying to use both if you want it to work, not just look pretty.

As I remember it, when RSS autodiscovery started this cowpath, 
aggregator developers generally didn't have an SGML parser handy, and 
weren't especially happy about the idea of having to write their own 
HTML parser. Finding one (or a few) of relatively few links in the 
first bit of the document feels a lot easier than having to look at 
every a in the whole document.

Now? I'd say most don't have an SGML parser handy, and won't be 
especially happy about writing their own HTML parser. It's fairly rare 
for someone to comment out bits of their head, and quite common for 
them to comment out huge swaths of their body, including things a 
template came with, like a href=../xml/index.atom rel=feedAtom 
feed/a, with no thought that something will be seeing and using that 
invisible link with an incorrect path. I added Atom autodiscovery to my 
current aggregator, Feed on Feeds, with a ten second copy/paste/change 
mime-type of the results of it using a regular expression on the HTML. 
If instead I had to correctly parse the entire HTML document, I'd... 
switch to something in Python, I guess.

Then, since I foolishly took the Firefox bug for better autodiscovery, 
I'll also need to do it where I do have an excellent HTML parser, but I 
have to do it on every single page that every single Firefox user loads, 
whether or not they have any interest in feeds, or subscribed to the 
feed ten thousand loads of that particular page ago. link is easy, 
we've got a DOMLinkAdded event and most pages have very few of them. 
a? Well, the performance hit probably won't be noticeable on most pages.

Phil Ringnalda

Re: Autodiscovery in a as well as link

2005-05-06 Thread Roger B.


 Is there something wrong with the HTML parsers?

Nikolas: Are they installed by default on most servers? If not, can
those running in sandboxes install them?

From the perspective of my niche, I can tell you that Coldfusion can
use jTidy to make sense of random HTML, but it is (a) installed in
virtually zero CF hosting environments, and (b) cannot normally be
added by an individual developer working in a sandbox. (It's also
riddled with bugs, but I'm just grateful to have it at all... I steer
clear of gift horses' mouths whenever possible.)

--
Roger Benningfield

Re: Autodiscovery, real-world examples

2005-05-05 Thread fantasai

Nikolas 'Atrus' Coukouma wrote:
 fantasai wrote:

 I think you've missed how things are working at the moment. Most
 programs implemented what's in the spec before it's written. Mark is
 trying to negotiate a common standard when implementations already
 exist. A lot of experimentation has already occurred.
I'm not suggesting that the spec invalidate such well-entrenched practice,
but that it allows an alternative (not requiring 'alternate') for situations
in which it is not appropriate.
 One of the key points seems to be that autodiscovery is not meant to
 find all feeds linked to on a page, just the ones that serve as
 alternates to the current one. If people wanted this functionality, they
 would have done it by now.
Done what? Linked to non-alternate feeds with rel=alternate just so
that it would trigger autodiscovery? People do that all the time. Give
them an alternative that doesn't require such a hack.
 I think you have three separate cases of autodiscovery:
 * the feed for *this* page - handled by this autodiscovery proposal
 * other feeds the author reads or recommends - usually done by linking
 to a separate file. Some quick searching reveals one suggestion to use
 rel=blogroll for this
 * any other feeds linked to for any reason at all - seems to be little
 interest in

 I don't think combining these three into one case will do any good. In
 fact, I think it's confusing and unusable.
That makes sense.
I think that you're missing one key use case, though: autodiscovery of
a blog's main feed from sub-parts of it. A lot of websites link to the
main blog feed from individual entries, for example, and they're doing
it with rel=alternate, which is not appropriate. It frustrates me that
there is no way of changing these links to not use rel=alternate.
And for linking to other pages.. Here's a real-world example:
The mozilla.org main page http://www.mozilla.org/ is an example
of where rel=alternate is a problem. There were three feeds on
it: Announcements, mozillaZine News, and Mozilla Weblogs
(now only two). Each one is an alternate of a web page, but of
_other_ pages (http://www.mozilla.org/news.html, http://www.mozillazine.org/, 
and http://planet.mozilla.org/ respectively), not the mozilla.org
front page. The last few headlines for each feed are listed on
the front page, and the designer felt it was appropriate for
autodiscovery to work on this page -- but it is not appropriate
for rel=alternate to be used for those autodiscovery links.
They are not alternate representations of the front page.

Here's another example:
LiveJournal creates a Friends page, where it aggregates the
blogs of all the users you've designated as friends. It could
create an Atom feed representing this aggregation, and mark that
as rel=alternate. What could also be useful, however, would be
linking to each of these blogs' feeds individually as well so
that they're represented individually in my aggregator and it
can aggregate them itself. Unlike the pre-aggregated feed,
however, these are not alternate representations of the Friends
page, and shouldn't be marked as such.
Making it possible for pages to link to non-alternate autodiscoverable
feeds without using rel=alternate -- and encouraging this practice --
would make it possible for UAs to actually /discriminate/ between
alternate and non-alternate feeds. Right now they can't, because
everything is indiscriminately marked as alternate.
~fantasai

Re: Autodiscovery, real-world examples

2005-05-05 Thread Antone Roundy

On Thursday, May 5, 2005, at 01:27  AM, fantasai wrote:
And for linking to other pages.. Here's a real-world example:
The mozilla.org main page http://www.mozilla.org/ is an example
of where rel=alternate is a problem. There were three feeds on
it: Announcements, mozillaZine News, and Mozilla Weblogs
(now only two). Each one is an alternate of a web page, but of
_other_ pages (http://www.mozilla.org/news.html, 
http://www.mozillazine.org/, and http://planet.mozilla.org/ 
respectively), not the mozilla.org
front page. The last few headlines for each feed are listed on
the front page, and the designer felt it was appropriate for
autodiscovery to work on this page -- but it is not appropriate
for rel=alternate to be used for those autodiscovery links.
They are not alternate representations of the front page.

I'm beginning to sway in the direction of this argument, but I'm not 
sure whether I'll sway back or not.  Given that @type will clearly (for 
Atom and RSS 2 anyway, if not for RSS 1) identify the feed as a feed 
(...or maybe an Atom Entry Document...the feed reader can deal with 
that issue when the user tries to subscribe), I don't think there's a 
big need for @rel to say feed.  But it wouldn't be illogical for use 
alternate for only the feed associated with a particular page 
(perhaps including the case of an individual entry archive page), and 
something else like related to point to other feeds.  A UA could 
check @rel and @type and present a UI saying something like subscribe 
to the feed for this page and subscribe to a feed related to this 
page.

Re: Autodiscovery

2005-05-05 Thread Sjoerd Visscher

Why not support hyperlinks too?
So besides:
link rel=alternate type=application/atom+xml title=Main Atom feed 
href=/xml/index.atom

also:
a rel=alternate type=application/atom+xml 
href=/xml/index.atomMain Atom feed/a

Most webpages already have a hyperlink to the feed, so they'd only need 
to add two attributes. It would be a waste to have to duplicate the 
information in the document head.

--
Sjoerd Visscher
http://w3future.com/weblog/

Re: Autodiscovery


Sjoerd Visscher wrote:


 Why not support hyperlinks too?

 So besides:

 link rel=alternate type=application/atom+xml title=Main Atom
 feed href=/xml/index.atom

 also:

 a rel=alternate type=application/atom+xml
 href=/xml/index.atomMain Atom feed/a

 Most webpages already have a hyperlink to the feed, so they'd only
 need to add two attributes. It would be a waste to have to duplicate
 the information in the document head.

The intent of the head element is to indicate a feed that serves as a
substitute for the page you're currently viewing.

This other case is locating all feeds linked to from a page. For that,
the type attribute should be sufficient to indicate that you're linking
to a feed.

-Nikolas 'Atrus' Coukouma

-Nikolas 'Atrus' Coukouma

RE: Autodiscovery, real-world examples

2005-05-05 Thread Bob Wyman


Fantasia wrote:
 Making it possible for pages to link to non-alternate 
 autodiscoverable feeds without using rel=alternate -- and 
 encouraging this practice -- would make it possible for UAs to 
 actually /discriminate/ between alternate and non-alternate feeds.
 Right now they can't, because everything is indiscriminately marked 
 as alternate.
+1. Being able to distinguish between alternates for the current
page and just other feeds that are linked to from the page would be very
useful. Also, in the case where there are multiple real alternates to the
page, it would be useful to be able to mark which feed is preferred. My
concern here is the transition between Atom V0.3 and Atom V1.0. A page might
link to feeds in both formats (as well as RSS, RDF, etc.) but it would be
good to know which of these feeds is considered the preferred feed by the
producer. In this way, people could migrate off the older feeds and one day
we'd actually be able to stop producing multiple feeds on each site.
We should also consider providing such preferred links in Atom,
RSS, RDF, etc. feeds. I'd like to be able to publish something in my Atom
0.3 feeds that tell people Don't keep reading this feed. Read the Atom 1.0
feed instead...

bob wyman

Re: Autodiscovery

2005-05-05 Thread Sjoerd Visscher

Nikolas 'Atrus' Coukouma wrote:
Sjoerd Visscher wrote:

Why not support hyperlinks too?
So besides:
link rel=alternate type=application/atom+xml title=Main Atom
feed href=/xml/index.atom
also:
a rel=alternate type=application/atom+xml
href=/xml/index.atomMain Atom feed/a
Most webpages already have a hyperlink to the feed, so they'd only
need to add two attributes. It would be a waste to have to duplicate
the information in the document head.
The intent of the head element is to indicate a feed that serves as a
substitute for the page you're currently viewing.
This other case is locating all feeds linked to from a page. For that,
the type attribute should be sufficient to indicate that you're linking
to a feed.
No, a hyperlink with a rel attribute means the same as a link element. 
The HTML spec describes the rel attribute on the a element thus:

This attribute describes the relationship from the current document to 
the anchor specified by the href attribute. The value of this attribute 
is a space-separated list of link types.

--
Sjoerd Visscher
http://w3future.com/weblog/

Re: Autodiscovery - different cases should use different rel


fantasai wrote:


 Nikolas 'Atrus' Coukouma wrote:

  I think you have three separate cases of autodiscovery:
  * the feed for *this* page - handled by this autodiscovery proposal
  * other feeds the author reads or recommends - usually done by linking
  to a separate file. Some quick searching reveals one suggestion to use
  rel=blogroll for this
  * any other feeds linked to for any reason at all - seems to be little
  interest in
 
  I don't think combining these three into one case will do any good. In
  fact, I think it's confusing and unusable.

 That makes sense.

 I think that you're missing one key use case, though: autodiscovery of
 a blog's main feed from sub-parts of it. A lot of websites link to the
 main blog feed from individual entries, for example, and they're doing
 it with rel=alternate, which is not appropriate. It frustrates me that
 there is no way of changing these links to not use rel=alternate.

An excellent point. Perhaps these should use rel=home :)

link rel=home type=application/atom+xml href=/xml/feed.atom



 And for linking to other pages.. Here's a real-world example:
 The mozilla.org main page http://www.mozilla.org/ is an example
 of where rel=alternate is a problem. There were three feeds on
 it: Announcements, mozillaZine News, and Mozilla Weblogs
 (now only two). Each one is an alternate of a web page, but of
 _other_ pages (http://www.mozilla.org/news.html,
 http://www.mozillazine.org/, and http://planet.mozilla.org/
 respectively), not the mozilla.org
 front page. The last few headlines for each feed are listed on
 the front page, and the designer felt it was appropriate for
 autodiscovery to work on this page -- but it is not appropriate
 for rel=alternate to be used for those autodiscovery links.
 They are not alternate representations of the front page.

These other feeds are suggestion/blogroll cases.


 Here's another example:
 LiveJournal creates a Friends page, where it aggregates the
 blogs of all the users you've designated as friends. It could
 create an Atom feed representing this aggregation, and mark that
 as rel=alternate. 

Actually, a patch was just committed to do this ;)

 What could also be useful, however, would be
 linking to each of these blogs' feeds individually as well so
 that they're represented individually in my aggregator and it
 can aggregate them itself. Unlike the pre-aggregated feed,
 however, these are not alternate representations of the Friends
 page, and shouldn't be marked as such.

I think this is a suggestion/blogroll case.


 Making it possible for pages to link to non-alternate autodiscoverable
 feeds without using rel=alternate -- and encouraging this practice --
 would make it possible for UAs to actually /discriminate/ between
 alternate and non-alternate feeds. Right now they can't, because
 everything is indiscriminately marked as alternate.


 ~fantasai

I've basically concluded that the keys to autodiscovery of feeds, in the
general sense, should not be three (rel, type, and href), but two (type
and href). Type is plenty of specification that it's a feed. Claiming
it's relationship as feed doesn't seem correct. There are a few
mime-types used, and the one for atom (application/atom+xml) will be an
official standard as soon as the draft is accepted by the IETF.

The value of rel, if present, will vary based on relation
* the feed for *this* page - rel=alternate
* the feed for main feed for this blog, in general - rel=home
* other feeds the author reads or recommends - rel=suggested
* any other feeds linked to for any reason at all - no rel, just the
type and href

Is this acceptable? I'm not completely happy with home and suggested
because they're not specified as link types in the HTML specs [1].
Sadly, it seems the HTML authors didn't consider these cases. home
seems to be an informal standard. Close matches in the HTML list are
index, contents, and start. All of these are inaccurate, but I
think contents is the best fit.

suggested is just my own idea. I mentioned the rel=blogroll before,
but that seems overly specific. bookmark seems to be the closest match
in the HTML list. Not in the way it's defined in the list, but the way
people usually think of it. I'm not sure what the heck the HTML spec is
indicating with:
Refers to a bookmark. A bookmark is a link to a key entry point within
an extended document. The title attribute may be used, for example, to
label the bookmark. Note that several bookmarks may be defined in each
document.
That definition makes it a close match to home, I suppose. Really, the
definition there is so vague that it's useless.

I can think of a couple other cases:
- Comment feeds, which are only generated by a few pieces of software so
far. These are close to, but not quite, alternate. they're usually
missing the entry itself, from what I understand. I think more work
needs to be done with comment feeds in general before we worry too much
about linking to them.
-Changelogs. Wikis are one of

Re: Autodiscovery


Sjoerd Visscher wrote:

 Nikolas 'Atrus' Coukouma wrote:

 Sjoerd Visscher wrote:

 Why not support hyperlinks too?

 So besides:

 link rel=alternate type=application/atom+xml title=Main Atom
 feed href=/xml/index.atom

 also:

 a rel=alternate type=application/atom+xml
 href=/xml/index.atomMain Atom feed/a

 Most webpages already have a hyperlink to the feed, so they'd only
 need to add two attributes. It would be a waste to have to duplicate
 the information in the document head.


 The intent of the head element is to indicate a feed that serves as a
 substitute for the page you're currently viewing.

 This other case is locating all feeds linked to from a page. For that,
 the type attribute should be sufficient to indicate that you're linking
 to a feed.


 No, a hyperlink with a rel attribute means the same as a link element.
 The HTML spec describes the rel attribute on the a element thus:

 This attribute describes the relationship from the current document to
 the anchor specified by the href attribute. The value of this
 attribute is a space-separated list of link types.

What I was getting at is that link elements in the head are usually a
kind of metadata intended for the user agent. Hyperlinks are usually
meant to be displayed. This proposal is aimed at providing metadata for
the user agent, so it makes since to put it in a link element in the head.

I'm on the fence about whether or not a link element should be the
*required*, even when a hyperlink is present in the body.

Supporting general hyperlinks starts making more sense if we have cases
other than alternate (I've written elsewhere about this) because the
amount of duplicated information is much greater. If you're only
supporting feeds that serve as an alternate form of the content, then it
makes sense to repeat one link once just to make the programmer stuck
writing the user agent. I'd hope that whatever library/toolkit they're
using supports XPath queries. Using them makes it easy to pluck out
anything with type=application/atom+xml and an href property.

It's worth noting that in recent versions of XHTML, anything with an
href property is a hyperlink. There's no requirement to use an anchor or
an xlink:link element.

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery


Nikolas 'Atrus' Coukouma wrote:

I'm on the fence about whether or not a link element should be the
*required*, even when a hyperlink is present in the body.

Supporting general hyperlinks starts making more sense if we have cases
other than alternate (I've written elsewhere about this) because the
amount of duplicated information is much greater. If you're only
supporting feeds that serve as an alternate form of the content, then it
makes sense to repeat one link once just to make the programmer stuck
writing the user agent.
  

correction:
just to make [things easier for] the programmer stuck writing the user
agent.

-Nikolas 'Atrus' Coukouma

RE: Autodiscovery, real-world examples

2005-05-05 Thread James Tauber


On Thu, 5 May 2005 16:35:21 -0400, Bob Wyman [EMAIL PROTECTED] said:
 Being able to distinguish between alternates for the current
 page and just other feeds that are linked to from the page would be
 very useful.

+1

 Also, in the case where there are multiple real alternates to the
 page, it would be useful to be able to mark which feed is preferred.

+0.5

James

Re: Autodiscovery

2005-05-05 Thread Sjoerd Visscher


Supporting general hyperlinks starts making more sense if we have cases
other than alternate (I've written elsewhere about this) because the
amount of duplicated information is much greater. If you're only
supporting feeds that serve as an alternate form of the content, then it
makes sense to repeat one link once just to make the programmer stuck
writing the user agent. I'd hope that whatever library/toolkit they're
using supports XPath queries. Using them makes it easy to pluck out
anything with type=application/atom+xml and an href property.
Maybe atom needs only one link with a rel attribute, but there are 
others. I have a lot of hyperlinks with rel attributes on my weblog 
homepage, and I refuse to repeat them all as link elements.

--
Sjoerd Visscher
http://w3future.com/weblog/

Re: Autodiscovery - different cases should use different rel

2005-05-05 Thread Eric Scheid


On 6/5/05 7:22 AM, Nikolas 'Atrus' Coukouma [EMAIL PROTECTED] wrote:

 I've basically concluded that the keys to autodiscovery of feeds, in the
 general sense, should not be three (rel, type, and href), but two (type
 and href). Type is plenty of specification that it's a feed. Claiming
 it's relationship as feed doesn't seem correct. There are a few
 mime-types used, and the one for atom (application/atom+xml) will be an
 official standard as soon as the draft is accepted by the IETF.

Using @type only is not sufficient, since both Atom Feed Documents *and*
Atom Entry Documents use the same mime-type. One is a feed, the other is
not.

Similarly, RSS 1.0 isn't clearly distinguished by mime-type - there are lots
of other resources which are 'application/rdf+xml' (eg. FOAF)

e.

Re: Autodiscovery - different cases should use different rel

2005-05-05 Thread fantasai

Nikolas 'Atrus' Coukouma wrote:
fantasai wrote:
An excellent point. Perhaps these should use rel=home :)
link rel=home type=application/atom+xml href=/xml/feed.atom
...
The value of rel, if present, will vary based on relation
* the feed for *this* page - rel=alternate
* the feed for main feed for this blog, in general - rel=home
* other feeds the author reads or recommends - rel=suggested
* any other feeds linked to for any reason at all - no rel, just the
type and href
Is this acceptable? I'm not completely happy with home and suggested
because they're not specified as link types in the HTML specs [1].
Sadly, it seems the HTML authors didn't consider these cases. home
seems to be an informal standard. Close matches in the HTML list are
index, contents, and start. All of these are inaccurate, but I
think contents is the best fit.
Actually, I think start is the best fit. The main feed is often not a
table of contents to the entire weblog, but something partial. It is,
however, the starting point of the collection.
BTW, you might want to take a look at
  http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html
  http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html
~fantasai

Re: Autodiscovery

2005-05-05 Thread fantasai

Sjoerd Visscher wrote:
Why not support hyperlinks too?
So besides:
link rel=alternate type=application/atom+xml title=Main Atom feed 
href=/xml/index.atom

also:
a rel=alternate type=application/atom+xml 
href=/xml/index.atomMain Atom feed/a

Most webpages already have a hyperlink to the feed, so they'd only need 
to add two attributes. It would be a waste to have to duplicate the 
information in the document head.
The difference between link and a is that
  - link applies to the document as a whole: it indicates a relationship
between this document and the href destination.
  - a is a contextual link: it indicates a relationship between the
linking context and the href destination.
They have different purposes. It is imho perfectly reasonable to limit
autodiscovery to links only. It is also perfectly reasonable to link
to feeds with a, and expect that the UA will recognize it as a feed
rather than a generic XML document.
~fantasai

Re: Autodiscovery - different cases should use different rel


fantasai wrote:


 Nikolas 'Atrus' Coukouma wrote:

 fantasai wrote:

 An excellent point. Perhaps these should use rel=home :)

 link rel=home type=application/atom+xml href=/xml/feed.atom

 ...


 The value of rel, if present, will vary based on relation
 * the feed for *this* page - rel=alternate
 * the feed for main feed for this blog, in general - rel=home
 * other feeds the author reads or recommends - rel=suggested
 * any other feeds linked to for any reason at all - no rel, just the
 type and href

 Is this acceptable? I'm not completely happy with home and suggested
 because they're not specified as link types in the HTML specs [1].
 Sadly, it seems the HTML authors didn't consider these cases. home
 seems to be an informal standard. Close matches in the HTML list are
 index, contents, and start. All of these are inaccurate, but I
 think contents is the best fit.


 Actually, I think start is the best fit. The main feed is often not a
 table of contents to the entire weblog, but something partial. It is,
 however, the starting point of the collection.

Actually, I disagree with start because of the first sentence in the
HTML spec:
Refers to the first document in a collection of documents.
This indicates that start should point to the first post in a weblog.
end would be the most recent (not that end exists in the HTML spec)

This link type tells search engines which document is considered by the
author to be the starting point of the collection.
This is a completely different meaning and I'm not sure why it's bundled
with the first. According to this, start pointing to the homepage is fine.


 The end or last would be the most recent (not that the HTML specs have
an end or last rel)


 BTW, you might want to take a look at

   http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html
   http://fantasai.tripod.com/qref/Appendix/LinkTypes/alphindex.html

 ~fantasai

No offense, but with all the tripod ads, I would have much preferred a
link to the Hypertext links in HTML draft [1]. Section four is what I
want. It's not indexed alphabetically and doesn't combine other
documents, but it's the covers everything pretty well.

[1] http://www.w3.org/MarkUp/draft-ietf-html-relrev-00.txt

-Nikolas 'Atrus'

Re: Autodiscovery

Phil Ringnalda wrote:

 Arve Bersvendsen wrote:

On Tue, 03 May 2005 18:52:59 +0200, Tim Bray [EMAIL PROTECTED] wrote:
http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt

1) Change the attribute value for the rel from alternate to feed, 
Don't forget, since you would be doing that primarily for people who 
think too much, that you'll also need to include a profile [1] URI and 
make a guess at what dereferencing that URI ought to return, and 
probably take a stab at explaining how to deal with multiple profiles, 
since the HTML spec punted on that.
This would not be necessary if 'feed' were added to the HTML standard
directly.
Popularizing feed would have one benefit outside Atom's scope, though: 
there's currently no useful way for an RSS 1.0 feed to do autodiscovery 
with type=application/rdf+xml since it could be any alternate RDF, not 
just RSS: if Atom breaks the ice with feed then RSS 1.0 wins.
'feed' is not really defining a /relation/, it's defining a sort of
meta-content-type... But I would much prefer that to forcing 'alternate'
on non-'alternate' links.
~fantasai
(Copying to WHATWG mailing list: http://www.whatwg.org/ )

Re: Autodiscovery

2005-05-04 Thread Henri Sivonen

On May 4, 2005, at 02:56, David Nesting wrote:
Plus, feed is kind of application-specific.  What about related?
It's a spec for discovering *feeds*. It is proper to have an 
app-specific rel value to avoid feed-specific apps downloading non-feed 
related documents.

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: Autodiscovery


On 4/5/05 3:52 PM, fantasai [EMAIL PROTECTED] wrote:

 'feed' is not really defining a /relation/, it's defining a sort of
 meta-content-type... But I would much prefer that to forcing 'alternate'
 on non-'alternate' links.

instead of feed, consider updates, which gets closer to the gist of the
sense

e.

Re: AutoDiscovery

2005-05-04 Thread Anne van Kesteren

Randy Charles Morin wrote:
+1 to adding lang as an attribute to link
thanks Robert
link lang='en' ...
The HTML and XHTML specification already define that.
--
 Anne van Kesteren
 http://annevankesteren.nl/

Re: Autodiscovery

2005-05-04 Thread Antone Roundy

On Tuesday, May 3, 2005, at 11:41  PM, fantasai wrote:
David Nesting wrote:
I expect that many of my implementations will utilize content 
negotiation
(using the same URL as an HTML representation, where needed), so I 
expect
that I'll have some links like:
  link rel=alternate href=/ type=application/atom+xml
  link rel=alternate href=/ type=application/rss+xml
Or even
  link rel=alternate href= type=application/atom+xml
  link rel=alternate href= type=application/rss+xml
That won't work, because content negotiation will continue to return
the same thing it returned just now. You must somehow tell the server
to return a specific other version of the current document, and you
do that typically by sending a GET request with a different URL --
one that specifies a particular version of the resource.
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14
GET /path-to-the-feed HTTP/1.1
Accept: application/atom+xml
...
You don't have to change the URL--just list only the format you want in 
the Accept header.  If the autodiscovery link was lying/mistaken and 
that format really isn't available at that URL, you should get a 406 
(not acceptable) response.

Re: Autodiscovery

2005-05-04 Thread Robert Sayre


On 5/4/05, fantasai [EMAIL PROTECTED] wrote:
 
  Who's to say we can't overload it a little for this case?
 
 You are not writing the HTML 4.01 spec, you're writing an autodiscovery
 spec that takes advantage of the syntax *and semantics* given in HTML 4.
 Your specification should be consistent with HTML 4, not contradictory
 to it.

The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation. It is not contradictory.

Robert Sayre

Re: Autodiscovery

2005-05-04 Thread Joe Gregorio


On 5/4/05, Robert Sayre [EMAIL PROTECTED] wrote:
 
 On 5/4/05, fantasai [EMAIL PROTECTED] wrote:
 
   Who's to say we can't overload it a little for this case?
 
  You are not writing the HTML 4.01 spec, you're writing an autodiscovery
  spec that takes advantage of the syntax *and semantics* given in HTML 4.
  Your specification should be consistent with HTML 4, not contradictory
  to it.
 
 The autodiscovery spec is a reasonable interpretation of the *one
 line* definition of the 'alternate' relation. It is not contradictory.

+1

-- 
Joe Gregoriohttp://bitworking.org

Re: Autodiscovery

Arve Bersvendsen wrote:
On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid  
[EMAIL PROTECTED] wrote:

instead of feed, consider updates, which gets closer to the gist 
of  the sense
No. To me 'Updates' signifies that something is 'updated'. Even posting  
new content falls outside of that definition.
That would signify updates to my document. If I'm linking to the
CNN news feed, or my-favorite-blog, that wouldn't be appropriate.
For this purpose, the syntax needs to signify that this is a feed,
that it needs to be handled as such.. and that there is no other
significant relationship between the document and the feed it links
to (unless otherwise specified).
~fantasai

Re: Autodiscovery

Robert Sayre wrote:
On 5/4/05, fantasai [EMAIL PROTECTED] wrote:
Who's to say we can't overload it a little for this case?
You are not writing the HTML 4.01 spec, you're writing an autodiscovery
spec that takes advantage of the syntax *and semantics* given in HTML 4.
Your specification should be consistent with HTML 4, not contradictory
to it.
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation. It is not contradictory.
The definition of 'alternate' is not one line long on my screen, but
here's the first sentence of it:
 # Alternate
 #   Designates substitute versions for the document in which the link occurs.
 -- http://www.w3.org/TR/REC-html40/types.html#h-6.12
How is a link from the top of my homepage to my friend's weblog feed
designating a substitute version for the document in which the link
occurs?
Note that we are not arguing the semantics of the link element in
an Atom document, but the semantics of the link element in an HTML
document.
~fantasai

Re: Autodiscovery

2005-05-04 Thread Robert Sayre


On 5/4/05, fantasai [EMAIL PROTECTED] wrote:
 
 The definition of 'alternate' is not one line long on my screen, but
 here's the first sentence of it:
 
   # Alternate
   #   Designates substitute versions for the document in which the link 
 occurs.
 
   -- http://www.w3.org/TR/REC-html40/types.html#h-6.12
 
 How is a link from the top of my homepage to my friend's weblog feed
 designating a substitute version for the document in which the link
 occurs?

I don't know, but I'm not sure why you think that's what the
autodiscovery spec endorses. Is there some part of the spec that
endorses that? The autodiscovery spec is for use by UAs like Mozilla
and Safari that present little icons alerting the user to a feed
version of a page. Often, I never visit the page again, once I've
subscribed to the feed. The feed is a substitute.

 Note that we are not arguing the semantics of the link element in
 an Atom document, but the semantics of the link element in an HTML
 document.

Yes, I caught that.

Robert Sayre

Re: Autodiscovery


On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:

 The autodiscovery spec is a reasonable interpretation of the *one
 line* definition of the 'alternate' relation.

how is a feed of recent entries a substitute version for the document in
which the link occurs when that document is some blog post long since
dropped out of the feed?

 Alternate
 Designates substitute versions for the document in which the link occurs. When
 used together with the lang attribute, it implies a translated version of the
 document. When used together with the media attribute, it implies a version
 designed for a different medium (or media).

Re: Autodiscovery

2005-05-04 Thread Thomas Broyer

Robert Sayre wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation. It is not contradictory.
But a feed is not a substitute version of an archive page as most 
archived entries are not in the feed anymore.

That said, I'm totally in favor of using rel=alternate to link to a 
feed from the _alternate_ HTML version.

From an archive page, you should rather use rel=start.
Actually, here's my view of those things:
In the latest news page (generally the homepage for a weblog):
link rel=alternate type=application/atom+xml href=feed.atom
In a category page:
link rel=start type=text/html href=../index.html
link rel=start type=application/atom+xml href=../feed.atom
link rel=alternate type=application/atom+xml href=category.atom
link rel=section type=text/html href=category/index.html
link rel=section type=application/atom+xml 
href=category/category.atom

In a single-entry archive page:
link rel=start type=text/html href=../../index.html
link rel=start type=application/atom+xml href=../../feed.atom
link rel=section type=text/html href=../index.html
link rel=section type=application/atom+xml href=../category.atom
!-- no alternate --
However, is this enough for the autodiscovery purpose?
--
Thomas Broyer

Re: Autodiscovery

2005-05-04 Thread Roger B.


 how is a feed of recent entries a substitute version for the document in
 which the link occurs when that document is some blog post long since
 dropped out of the feed?

Eric: A devil's advocacy moment... if I change the published date for
the document to today's date, it will suddenly spring forward into my
feed of recent entries. And at some point in the past, it was already
in that feed.

--
Roger Benningfield

Re: Autodiscovery

2005-05-04 Thread Dan Brickley


* Eric Scheid [EMAIL PROTECTED] [2005-05-05 02:35+1000]
 
 On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:
 
  The autodiscovery spec is a reasonable interpretation of the *one
  line* definition of the 'alternate' relation.
 
 how is a feed of recent entries a substitute version for the document in
 which the link occurs when that document is some blog post long since
 dropped out of the feed?

Because the HTML definition is close to meaningless. I can substitute
any document for another, and the 2nd is a substitution not through any 
intrinsic characteristics, but because it was substituted. Many of the 
HTML link type definitions don't bear up under detailed scrutiny...

Dan

Re: Autodiscovery

Dan Brickley wrote:
* Eric Scheid [EMAIL PROTECTED] [2005-05-05 02:35+1000]
On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:

The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.
how is a feed of recent entries a substitute version for the document in
which the link occurs when that document is some blog post long since
dropped out of the feed?
Because the HTML definition is close to meaningless. I can substitute
any document for another, and the 2nd is a substitution not through any 
intrinsic characteristics, but because it was substituted. Many of the 
HTML link type definitions don't bear up under detailed scrutiny...
I think you're taking your anarchic interpretation a little too far there.
Especially there: if you read the *spec*, you might notice that the definition
of 'alternate' continues:
  # When used together with the media attribute, it implies a version
  # designed for a different medium (or media).
From section 12.2.4, we also have
  #  The rel attribute specifies the relationship of the linked document
  # with the current document.
So, according to HTML 4.01 -- which is the definitive spec as far as HTML
is concerned -- the following link
   link rel=alternate type=application/atom+xml href=feed.atom
designates a link to a version of the linking document that is
application/atom+xml.
Again, my friend's blog feed is not an Atom version of /my/ web page;
linking to it as alternate would be wrong.
~fantasai

Re: Autodiscovery

2005-05-04 Thread Tim Bray

On May 4, 2005, at 11:02 AM, Robert Sayre wrote:
I think it would be a mistake to see this as an opportunity to invent
a supremely capable and expressive autodiscovery spec. I've seen
mozilla, safari, NNW do autodiscovery. I'm sure bots from PubSub,
Technorati, Yahoo, etc do it as well. We should document what they do,
and settle on one arbitrary choice where they differ for no good
reason.
Mark's draft does an excellent job of documenting that reality.
+1.
It's Good Enough.  -Tim

Re: Autodiscovery

Antone Roundy wrote:
On Tuesday, May 3, 2005, at 11:41  PM, fantasai wrote:
David Nesting wrote:
I expect that many of my implementations will utilize content 
negotiation
(using the same URL as an HTML representation, where needed), so I 
expect
that I'll have some links like:
  link rel=alternate href=/ type=application/atom+xml
  link rel=alternate href=/ type=application/rss+xml
Or even
  link rel=alternate href= type=application/atom+xml
  link rel=alternate href= type=application/rss+xml
That won't work, because content negotiation will continue to return
the same thing it returned just now. You must somehow tell the server
to return a specific other version of the current document, and you
do that typically by sending a GET request with a different URL --
one that specifies a particular version of the resource.
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14
GET /path-to-the-feed HTTP/1.1
Accept: application/atom+xml
...
You don't have to change the URL--just list only the format you want in 
the Accept header.  If the autodiscovery link was lying/mistaken and 
that format really isn't available at that URL, you should get a 406 
(not acceptable) response.
Where does it say that including a 'type' attribute on a link forces
the UA to send a restricted Accept header?
~fantasai

Re: Autodiscovery

2005-05-04 Thread Julian Reschke

Antone Roundy wrote:
On Wednesday, May 4, 2005, at 12:59  PM, fantasai wrote:
Again, my friend's blog feed is not an Atom version of /my/ web page;
linking to it as alternate would be wrong.

To me, this raises a red flag, suggesting that using an autodiscovery 
link from your web page to your friend's feed is not what autodiscovery 
is intended for.
+1
Julian

Re: Autodiscovery

Antone Roundy wrote:
On Wednesday, May 4, 2005, at 12:59  PM, fantasai wrote:
Again, my friend's blog feed is not an Atom version of /my/ web page;
linking to it as alternate would be wrong.
To me, this raises a red flag, suggesting that using an autodiscovery 
link from your web page to your friend's feed is not what autodiscovery 
is intended for.
Probably not. But the same argument applies if I have an autodiscovery
link from a single entry in my blog to the main blog feed (which is a
valid alternate version of my weblog's front page, but not of that single
entry).
~fantasai

Re: Autodiscovery

2005-05-04 Thread Joe Gregorio


On 5/4/05, Robert Sayre [EMAIL PROTECTED] wrote: 
 Mark's draft does an excellent job of documenting that reality. 

+1

   -joe

-- 
Joe Gregoriohttp://bitworking.org

Re: Autodiscovery


fantasai wrote:


 Arve Bersvendsen wrote:


 On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid 
 [EMAIL PROTECTED] wrote:

 instead of feed, consider updates, which gets closer to the gist
 of  the sense


 No. To me 'Updates' signifies that something is 'updated'. Even
 posting  new content falls outside of that definition.


 That would signify updates to my document. If I'm linking to the
 CNN news feed, or my-favorite-blog, that wouldn't be appropriate.
 For this purpose, the syntax needs to signify that this is a feed,
 that it needs to be handled as such.. and that there is no other
 significant relationship between the document and the feed it links
 to (unless otherwise specified).

 ~fantasai

These are both valid interpretations of updates. From Princeton's WordNet:
update - n - news that updates your information
- v - 1: modernize or bring up to date; We updated the kitchen in the
old house
  2: bring up to date; supply with recent information
  3: bring to the latest state of technology

As this definition suggests, most people think of updates as
modifications of items that already exists first and completely new
items second. In the land of feeds, the frequency is reversed (most
updates in feeds are new items, not modifications to existing ones).

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery


fantasai wrote:


 Arve Bersvendsen wrote:


 On Wed, 04 May 2005 09:43:38 +0200, Eric Scheid 
 [EMAIL PROTECTED] wrote:

 instead of feed, consider updates, which gets closer to the gist
 of  the sense


 No. To me 'Updates' signifies that something is 'updated'. Even
 posting  new content falls outside of that definition.


 That would signify updates to my document. If I'm linking to the
 CNN news feed, or my-favorite-blog, that wouldn't be appropriate.
 For this purpose, the syntax needs to signify that this is a feed,
 that it needs to be handled as such.. and that there is no other
 significant relationship between the document and the feed it links
 to (unless otherwise specified).

 ~fantasai

These are both valid interpretations of updates. From Princeton's WordNet:
update - n - news that updates your information
- v - 1: modernize or bring up to date; We updated the kitchen in the
old house
  2: bring up to date; supply with recent information
  3: bring to the latest state of technology

As this definition suggests, most people think of updates as
modifications of items that already exists first and completely new
items second. In the land of feeds, the frequency is reversed (most
updates in feeds are new items, not modifications to existing ones).

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery


Eric Scheid wrote:

On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:

  

The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.



how is a feed of recent entries a substitute version for the document in
which the link occurs when that document is some blog post long since
dropped out of the feed?

I'd suggest placing the link element only on the front page of your blog
if this is a concern. The feed usually is a substitute version for the
document in which the link occurs for that, at least. There's nothing
in the spec that even suggests you to place the autodiscovery
information in archive pages. In practice, people probably will, but I'm
not sure it's worth worrying about.

Do you have some example that's more generally applicable?

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery

2005-05-04 Thread Antone Roundy

On Wednesday, May 4, 2005, at 04:49  PM, Nikolas 'Atrus' Coukouma wrote:
Eric Scheid wrote:
On 4/5/05 11:11 PM, Robert Sayre [EMAIL PROTECTED] wrote:
The autodiscovery spec is a reasonable interpretation of the *one
line* definition of the 'alternate' relation.
how is a feed of recent entries a substitute version for the 
document in
which the link occurs when that document is some blog post long since
dropped out of the feed?
I'd suggest placing the link element only on the front page of your 
blog
if this is a concern. The feed usually is a substitute version for the
document in which the link occurs for that, at least. There's nothing
in the spec that even suggests you to place the autodiscovery
information in archive pages. In practice, people probably will, but 
I'm
not sure it's worth worrying about.
There is a good reason for putting the link in the individual entry 
pages: if people get to your blog via some location other than your 
blog homepage, you don't want them to have to go to your homepage to 
subscribe to your blog's feed.  In such a case, sure, alternate 
wouldn't be descriptive of the feed's relationship to the isolated 
page, but the way that such links will be processed by browsers will 
match the intent for publishing the link - if you find this entry 
interesting enough to want to subscribe to my feed, here's where to do 
it.

I personally don't care whether it's alternative or something like 
feed.  Alternative is a more generally applicable term, but yeah, 
it doesn't sound quite right on individual entry pages.

Re: Autodiscovery


On 5/5/05 4:02 AM, Thomas Broyer [EMAIL PROTECTED] wrote:

 Robert Sayre wrote:
 The autodiscovery spec is a reasonable interpretation of the *one
 line* definition of the 'alternate' relation. It is not contradictory.
 
 But a feed is not a substitute version of an archive page as most
 archived entries are not in the feed anymore.
 
 That said, I'm totally in favor of using rel=alternate to link to a
 feed from the _alternate_ HTML version.
 
 From an archive page, you should rather use rel=start.

The problem is, an automaton wouldn't know which to use as it wouldn't know
if the page it is looking at is an entry archive page or a recent entries
page, which rather defeats the purpose of auto-discovery.

Also, it would be entirely reasonable to use @rel='alternate' to point to an
@type='application/atom+xml' Atom Entry Document from an archive page.

Furthermore, from a recent entries page it would also be entirely reasonable
to use @rel='start' to point to the first archive entry page.

Thus, the meanings of 'alternate' and 'start' would be *reversed* depending
on what kind of page you were looking at. This is not conducive to
hands-free auto discovery.

Using @rel='feed' from both kinds of pages fixes that problem.

e.

Re: Autodiscovery


On 5/5/05 4:17 AM, Dan Brickley [EMAIL PROTECTED] wrote:

 The autodiscovery spec is a reasonable interpretation of the *one
 line* definition of the 'alternate' relation.
 
 how is a feed of recent entries a substitute version for the document in
 which the link occurs when that document is some blog post long since
 dropped out of the feed?
 
 Because the HTML definition is close to meaningless. I can substitute
 any document for another, and the 2nd is a substitution not through any
 intrinsic characteristics, but because it was substituted. Many of the
 HTML link type definitions don't bear up under detailed scrutiny...

Only if you take the most broadest sense of the word 'substitute'.

This is like saying that not only is olive oil a substitute for butter in
cooking, but so is engine oil, concrete, a 400 pound gorilla, and the square
root of the gross national product of madagascar.

No, I suspect they used the word 'substitute' in it's more narrow sense, and
they used the word 'substitute' because they didn't want to write
alternate: Designates an alternate version for the document in which the
link occurs which would be circular.

e.

Re: Autodiscovery


On 5/5/05 5:20 AM, Antone Roundy [EMAIL PROTECTED] wrote:

 On Wednesday, May 4, 2005, at 12:59  PM, fantasai wrote:
 Again, my friend's blog feed is not an Atom version of /my/ web page;
 linking to it as alternate would be wrong.
 
 To me, this raises a red flag, suggesting that using an autodiscovery
 link from your web page to your friend's feed is not what autodiscovery
 is intended for.

I agree.

However, using a link from an archive page is common practice (very!), but
is one that would confound the use of Atom Entry Documents as
@rel='alternate'.

e.

Re: Autodiscovery


Eric Scheid wrote:

On 5/5/05 4:38 AM, Nikolas 'Atrus' Coukouma [EMAIL PROTECTED] wrote:
  

Do you have some example that's more generally applicable?



in practice, people will put a link to the feed from which this page, and
others like it, are likely to be found, into entry only pages.

otherwise auto-discovery doesn't work unless you first navigate to the front
page of someone's blog.

people want to be able to say here's a link to my feed from entry pages.

e.

As I said I'm not sure it's worth worrying about. My current opinion
is that it's just not worth making this change at this point, if this is
in fact the only concern. It applies to a large number of pages with a
small number of views and those are done for usability. Even if pages
only had the link on the main page, I think it would allow 95% of users
to find it. Maybe this is more of a concern for blogs where the archives
are a major entry point. Perhaps this is even the usual case and I'm
just used to people coming in the front door. What are the chances of
someone subscribing to your feed if they never even look at the front page?

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery and alternate

2005-05-04 Thread Kevin Marks

How about alternate be recommended for only true substitutes; a feed 
for comments or pictures should not be labelled alternate, as it is 
not a substitute. feed is appealing, but does fly in the face of 
practice.

There are existing rel values that could apply to qualify other kinds 
of feeds, or we could suggest new ones.

eg, if it is an titles-only feed, rel=contents would apply
If you had both full-content and summary feeds available, this could be 
indicated in a machine readable way (I appreciate that Atom handles 
this properly within the format, unlike RSS, but offering both versions 
is something I see many sites doing).

I am amazed that there was no rel=summary defined by the w3c; this 
would be a useful extension to consider.

http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links
On May 3, 2005, at 10:29 PM, fantasai wrote:
Arve Bersvendsen wrote:
On Tue, 03 May 2005 18:52:59 +0200, Tim Bray [EMAIL PROTECTED] wrote:
http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt
1) Change the attribute value for the rel from alternate to feed, 
or  some similar wording.  A feed is not always an alternate of the 
HTML  document in which it occurs.
As I mentioned last November [1] I agree with not requiring the
'alternate' rel value for the reasons stated in
  http://fantasai.inkedblade.net/weblog/2004/linking-feeds/
Briefly, it is an abuse of its semantics because many feed links
are not links to alternate representations of the current page.
[1] http://www.imc.org/atom-syntax/mail-archive/msg11705.html
~fantasai

Re: Autodiscovery