Re: Autodiscovery Draft

[Elliotte Harold]

John Panzer wrote:
There were strong suggestions at the time, I think, that this was part 
of HTML and should belong to the WHAT-WG.


So is there a WHAT-WG document to look at?



Yes. http://www.whatwg.org/specs/web-apps/current-work/#link-type5


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/

Re: Autodiscovery Draft

[Anne van Kesteren]

On Mon, 19 Mar 2007 23:00:34 +0100, John Panzer <[EMAIL PROTECTED]> wrote:

There were strong suggestions at the time, I think, that this was part
of HTML and should belong to the WHAT-WG.

So is there a WHAT-WG document to look at?


http://www.whatwg.org/specs/web-apps/current-work/#linkTypes


--
Anne van Kesteren

Re: Autodiscovery Draft

[Eric Scheid]

On 20/3/07 9:00 AM, "John Panzer" <[EMAIL PROTECTED]> wrote:

> Also, is there a standard way to discover the collection associated with a
> feed?  (Given that, if there is an IETF or WHAT-WG way to discover feeds,
> there's an obvious way to discover collections... but I'm not clear on what
> that would be.  I do think that collection autodisco is important.)

please remember that there may be multiple collections collated into one
feed ... and that various members of one collection may be represented in
many different feeds.

it's not 1:1.

e.

Re: Autodiscovery Draft

[James M Snell]

John Panzer wrote:
> [snip]
> Also, is there a standard way to discover the collection associated with
> a feed?  (Given that, if there is an IETF or WHAT-WG way to discover
> feeds, there's an obvious way to discover collections... but I'm not
> clear on what that would be.  I do think that collection autodisco is
> important.)

An app:collection element can appear within atom:feed and atom:source
elements.

- James

Re: Autodiscovery Draft

[John Panzer]

There were strong suggestions at the time, I think, that this was part 
of HTML and should belong to the WHAT-WG.


So is there a WHAT-WG document to look at?

Also, is there a standard way to discover the collection associated with 
a feed?  (Given that, if there is an IETF or WHAT-WG way to discover 
feeds, there's an obvious way to discover collections... but I'm not 
clear on what that would be.  I do think that collection autodisco is 
important.)


-John

James M Snell wrote:

The autodisco draft originally authored by Mark Pilgrim and resurrected
by me late last year.

http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt

- James

Jan Algermissen wrote:
  

James,

what draft do you refer to?

Thanks,
Jan

On 19.03.2007, at 20:50, James M Snell wrote:



I'm assuming that since there was no additional expressed interest in
moving forward with the Atom autodiscovery draft that it's not going to
go anywhere.  My current intention is to go ahead and let it expire
again without any further modifications.

- James

  



  

Re: Autodiscovery Draft

[Jan Algermissen]

James,

what draft do you refer to?

Thanks,
Jan

On 19.03.2007, at 20:50, James M Snell wrote:



I'm assuming that since there was no additional expressed interest in
moving forward with the Atom autodiscovery draft that it's not  
going to

go anywhere.  My current intention is to go ahead and let it expire
again without any further modifications.

- James

Re: Autodiscovery Draft

[James M Snell]

The autodisco draft originally authored by Mark Pilgrim and resurrected
by me late last year.

http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt

- James

Jan Algermissen wrote:
> James,
> 
> what draft do you refer to?
> 
> Thanks,
> Jan
> 
> On 19.03.2007, at 20:50, James M Snell wrote:
> 
>>
>> I'm assuming that since there was no additional expressed interest in
>> moving forward with the Atom autodiscovery draft that it's not going to
>> go anywhere.  My current intention is to go ahead and let it expire
>> again without any further modifications.
>>
>> - James
>>
> 
> 

Re: Autodiscovery IPR and Process Concerns

[Robert Sayre]

On 11/30/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:


What rhetorical device is it to point out the rhetorical devices
used by other participants in a discussion?


Gosh, Aristotle. I'm sure I don't know. Y'all let me know when y'all
figure it out.

- Bobby

Re: Autodiscovery IPR and Process Concerns

[A. Pagaltzis]

* Robert Sayre <[EMAIL PROTECTED]> [2006-11-30 08:10]:
> On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote:
> >   If y'all think
> 
> Ah, this is what's called "innappropriately folksy". It's
> a common rhetorical device used when the speaker wants to
> appear that they're on the side of "the common man" or
> equivalent.

What rhetorical device is it to point out the rhetorical devices
used by other participants in a discussion?

> The president of the United States makes frequent use of this
> device.

What rhetorical device is it to use inappropriate and entirely
irrelevant political analogies in the hopes of derailing
a discussion?

Regards,
-- 
Aristotle Pagaltzis // 

Re: autodiscovery draft vs namespaces

[James M Snell]

Kornel, thanks for the input. In the next rev of the draft (following
the initial reboot that should publish in a day or so) I'll see what I
can do to clarifying some of these issues.  As always, suggested spec
text is helpful and encouraged.  I will do my best to incorporate all
editorial changes.

- James

Kornel Lesinski wrote:
> 
> 
> I've noticed that draft-ietf-atompub-autodiscovery-01.txt doesn't
> mention XML namespaces and tag prefixes. XHTML can get even more complex
> than memo suggests:
> 
> http://www.w3.org/1999/xhtml"; rel="alternate"
> type="application/atom+xml" href="bar">
> 
> My suggestion is that instead of specifying all quirks of X[HT]ML syntax:
> * require that XML parser is used for XHTML
> * if document turns out not to be well-formed (which often is the case
> with real-world "XHTML"), allow HTML parsing rules used as fallback
> 
> And then simply state that in XHTML  element in
> "http://www.w3.org/1999/xhtml"; namespace should be used. An example
> XPath expression or W3C DOM-based pseudocode might be very helpful there.
> 
> 
> BTW: in all examples attributes have always the same order. They could
> be shuffled to emphasise that order is not significant.
> 
> --regards, Kornel Lesiński
> 
> 

Re: autodiscovery draft vs namespaces

[Kornel Lesinski]

I've noticed that draft-ietf-atompub-autodiscovery-01.txt doesn't mention  
XML namespaces and tag prefixes. XHTML can get even more complex than memo  
suggests:


http://www.w3.org/1999/xhtml"; rel="alternate"  
type="application/atom+xml" href="bar">


My suggestion is that instead of specifying all quirks of X[HT]ML syntax:
* require that XML parser is used for XHTML
* if document turns out not to be well-formed (which often is the case  
with real-world "XHTML"), allow HTML parsing rules used as fallback


And then simply state that in XHTML  element in  
"http://www.w3.org/1999/xhtml"; namespace should be used. An example XPath  
expression or W3C DOM-based pseudocode might be very helpful there.



BTW: in all examples attributes have always the same order. They could be  
shuffled to emphasise that order is not significant.


--
regards, Kornel Lesiński

RE: Autodiscovery

[Anil Dash]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-atom-
> [EMAIL PROTECTED] On Behalf Of Kevin Marks
> Subject: Re: Autodiscovery
> 
> On May 6, 2005, at 12:21 PM, Bob Wyman wrote:
> 
> >
> > 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.

Not to go *too* far off-topic, but is syndication/aggregation a media
type instead of (or in combination with) merely an alternate rel type?


__
Anil Dash  +1 646 541 5843

Re: Autodiscovery

[Kevin Marks]

On May 6, 2005, at 12:21 PM, Bob Wyman wrote:
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  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  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, you're the one making them seperable. The HTML spec is very 
document-focused; when you migrate HTML from one document to another, 
it is your responsibility to do it in a coherent way. Revising rel 
values is analogous to changing relative links in the href's.

After all, the 'next', 'previous' 'contents' etc rel values also need 
care when migrating, so it's not just 'alternate' or 'friend'.

Re: Autodiscovery paces

[Eric Scheid]

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 
fits the first. So, +1 to PaceDifferentRelValue, -1 to PaceAnchorSupport.

e.

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

Re: Autodiscovery paces

[Eric Scheid]

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

[Eric Scheid]

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

[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

[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
...
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...
example of a broken feed
archives for June 2002
Tom's feed, very interesting
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:
...
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:
...
Linking to the news feed from another page (e.g. the Mozilla home):
...

--
Thomas Broyer

Re: Autodiscovery paces

[Graham]

On 10 May 2005, at 8:41 pm, Phil Ringnalda wrote:
... that it will be totally borked if Atom feeds with rel="alternate"
autodiscovery turn out to be in a namespace other than the Atom 0.3
one.
I just tried it, and it doesn't seem to care about the namespace.  
Anyone who gets lazy and uses "alternate" instead of "feed" for their  
Atom 1.0 feed would be borked anyway, so I don't really see this as a  
valid "pro" argument.

BTW Are we seriously considering using a different rel value to every  
other feed format in existence, including our own, for no discernible  
reason?

Graham

Re: Autodiscovery paces

[Robert Sayre]

On 5/10/05, Phil Ringnalda <[EMAIL PROTECTED]> wrote:
> 
> On 5/10/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
> >
> > The need is to not confuse users. Safari under tiger now does RSS
> > auto-discovery, which means
> 
> ... that it will be totally borked if Atom feeds with rel="alternate"
> autodiscovery turn out to be in a namespace other than the Atom 0.3
> one.

Safari's RSS/Atom parser is an XQuery script. When Atom is done, you
can bet they will roll out an updated script via Software Update.
They'll surely have other bugs to fix, anyway.I bet they will have it
done before we have an RFC number.

Robert Sayre

Re: Autodiscovery paces

[Phil Ringnalda]

On 5/10/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
> 
> The need is to not confuse users. Safari under tiger now does RSS
> auto-discovery, which means

... that it will be totally borked if Atom feeds with rel="alternate"
autodiscovery turn out to be in a namespace other than the Atom 0.3
one. It occurred to me after I changed Mark's "Such notification could
also be built directly into future versions of desktop web browsers."
to "Such notification is also built directly into some desktop web
browsers." that it's not a very good thing for Atom 1.0 that it is: I
don't know about Safari and Opera, but thanks to ultra-liberal
autodiscovery Firefox will be discovering Atom 1.0 feeds without
knowing how to handle them no matter what, unless we beat the Firefox
1.1 clock by just the right amount.

At least changing the @rel value will give more cautious
autodiscoverers a fighting chance at not discovering Atom 1.0 until
they know how to read it. During the changeover, rel="alternate feed"
would still be risky, but a careful publisher could call their
alternate feed only rel="feed" until they felt enough clients
understood 1.0 to risk confusing legacy 0.3 clients.

Phil Ringnalda

Re: Autodiscovery paces

[Eric Scheid]

On 11/5/05 3:17 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:

> Hmm. I can see the merit in your rationale. Does it meet a need?

The need is to not confuse users. Safari under tiger now does RSS
auto-discovery, which means there will be many totally-non-geek users who
might well get upset if the "Subscribe to RSS" function appears to be
borked. We're about to cross the chasm with RSS/Atom -- now would be a good
time to make sure the folks on the other side will have a pleasant
experience.

Safari is however having to make do using rough heuristics instead of
following a documented specification.

Right now, it suggests links to "application/atom+xml" resources as being
feeds, but sometime in the future that will be sub-optimal once/if folks
start publishing Atom Entry Documents.

I suspect it probably also suggests the following link as an RSS 1.0 feed:



even if it were on this page:

http://dannyayers.com/misc/about/biog.htm

which (I'm guessing) would more likely to lead to a FOAF document than an
RSS 1.0 document.

e.

Re: Autodiscovery paces

[Robert Sayre]

On 5/10/05, Eric Scheid <[EMAIL PROTECTED]> wrote:

> 
> Without @rel="feed", a browser with autodiscovery support might well suggest
> those links as being worthy of subscription. 

Hmm. I can see the merit in your rationale. Does it meet a need? Why
not deploy it and see what happens. There's nothing in the HTML spec
that says you can't make up a rel value, and you won't break anything
by trying it out.

Robert Sayre

Re: Autodiscovery paces

[Eric Scheid]

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
> 
> ...

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...

example of a broken feed
archives for June 2002
Tom's feed, very interesting

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

[Graham]

On 10 May 2005, at 3:38 am, Nikolas Coukouma wrote:
http://www.intertwingly.net/wiki/pie/PaceAnchorSupport
-1
I also don't want to implement it.
http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue
-1
I mainly don't see the point of changing it. 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.

Graham

Re: Autodiscovery paces

[Anne van Kesteren]

Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue
+1 if it is extended to support "alternate" as well when the feed 
really is the alternate version of the page. That would be a 
requirement for page authors. Feed readers don't have to check that
and can fetch every feed with either a "feed" or "alternate" REL 
attribute value.
I don't understand what the "feed" relation indicates. What benefit 
does it have over

...
?
That it can be used for *any* feed regardless its MIME type.
Another advantage is that I can say: 'Look, an Atom feed that is well-formed', without 
making feed readers discover it.

--
 Anne van Kesteren
 

Re: Autodiscovery paces

[Robert Sayre]

> > http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue
> 
> +1 if it is extended to support "alternate" as well when the feed really
> is the alternate version of the page. That would be a requirement for
> page authors. Feed readers don't have to check that and can fetch every
> feed with either a "feed" or "alternate" REL attribute value.

I don't understand what the "feed" relation indicates. What benefit
does it have over

...

?

Robert Sayre

Re: Autodiscovery paces

[Anne van Kesteren]

Nikolas Coukouma wrote:
http://www.intertwingly.net/wiki/pie/PaceAnchorSupport
+1 with the same remark as Mark Pilgrim.

http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue
+1 if it is extended to support "alternate" as well when the feed really 
is the alternate version of the page. That would be a requirement for 
page authors. Feed readers don't have to check that and can fetch every 
feed with either a "feed" or "alternate" REL attribute value.

--
 Anne van Kesteren
 

Re: Autodiscovery paces

[Mark Pilgrim]

On 5/9/05, Nikolas Coukouma <[EMAIL PROTECTED]> wrote:
> http://www.intertwingly.net/wiki/pie/PaceAnchorSupport

"Autodicovery elements MAY appear in either the  or the 
of the document."

I believe this is incorrect.  IIRC,  elements may only appear in
the , and  elements may only appear in the .

Other than that, +1 on PaceAnchorSupport.

> 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.

-- 
Cheers,
-Mark

Re: Autodiscovery

[Nikolas 'Atrus' Coukouma]

Roger B. wrote:

>>The problem is fortunately mitigated because user agents usually 
>>only offer copying @href ("copy link location").> I'm under the 
>>impression that they do something similar with rich-text copying.
>>
>>
>
>Nikolas: Your impression is mistaken. If I copy a chunk from Zeldman's
>XFN-friendly links page and paste it into my WYSIWYG editor, I get all
>of his @rel="whatevers" in my post. This is the same behavior I've
>noted in every IE- and Mozilla-based WYSIWYG editor I've tried.
>
>--
>Roger Benningfield
>  
>
Crud. To the bug databases I go.

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery in as well as

[Nikolas 'Atrus' Coukouma]

Roger B. wrote:

>>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?
>  
>
Everything except perhaps the C libraries. All the other implementations
I listed are written  purely in their respective scripting language and
should work if you just copy the source. Well, there's the possiblity
that some require an obscure lib somewhere, but the source I skimmed
indicated that they were based on basic string functions and/or regular
expressions. I should also note that I'm not sure how well each of them
stands up to crazy real world input because I've never tried using them
on arbitrary pages.

Hrm, I find, or make up, some test inputs ...

>>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
>
My condolences.

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery

[Roger B.]

> The problem is fortunately mitigated because user agents usually 
> only offer copying @href ("copy link location").> I'm under the 
> impression that they do something similar with rich-text copying.

Nikolas: Your impression is mistaken. If I copy a chunk from Zeldman's
XFN-friendly links page and paste it into my WYSIWYG editor, I get all
of his @rel="whatevers" in my post. This is the same behavior I've
noted in every IE- and Mozilla-based WYSIWYG editor I've tried.

--
Roger Benningfield

Re: Autodiscovery in as well as

[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 in as well as

[Nikolas 'Atrus' Coukouma]

Phil Ringnalda wrote:

>
> 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.

You're absolutely right. I was thing in more immediate terms before, but
if we're going to make this part of the Atom working group, land of
well-defined and reasonable specs, everything should work.

>
> 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 s in the
> first bit of the document feels a lot easier than having to look at
> every  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 , and quite common for
> them to comment out huge swaths of their , including things a
> template came with, like Atom
> feed, 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.

Is there something wrong with the HTML parsers?
Perl has HTML::Parser
Python has htmllib.py
Ruby has ymHTML and a port of of the Python library called html-parseer
PHP has PHP-HTML
Common Lisp has phtml
The W3C  provides a simple parser written in C

I'm sure I can find more, but I think the above is a sufficiently long
list to illustrate my point.

> 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.  is
> easy, we've got a DOMLinkAdded event and most pages have very few of
> them. ? Well, the performance hit probably won't be noticeable on
> most pages.

This is a single XPath query.  Gecko has native support for it. I'm not
sure about the others, but Sarissa is a fine library for DOM
manipulation (including XSLT and XPath) from Javascript and it works
with IE, KHTML, Opera ...

>
> Phil Ringnalda
>
Of course, if your XML library copes with all the errors present in
normal HTML, it's probably nicer to use than any HTML parser.

The point here is that most developers have access to an HTML parser. I
admit that they might need patching, but at least 90% of the work is done.

I'll try to find time to examine each of these libraries and make any
changes needed. Hopefully they're already in good shape or the author is
open to this sort thing. If all else fails, there's forking.

If the problem is ignorance, I'll happily maintain a list. I'm also
willing to write some sample implementations in all of the languages I
listed before and more.

I don't think this is terribly difficult. In fact, I just took a shot at
altering Feeds on Feeds to support this and found it incredibly easy.

patch: http://zaphod.student.umd.edu/~atrus/FoF_mod/a-support.patch
There's other stuff in the same directory there if you want to poke at
it. The changes just use PHP-HTML, which I mentioned earlier.

Cheers,
-Nikolas 'Atrus' Coukouma

Re: Autodiscovery in as well as

[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 s in the 
first bit of the document feels a lot easier than having to look at 
every  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 , and quite common for 
them to comment out huge swaths of their , including things a 
template came with, like Atom 
feed, 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.  is easy, 
we've got a DOMLinkAdded event and most pages have very few of them. 
? Well, the performance hit probably won't be noticeable on most pages.

Phil Ringnalda

Re: Autodiscovery

[Nikolas 'Atrus' Coukouma]

Bob Wyman wrote:

>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  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  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
>  
>
Since the HTML spec is where this originates, I'm inclined to say that
this is something that should be handled by whatever is manging content
(user or program) is copying the link. Clearly, @rel should be copied
with caution or simply left behind entirely.

I think calling this "components of a page establishing metadata for the
page as a whole" is a bit misleading. The metadata (@rel) say nothing
about the document it's in. It's metadata about the link between the two
documents. This metadata is context-Dependant because it depends on an
implicit @from counterpart to the explicit @href (@to, in XLink).

 and  both suffer from this weakness. I can't pick up a link
element from one element and move it to another. I can have a pile of
them in the template I use to make my pages.

It's considered a usability problem in the case of  because 
appears in a place where it's a it more likely to be copied: the body.
The problem is fortunately mitigated because user agents usually only
offer copying @href ("copy link location"). I'm under the impression
that they do something similar with rich-text copying. If someone's
copying HTML "source" by hand, then they should know to be wary of @rel.
The best we can do is add a note.

It's also not likely to bother programs that put content into
syndication feeds because links to feeds generally appear in the
periphery of presentation and not the main content of a feed. If people
do include @rel in content that's included in syndicated content, then
it should be stripped.

Again, no one uses @rel in  because it's unsupported. Coincidentally,
most programs do the right thing. If we push for @rel support in  in
the autodiscovery spec, then I think there may be an increase in usage,
at which time users can authors can educate themselves and programs can
make changes. They should have done this years ago. We're not creating
@rel, just encouraging it's use.

All of that said, it seems sensible to include a warning or a note or
somesuch.

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery discussion & editorship

[Paul Hoffman]

At 8:29 PM -0700 5/5/05, Tim Bray wrote:
Paul, is there any reason Mark or Phil shouldn't submit the most 
recent autodiscovery-01 as a committee draft?
No reason at all. We can poke at it, regardless of the -nn.txt numbering.
--Paul Hoffman, Director
--Internet Mail Consortium

RE: Autodiscovery

[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  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  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

[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 discussion & editorship

[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

[Nikolas Coukouma]

Sjoerd Visscher wrote:
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.

Completely separately, to the anchor versus link debate:
"space-separated list of link types."
is a find worthy of points (redeemable at your local ego shop).
This means we can have our pie and eat it too.
If we define rel="feed", there's no reason it can't be combined with 
other rel types :) For example, we could allow
http://www.example.com/xml/index.atom";>
http://www.example.com/xml/index.atom";>

Using @rel for type-ish hinting is an ugly hack, but this allows us to 
at least let @rel function the way it was intended to in addition to the 
hack.

It's that or choose another attribute to be our victim
-Nikolas 'Atrus' Coukouma

Re: Autodiscovery

[Nikolas 'Atrus' Coukouma]

Sjoerd Visscher wrote:

>
> fantasai wrote:
>
>>
>> The difference between  and  is that
>>   -  applies to the document as a whole: it indicates a
>> relationship
>> between this document and the href destination.
>>   -  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 s only. It is also perfectly reasonable to link
>> to feeds with , 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.

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

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery - different cases should use different rel

[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

[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.
>
>
>
>e.
>
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

[Sjoerd Visscher]

fantasai wrote:
The difference between  and  is that
  -  applies to the document as a whole: it indicates a relationship
between this document and the href destination.
  -  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 s only. It is also perfectly reasonable to link
to feeds with , 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

[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 - different cases should use different rel

[Nikolas 'Atrus' Coukouma]

Eric Scheid wrote:

>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.
>  
>
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.
They can bear to check the feed and see what the root element is.

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.

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.

-Nikolas 'Atrus' Coukouma

RE: Autodiscovery via body elements like a, div, span, etc.

[Bob Wyman]

Sjoerd Visscher wrote:
> Why not support hyperlinks too?
>  href="/xml/index.atom">Main Atom feed
One very interesting side-effect of putting the autodiscovery data
in elements of the body is that it then becomes visible in many more
environments. For instance, if I were to cut some text from a web page and
paste it into blog post or another web page, then if that text had links
with rel="alternate" in it, those links would travel along with the quote.
If I built a page of quotes from many sites, I might end up with "alternate"
links to many different sites, feeds, etc. This might not be as "bad" as it
sounds...
This might argue against using "alternate" in body elements that
might be cut out and pasted into or quoted in other pages since clearly, the
thing which is an alternate is an alternate of the page which originally
contained the quote -- not the page into which the quote has been pasted or
an alternate form of the quote itself.
While there are some problems to be worked on, I very much like the
idea of a chunk of HTML carrying around some indication of its provenance,
original source and alternate sources. 

bob wyman

Re: Autodiscovery - different cases should use different rel

[Nikolas 'Atrus' Coukouma]

fantasai wrote:

>
> Nikolas 'Atrus' Coukouma wrote:
>
>> fantasai wrote:
>>
>> An excellent point. Perhaps these should use rel="home" :)
>>
>> 
>
> ...
>
>>
>> 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

[A. Pagaltzis]

* fantasai <[EMAIL PROTECTED]> [2005-05-04 19:15]:
> 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"?

Itâs not. And itâs offtopic. Itâs called the âautodiscoveryâ
spec, not the âfeed directoryâ spec. If you want to link your
friendâs blogâs feed, supply an OPML or FOAF blogroll. Covering
this ground is not within the scope of autodiscovery.

Regards,
-- 
Aristotle

Re: Autodiscovery

[fantasai]

Sjoerd Visscher wrote:
Why not support hyperlinks too?
So besides:


also:
Main Atom feed

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  and  is that
  -  applies to the document as a whole: it indicates a relationship
between this document and the href destination.
  -  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 s only. It is also perfectly reasonable to link
to feeds with , 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]

Nikolas 'Atrus' Coukouma wrote:
fantasai wrote:
An excellent point. Perhaps these should use rel="home" :)

...
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 - different cases should use different rel

[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

[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, real-world examples

[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

[Nikolas 'Atrus' Coukouma]

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

[Nikolas 'Atrus' Coukouma]

Sjoerd Visscher wrote:

> Nikolas 'Atrus' Coukouma wrote:
>
>> Sjoerd Visscher wrote:
>>
>>> Why not support hyperlinks too?
>>>
>>> So besides:
>>>
>>> 
>>>
>>> also:
>>>
>>> >> href="/xml/index.atom">Main Atom feed
>>>
>>> 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 - different cases should use different rel

[Nikolas 'Atrus' Coukouma]

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" :)




>
> And for linking to other pages.. Here's a real-world example:
> The mozilla.org main page  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 

Re: Autodiscovery

[Sjoerd Visscher]

Nikolas 'Atrus' Coukouma wrote:
Sjoerd Visscher wrote:

Why not support hyperlinks too?
So besides:

also:
Main Atom feed
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, real-world examples

[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

[Nikolas 'Atrus' Coukouma]

Sjoerd Visscher wrote:

>
> Why not support hyperlinks too?
>
> So besides:
>
> 
>
> also:
>
>  href="/xml/index.atom">Main Atom feed
>
> 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

[Sjoerd Visscher]

Why not support hyperlinks too?
So besides:


also:
Main Atom feed

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, real-world examples

[Robert Sayre]

On 5/5/05, Antone Roundy <[EMAIL PROTECTED]> wrote:
> 
> On Thursday, May 5, 2005, at 01:27  AM, fantasai wrote:
> > 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 can see your point, but the autodiscovery spec isn't standardizing
all usages. Just the one we have a good grasp on. Secondly, there's
nothing stopping UAs from "discovering" other feeds. Safari 2.0
already does this.

Robert Sayre

Re: Autodiscovery, real-world examples

[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  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, real-world examples

[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  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

[Eric Scheid]

On 5/5/05 5:36 AM, "fantasai" <[EMAIL PROTECTED]> wrote:

>  - specify that UAs MAY also recognize the rel="alternate" and
>type="application/atom+xml" combination as an autodiscoverable Atom
>feed even if 'feed' is not among the rel values,

 and that UA should check that the representation returned when
 requesting that resource is an Atom Feed Document, and not an
 Atom Entry Document.

e.

Re: Autodiscovery and alternate

[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

[Nikolas 'Atrus' Coukouma]

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

[Eric Scheid]

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]

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

[Eric Scheid]

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

[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

[Nikolas 'Atrus' Coukouma]

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

[Nikolas 'Atrus' Coukouma]

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

[Nikolas 'Atrus' Coukouma]

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

[Nikolas 'Atrus' Coukouma]

fantasai wrote:

>
> Henri Sivonen wrote:
>
>>
>> On May 4, 2005, at 09:16, Mark Pilgrim wrote:
>>
>>> Then I'm confused as to why you can't just release running code that
>>> hard-codes rel="alternate".  You know, like people have already done.
>>
>>
>> Sure you can. ("Can" in the sense that it is possible.)
>>
>> However, when other things are equal, I think misusing an existing
>> relation (feed usually is not a proper alternate representation) is
>> worse than specifying a new one without all the profile fluff.
>>
>> Still, I am well aware that the other things are not equal in this
>> case (ie. there is deployed code), which is why I was not arguing in
>> favor of rel='feed' per se, but pointing out that the particular
>> reasoning against it did not hold water, IMO.
>
>
> It is the case that many, if not most, autodiscovery links *are* linking
> to valid alternates of the current page. Taking into account the wide
> use of the rel="alternate" type="application/atom+xml" combination, the
> spec could be written to
>
>   - specify that any link with rel="feed" and type="application/atom+xml"
> indicates an autodiscoverable Atom feed
>   - specify that UAs MAY also recognize the rel="alternate" and
> type="application/atom+xml" combination as an autodiscoverable Atom
> feed even if 'feed' is not among the rel values,
>   - but specify that authors SHOULD NOT  (or MUST NOT) leave out the
> 'feed' value
>   - recommend that links that do indicate a feed version of the current
> HTML page SHOULD link to that feed with both link types
>
> Blogging software is a fast-moving industry. If the draft editor makes
> this change and notifies the community, I suspect it will not be long
> before most software supports both syntaxes.
>
> ~fantasai

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.

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.

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.

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery

[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

[Graham]

On 4 May 2005, at 7:02 pm, Robert Sayre wrote:
settle on one arbitrary choice
+1
Graham

Re: Autodiscovery

[fantasai]

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

[fantasai]

Henri Sivonen wrote:
On May 4, 2005, at 09:16, Mark Pilgrim wrote:
Then I'm confused as to why you can't just release running code that
hard-codes rel="alternate".  You know, like people have already done.
Sure you can. ("Can" in the sense that it is possible.)
However, when other things are equal, I think misusing an existing 
relation (feed usually is not a proper alternate representation) is 
worse than specifying a new one without all the profile fluff.

Still, I am well aware that the other things are not equal in this case 
(ie. there is deployed code), which is why I was not arguing in favor of 
rel='feed' per se, but pointing out that the particular reasoning 
against it did not hold water, IMO.
It is the case that many, if not most, autodiscovery links *are* linking
to valid alternates of the current page. Taking into account the wide
use of the rel="alternate" type="application/atom+xml" combination, the
spec could be written to
  - specify that any link with rel="feed" and type="application/atom+xml"
indicates an autodiscoverable Atom feed
  - specify that UAs MAY also recognize the rel="alternate" and
type="application/atom+xml" combination as an autodiscoverable Atom
feed even if 'feed' is not among the rel values,
  - but specify that authors SHOULD NOT  (or MUST NOT) leave out the
'feed' value
  - recommend that links that do indicate a feed version of the current
HTML page SHOULD link to that feed with both link types
Blogging software is a fast-moving industry. If the draft editor makes
this change and notifies the community, I suspect it will not be long
before most software supports both syntaxes.
~fantasai

Re: Autodiscovery

[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

[fantasai]

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:
  
  
Or even
  
  
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

[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]

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.

Re: Autodiscovery

[fantasai]

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
   
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

[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

[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

[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):

In a "category" page:






In a "single-entry archive" page:





However, is this enough for the autodiscovery purpose?
--
Thomas Broyer

Re: Autodiscovery

[Robert Sayre]

On 5/4/05, Eric Scheid <[EMAIL PROTECTED]> 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 don't know. Time is a funny thing. 

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. I
tried to rewrite it once, only to later realize what gross errors I'd
made as I tried to clarify or add features to it. I can assure you
that everything is there for a real-world reason. I suggested a few
changes to section 6, which seems like overspecification to me, but
that's the only thing I suggest we touch.

Robert Sayre

Re: Autodiscovery

[Eric Scheid]

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

[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  element in
> an Atom document, but the semantics of the  element in an HTML
> document.

Yes, I caught that.

Robert Sayre

Re: Autodiscovery

[fantasai]

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  element in
an Atom document, but the semantics of the  element in an HTML
document.
~fantasai

Re: Autodiscovery

[fantasai]

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

[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

[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

[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:
  
  
Or even
  
  
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

[Henri Sivonen]

On May 4, 2005, at 10:43, Eric Scheid wrote:
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
We all call them feeds and in the end it comes down to picking a string 
that software uses for comparison. Why all the over-generalization?

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

Re: Autodiscovery

[Henri Sivonen]

On May 4, 2005, at 09:16, Mark Pilgrim wrote:
On 5/4/05, Henri Sivonen <[EMAIL PROTECTED]> wrote
No you don't. rel='license' and rel='nofollow' have been deployable
without a profile. You just release running code that hard-codes
rel='feed' and, boom, no profile needed.
Then I'm confused as to why you can't just release running code that
hard-codes rel="alternate".  You know, like people have already done.
Sure you can. ("Can" in the sense that it is possible.)
However, when other things are equal, I think misusing an existing 
relation (feed usually is not a proper alternate representation) is 
worse than specifying a new one without all the profile fluff.

Still, I am well aware that the other things are not equal in this case 
(ie. there is deployed code), which is why I was not arguing in favor 
of rel='feed' per se, but pointing out that the particular reasoning 
against it  did not hold water, IMO.

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

Re: Autodiscovery

[Dan Brickley]

* Henri Sivonen <[EMAIL PROTECTED]> [2005-05-04 09:04+0300]
> 
> 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.

What's a feed? 1/2 ;)

FWIW in the FOAF spec we currently say:

http://example.com/people/~you/foaf.rdf"; /> 
(although we shouldn't really be taking over the title attribute...)

(we don't really say what a FOAF file is either; pointing to an RSS1 doc
that had some use of the FOAF namespace in it too could be reasonable...).

Dan

Re: Autodiscovery

[Arve Bersvendsen]

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.

--
Arve Bersvendsen