subject:"Autodiscovery"


PaceAnchorSupport and PaceDifferentRelValue don't seem very useful,
and they weren't proposed by implementors. The spec is extremely
well-written and reflects existing behavior.

Can we please un-expire this:
http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

and be done?

--

Robert Sayre

I would have written a shorter letter, but I did not have the time.

Re: finishing autodiscovery, like now


* Robert Sayre [EMAIL PROTECTED] [2006-01-19 18:25]:
PaceAnchorSupport and PaceDifferentRelValue don't seem very
useful, and they weren't proposed by implementors. The spec is
extremely well-written and reflects existing behavior.

They’re trying to do something useful, but in the wrong way. Both
seem to stem from a desire to be able to link feeds other than
those which are an alternate of the page in question.

But we already have a name for doing that: it’s called “linking
to something.” Now, it’d be useful to encourage people to add
`type` attributes to their `a` links, so tools could find them
just by looking at the page without spidering. But `rel` does not
add any information. The page is simply linking to another
resource. So +1 to encouraging `type`, -1 on fiddling with `rel`
at all (let alone going around changing values).

In fact, semantically, we should be encouraging people to move
things out of their `link`s and into `a`s in the page. After
all, the infrastructure for doing something useful with feeds
when a user clicks on a link in the page already exists: MIME
types and and `atom:[EMAIL PROTECTED]'self']`. This infrastructure is
not well supported; true. But new autodiscovery syntax is not
going to become well supported any quicker.

Can we please un-expire this:
http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html
and be done?

+1

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: finishing autodiscovery, like now


On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:

 But we already have a name for doing that: it¹s called ³linking
 to something.² Now, it¹d be useful to encourage people to add
 `type` attributes to their `a` links, so tools could find them
 just by looking at the page without spidering. But `rel` does not
 add any information.

Here is a link to a resource:

link type=application/atom+xml href=... /

Please explain how a tool can decide whether that is a link to a atom:feed
document, or is a link to an atom:entry document?
 
 In fact, semantically, we should be encouraging people to move
 things out of their `link`s and into `a`s in the page.

Sounds like PaceAnchorSupport. How do you propose we do this encouragement,
if not by codifying it into a spec?

On 20/1/06 4:05 AM, Robert Sayre [EMAIL PROTECTED] wrote:
 The spec is extremely well-written and reflects existing behavior.

The existing behaviour is based on the various incarnations of RSS where the
only document type involved are feeds. RFC 4287 introduces a new document
type, the Atom Entry Document, which autodiscovery-01 fails to take into
consideration. That doesn't meet my definition of well-written.

e.

Re: finishing autodiscovery, like now

2006-01-19 Thread Anne van Kesteren



Quoting Eric Scheid [EMAIL PROTECTED]:

On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:

But we already have a name for doing that: it¹s called ³linking
to something.² Now, it¹d be useful to encourage people to add
`type` attributes to their `a` links, so tools could find them
just by looking at the page without spidering. But `rel` does not
add any information.


Here is a link to a resource:

   link type=application/atom+xml href=... /

Please explain how a tool can decide whether that is a link to a atom:feed
document, or is a link to an atom:entry document?


Why is that relevant?


--
Anne van Kesteren
http://annevankesteren.nl/

Re: finishing autodiscovery, like now


On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:

 The existing behaviour is based on the various incarnations of RSS where the
 only document type involved are feeds. RFC 4287 introduces a new document
 type, the Atom Entry Document, which autodiscovery-01 fails to take into
 consideration. That doesn't meet my definition of well-written.

Well, if anyone actually did that, it might be a problem. But, then
again, it might not be. You've had years to propose your definition of
well-written. I think the current draft reflects what
implementations do pretty well. We haven't been able to come to
consensus on additional features, so I suggest we're done.

--

Robert Sayre

I would have written a shorter letter, but I did not have the time.

Re: finishing autodiscovery, like now




Eric Scheid wrote:

On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:


But we already have a name for doing that: it¹s called ³linking
to something.² Now, it¹d be useful to encourage people to add
`type` attributes to their `a` links, so tools could find them
just by looking at the page without spidering. But `rel` does not
add any information.


Here is a link to a resource:

link type=application/atom+xml href=... /

Please explain how a tool can decide whether that is a link to a atom:feed
document, or is a link to an atom:entry document?
 


This is a general limitation of the media type definition, not with the 
autodiscovery draft.  We have the same problem differentiating 
atom:link type=application/atom+xml href=... /.  This isn't a 
problem that the autodiscovery draft needs to solve.  If it's a problem, 
solve it in the Atom format spec where the media type is defined.



On 20/1/06 4:05 AM, Robert Sayre [EMAIL PROTECTED] wrote:

The spec is extremely well-written and reflects existing behavior.


The existing behaviour is based on the various incarnations of RSS where the
only document type involved are feeds. RFC 4287 introduces a new document
type, the Atom Entry Document, which autodiscovery-01 fails to take into
consideration. That doesn't meet my definition of well-written.


I really don't believe this is going to be much of a problem in practice.

- James

Re: finishing autodiscovery, like now


Hi Eric,

* Eric Scheid [EMAIL PROTECTED] [2006-01-19 21:10]:
Here is a link to a resource:

link type=application/atom+xml href=... /

Please explain how a tool can decide whether that is a link to a
atom:feed document, or is a link to an atom:entry document?

this is an excellent point. How does either Pace address it?

 In fact, semantically, we should be encouraging people to move
 things out of their `link`s and into `a`s in the page.

Sounds like PaceAnchorSupport. How do you propose we do this
encouragement, if not by codifying it into a spec?

PaceAnchorSupport merely promotes `a` to parity with `link`,
for which the I-D says a `rel` attribute consisting of at least
`alternate` is required.

But I don’t see how “this is a feed I want to link to” implies a
different relationship with the linking page than “this is some
resource I want to link to.” The mere fact that the linked
resource is a feed (or entry document) does not constitute a
relationship with the linking page in and of itself; and that
makes `rel` the wrong place to shoehorn this information into.

So no, encouraging people to add advisory `type` information to
their links is not equivalent to PaceAnchorSupport.

In any case, the important part is that when someone clicks the
link in a browser, the right things happen. For that, the `type`
is not even necessary, so long as the feed is served with the
correct MIME type and contains a self-link. The type makes some
harvesting easier, but ultimately, it’s not *necessary*.

We’re trying to shoehorn this functionality in with autodiscovery
right now because as of yet, the right things do not happen, even
though they *could*, whereas something closer to the right things
does happen when autodiscovery links are added willy-nilly.

The existing behaviour is based on the various incarnations of
RSS where the only document type involved are feeds. RFC 4287
introduces a new document type, the Atom Entry Document, which
autodiscovery-01 fails to take into consideration. That doesn't
meet my definition of well-written.

I don’t know how that is relevant. I am trying to think of a
scenario where I’d want to autodiscover an entry document (as
opposed to simply linking to it) and the inability to distinguish
between feed and entry documents is causing a problem, but I
can’t come up with anything. Can you provide an example?

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: finishing autodiscovery, like now


On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
 The existing behaviour is based on the various incarnations of RSS where the
 only document type involved are feeds. RFC 4287 introduces a new document
 type, the Atom Entry Document, which autodiscovery-01 fails to take into
 consideration. That doesn't meet my definition of well-written.


The purpose of Atom autodiscovery is for clients who know the URI of a
web page to find the location of that page's associated Atom feed.


Not an entry but a feed. The autodiscovery is unambiguous on what such
a link points to. Now to match RFC 4287 that 'feed' ought to
be 'Feed', but that is a rather minor change.

   -joe

--
Joe Gregoriohttp://bitworking.org

Re: finishing autodiscovery, like now

2006-01-19 Thread Phil Ringnalda


On 1/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
 The existing behaviour is based on the various incarnations of
 RSS where the only document type involved are feeds. RFC 4287
 introduces a new document type, the Atom Entry Document, which
 autodiscovery-01 fails to take into consideration. That doesn't
 meet my definition of well-written.

 I don't know how that is relevant. I am trying to think of a
 scenario where I'd want to autodiscover an entry document (as
 opposed to simply linking to it) and the inability to distinguish
 between feed and entry documents is causing a problem, but I
 can't come up with anything. Can you provide an example?

I have a weblog post. I would like aggregators to discover both the
feed for comments (rel=alternate feed) and the feed for my weblog
(rel=feed), but I would like search engines and hypothetical
Atom-aware browsers and Piggybank-style history miners to discover the
Atom Entry document, where they can find just the entry for one-time
fetching with no question about what they are getting
(rel=alternate).

Of course, if we spec only things which include feed in the rel
value as being appropriate for aggregators, and all others as not, we
still would need to wait three or four years for existing use of
alternate alone to die down before any aggregator developer would
consider following along and ignoring non-feeds.

Phil Ringnalda

Re: finishing autodiscovery, like now


On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote:

 Of course, if we spec only things which include feed in the rel
 value as being appropriate for aggregators, and all others as not, we
 still would need to wait three or four years for existing use of
 alternate alone to die down before any aggregator developer would
 consider following along and ignoring non-feeds.

First person to need the feature has to spec alternate entry instead
of making everyone change to alternate feed. Not it!

--

Robert Sayre

I would have written a shorter letter, but I did not have the time.

Re: finishing autodiscovery, like now



Why wouldn't this work?

rel=alternate feed
rel=alternate entry
rel=alternate replies  (see [1])

[1]http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-03.txt

Phil Ringnalda wrote:

On 1/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote:

The existing behaviour is based on the various incarnations of
RSS where the only document type involved are feeds. RFC 4287
introduces a new document type, the Atom Entry Document, which
autodiscovery-01 fails to take into consideration. That doesn't
meet my definition of well-written.

I don't know how that is relevant. I am trying to think of a
scenario where I'd want to autodiscover an entry document (as
opposed to simply linking to it) and the inability to distinguish
between feed and entry documents is causing a problem, but I
can't come up with anything. Can you provide an example?


I have a weblog post. I would like aggregators to discover both the
feed for comments (rel=alternate feed) and the feed for my weblog
(rel=feed), but I would like search engines and hypothetical
Atom-aware browsers and Piggybank-style history miners to discover the
Atom Entry document, where they can find just the entry for one-time
fetching with no question about what they are getting
(rel=alternate).

Of course, if we spec only things which include feed in the rel
value as being appropriate for aggregators, and all others as not, we
still would need to wait three or four years for existing use of
alternate alone to die down before any aggregator developer would
consider following along and ignoring non-feeds.

Phil Ringnalda

Re: finishing autodiscovery, like now


On 20/1/06 7:52 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:

 Here is a link to a resource:
 
link type=application/atom+xml href=... /
 
 Please explain how a tool can decide whether that is a link to a
 atom:feed document, or is a link to an atom:entry document?
 
 this is an excellent point. How does either Pace address it?

PaceDifferentRelValue addresses this. It suggests using feed as an @rel
value to indicate the referenced resource is a feed (ie. is not an entry
doc) which can be subscribed to. It doesn't rule out continuing to use
alternate for those cases where the feed is actually an alternate to the
current document.

 I am trying to think of a scenario where I¹d want to autodiscover an entry
 document (as opposed to simply linking to it) and the inability to distinguish
 between feed and entry documents is causing a problem, but I can¹t come up
 with anything. Can you provide an example?

I'm not talking about autodiscovery of entry documents. I'm talking about
autodiscovery of feeds, which (and this is the point) is *different* from
autodiscovery of resources with the mime type of application/atom+xml.

Apart from Atom Entry Documents, there are also application/ref+xml
documents ... and not all of those are RSS 1.0 feeds.

Using feed solves the problem for both cases (atom entry and rdf+xml), and
potentially any similar problems (eg newsml+xml?).

e.

Re: finishing autodiscovery, like now


On 20/1/06 7:57 AM, James M Snell [EMAIL PROTECTED] wrote:

 Here is a link to a resource:
 
 link type=application/atom+xml href=... /
 
 Please explain how a tool can decide whether that is a link to a atom:feed
 document, or is a link to an atom:entry document?
  
 
 This is a general limitation of the media type definition, not with the
 autodiscovery draft.  We have the same problem differentiating
 atom:link type=application/atom+xml href=... /.  This isn't a
 problem that the autodiscovery draft needs to solve.  If it's a problem,
 solve it in the Atom format spec where the media type is defined.

Too late. It would have been nice to have application/atomentry+xml

Also, fixing it in the atom format spec doesn't fix the exact same problem
autodiscovery has with application/rdf+xml.

e.

Re: finishing autodiscovery, like now


On 1/19/06, James M Snell [EMAIL PROTECTED] wrote:

 Why wouldn't this work?

 rel=alternate feed
 rel=alternate entry
 rel=alternate replies  (see [1])

Because rel is a space separated list of link types:

  http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel

I.e. the values are all orthogonal.

   -joe

--
Joe Gregoriohttp://bitworking.org

Re: finishing autodiscovery, like now


On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:

 PaceDifferentRelValue addresses this. It suggests using feed as an @rel
 value to indicate the referenced resource is a feed (ie. is not an entry
 doc) which can be subscribed to.

The spec already does this without a new rel value.

 It doesn't rule out continuing to use
 alternate for those cases where the feed is actually an alternate to the
 current document.

I am lie-down-in-the-road opposed to PaceDifferentRelValue.
Interesting idea. I suggest someone write a DifferentSpec.

--

Robert Sayre

I would have written a shorter letter, but I did not have the time.

Re: finishing autodiscovery, like now


* Phil Ringnalda [EMAIL PROTECTED] [2006-01-19 22:30]:
 I am trying to think of a scenario where I'd want to
 autodiscover an entry document (as opposed to simply linking
 to it) and the inability to distinguish between feed and entry
 documents is causing a problem, but I can't come up with
 anything. Can you provide an example?

I have a weblog post. I would like aggregators to discover both
the feed for comments (rel=alternate feed) and the feed for my
weblog (rel=feed),

Is `feed` a relationship of the page with the feed? Is there a
reason `a type=application/atom+xml` wouldn’t suffice?

but I would like search engines and hypothetical Atom-aware
browsers and Piggybank-style history miners to discover the Atom
Entry document, where they can find just the entry for one-time
fetching with no question about what they are getting
(rel=alternate).

Okay, so you have two alternates: one with comments, one without.
That would be `rel=alternate` in both cases, with
`title=Entry` in one of them and `title=Entry with comments`
in the other.

This is semantically weak, I know.

But I don’t see how it can be strengthened. It merely appears to
be expressible more precisely because we’re sticking to the
weblog use case.

What about feeds for a page on a wiki? Say you have one entry
document which contains the latest version of the page at the
time of retrieval, one feed which lists the history of major
edits, one which lists major+minor edits, and let’s say it’s one
of those newfangled wikis where you can leave comments on a page
separately from the page content, so you have a feed for that as
well. How do you tell those apart?

Then someone comes around and does this on his site:
http://www-128.ibm.com/developerworks/webservices/library/ws-atomwas/

And then someone else does something else.

And someone else still uses Atom in yet another clever way.

It’s just impossible to specify enough precise semantics to cover
everyone’s use cases, and no single app will ever understand all
of these disparate semantics. The problem seems simple while you
look at it with blog-coloured glasses because that is such a
small and well-understood niche of the problem space.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: finishing autodiscovery, like now


* Eric Scheid [EMAIL PROTECTED] [2006-01-19 23:10]:
PaceDifferentRelValue addresses this. It suggests using feed
as an @rel value to indicate the referenced resource is a feed
(ie. is not an entry doc) which can be subscribed to. It doesn't
rule out continuing to use alternate for those cases where the
feed is actually an alternate to the current document.

Quibbling about the assumption that noone would ever want to
subscribe to an entry document aside, I guess I can see the
point. But `rel` is not the place for that. I don’t think we *do*
have a place for it.

What you really want is to express that the linked resource
adheres to a certain profile. (Hm, what happened to James Snell’s
profile extension?)

People could be as precise as they care to be, and bots and user
agents could support whichever profiles they cared to. You avoid
requiring full buy-in from everyone in order to make something
useful even though it’s as vague as “feed.”

Of course, this requires a mythical hook in HTML to hang the
profile information off of…

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: finishing autodiscovery, like now




A. Pagaltzis wrote:

(Hm, what happened to James Snell’s profile extension?)


In progress. I decided to hold off in favor of a few other higher 
priority items.  Expect a draft on this either later this month or next.


- James

Re: finishing autodiscovery, like now


On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:

 
 The purpose of Atom autodiscovery is for clients who know the URI of a
 web page to find the location of that page's associated Atom feed.
 
 
 Not an entry but a feed. The autodiscovery is unambiguous on what such
 a link points to.

Unambiguous? The autodiscovery spec does not outlaw using
[EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry
documents. It only says that such links may be used to find Atom Feed
Documents. This is a subtle nuance.

e.

Re: finishing autodiscovery, like now


On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:

 Okay, so you have two alternates: one with comments, one without.
 That would be `rel=alternate` in both cases, with
 `title=Entry` in one of them and `title=Entry with comments`
 in the other.
 
 This is semantically weak, I know.

@rel contains tokens, @title contains human language content.

Would @title=Entrada com comentários also be acceptable? How about
@title=Entrata con le osservazioni or @title=Entrée avec des
commentaires or @title=Entrada con comentarios or @title=Eintragung mit
Anmerkungen? No. This is no basis for auto-whatever.

No matter what the @lang might be, the @rel would still contain the same
token for each of those possible @title links. It's just English Language
Imperialism why it happens to be alternate entry, it could just as easily
be specced to be FooBarBaz or 3576.24352.987.

e.

Re: finishing autodiscovery, like now


On 20/1/06 10:10 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:

 And someone else still uses Atom in yet another clever way.

Which is precisely why [EMAIL PROTECTED]alternate,@type=atom+xml] is an
*ambiguous* way of discovering atom Feeds ...

 It¹s just impossible to specify enough precise semantics to cover
 everyone¹s use cases, and no single app will ever understand all
 of these disparate semantics.

Strawman. I'm not suggesting we pre-define all these other cases. I'm
suggesting we define this one case (here is a feed document related to this
page) in a manner which distinguishes it from other [undefined] cases.

 The problem seems simple while you
 look at it with blog-coloured glasses because that is such a
 small and well-understood niche of the problem space.

Be careful what you assume. I'm thinking of using atom entry documents for
many non-blog related purposes, and this is what is driving my interest in
disambiguating feed autodiscovery.

e.

Re: finishing autodiscovery, like now


On 20/1/06 8:52 AM, Joe Gregorio [EMAIL PROTECTED] wrote:

 Why wouldn't this work?
 
 rel=alternate feed
 rel=alternate entry
 rel=alternate replies  (see [1])
 
 Because rel is a space separated list of link types:
 
 http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
 
 I.e. the values are all orthogonal.

Yes, but that would mean that it *would* work, not that it *wouldn't*. Being
orthogonal means that those three links are equivalent to these six links

 rel=alternate href=1
 rel=alternate href=2
 rel=alternate href=3
 rel=feed  href=1
 rel=entry href=2
 rel=replies   href=3

Which is exactly what was intended.


e.

Re: finishing autodiscovery, like now

2006-01-19 Thread Phil Ringnalda


On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote:
 Because rel is a space separated list of link types:

   http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
 https://mail.google.com/mail/
 I.e. the values are all orthogonal.

Though at this point in this discussion, someone is always duty-bound
to point out that the only use of link that HTML actually specifies,
for stylesheets, treats them as not orthogonal (alternate stylesheet
is not alternate and a stylesheet, it's an
alternate-stylesheet), and further assigns meaning to the presence
(though not, exactly, the content) of a title attribute.

Phil Ringnalda

Re: finishing autodiscovery, like now


On 20/1/06 8:31 AM, Robert Sayre [EMAIL PROTECTED] wrote:

 First person to need the feature has to spec alternate entry instead
 of making everyone change to alternate feed.

How is speccing alternate entry helpful?

That would *still* be considered an autodiscovery link to a feed,
according the current autodiscovery spec. That's the problem right there.

The spec should allow for the creation of other specs without land-grabbing
the non-specific alternate @rel value.

e.

Re: finishing autodiscovery, like now


On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
 That would *still* be considered an autodiscovery link to a feed,
 according the current autodiscovery spec. That's the problem right there.

It's not a problem. It works now, and no one is going to run out and
change the running code. If someone did do alternate entry, I can
see implementations getting patches to ignore those. In fact, you
don't even need a spec to help. Just start doing it. If it becomes
common, there will be patches.

--

Robert Sayre

I would have written a shorter letter, but I did not have the time.

Re: finishing autodiscovery, like now



Eric Scheid wrote:

Yes, but that would mean that it *would* work, not that it *wouldn't*. Being
orthogonal means that those three links are equivalent to these six links


rel=alternate href=1
rel=alternate href=2
rel=alternate href=3
rel=feed  href=1
rel=entry href=2
rel=replies   href=3


Which is exactly what was intended.



Yep. Specifying them as separate tokens provides backwards compatibility 
(with clients that are actually implemented properly) and better 
semantics.  Folks that rely just on the alternate mechanism won't be 
any worse off than they are currently.  Folks that want the clearer and 
specific semantics would look for feed, entry, replies


- James

Re: finishing autodiscovery, like now


On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:

 On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:

  
  The purpose of Atom autodiscovery is for clients who know the URI of a
  web page to find the location of that page's associated Atom feed.
  
 
  Not an entry but a feed. The autodiscovery is unambiguous on what such
  a link points to.

 Unambiguous? The autodiscovery spec does not outlaw using
 [EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom entry
 documents. It only says that such links may be used to find Atom Feed
 Documents. This is a subtle nuance.

That is not a subtle nuance but an incorrect interpretation. By that
same logic it does not outlaw using
[EMAIL PROTECTED]/atom+xml,@rel=alternate] to point to
an RSS feed, or a PNG.

The autodiscovery spec would be the only RFC that defines
the behaviour of [EMAIL PROTECTED]/atom+xml,@rel=alternate],
and the verbage in the autodiscovery spec is unambiguous
about that fact that it is talking about feeds and not entries.

   -joe

--
Joe Gregoriohttp://bitworking.org

Re: finishing autodiscovery, like now


On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote:

 On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote:
  Because rel is a space separated list of link types:
 
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
  https://mail.google.com/mail/
  I.e. the values are all orthogonal.

 Though at this point in this discussion, someone is always duty-bound
 to point out that the only use of link that HTML actually specifies,
 for stylesheets, treats them as not orthogonal (alternate stylesheet
 is not alternate and a stylesheet, it's an
 alternate-stylesheet), and further assigns meaning to the presence
 (though not, exactly, the content) of a title attribute.

Marvelous.

Are you suggesting we promulgate that behaviour in
the face of autodiscovery for RSS that already uses
alternate?

-joe

--
Joe Gregoriohttp://bitworking.org

Re: finishing autodiscovery, like now


On 20/1/06 12:32 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
 On 1/19/06, Phil Ringnalda [EMAIL PROTECTED] wrote:

 Though at this point in this discussion, someone is always duty-bound
 to point out that the only use of link that HTML actually specifies,
 for stylesheets, treats them as not orthogonal (alternate stylesheet
 is not alternate and a stylesheet, it's an
 alternate-stylesheet), and further assigns meaning to the presence
 (though not, exactly, the content) of a title attribute.
 
 Marvelous.

Yeah, awful.

 Are you suggesting we promulgate that behaviour in
 the face of autodiscovery for RSS that already uses
 alternate?

Speaking for myself, quite the opposite.

Robert Sayre is the only one so far suggesting that @rel=alternate entry
should be treated as excluding the semantic of @rel=alternate. Which is
surprising: I would have bet he would consider the alternate stylesheet
thing an abomination.

I'm suggesting that if we want to link to a resource which is considered to
be a feed for the current document we use feed. If we want to link to a
resource which is considered to be an alternate representation of the
current document we use alternate. If the resource is considered to be
both, then the x/html spec allows both relationships to be expressed in the
one link as a space separated list.

Specifying feed does not rule out using alternate feed for backwards
incompatibility purposes, except to those implementations that can't cope
with more than one value in @rel, and according to the autodisco 1.0 spec
they are broken anyways so I have no compassion for them.

e.

Re: finishing autodiscovery, like now

2006-01-19 Thread John Panzer




Joe Gregorio wrote on 1/19/2006, 5:29 PM:

 
  On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
  
   On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
  

The purpose of Atom autodiscovery is for clients who know the URI
  of a
web page to find the location of that page's associated Atom feed.

   
Not an entry but a feed. The autodiscovery is unambiguous on what
  such
a link points to.
  
   Unambiguous? The autodiscovery spec does not outlaw using
   [EMAIL PROTECTED]/atom+xml,@rel=alternate] for linking to atom
  entry
   documents. It only says that such links may be used to find Atom Feed
   Documents. This is a subtle nuance.
 
  That is not a subtle nuance but an incorrect interpretation. By that
  same logic it does not outlaw using
  [EMAIL PROTECTED]/atom+xml,@rel=alternate] to point to
  an RSS feed, or a PNG.
 
  The autodiscovery spec would be the only RFC that defines
  the behaviour of [EMAIL PROTECTED]/atom+xml,@rel=alternate],
  and the verbage in the autodiscovery spec is unambiguous
  about that fact that it is talking about feeds and not entries.
 

What autodiscovery links should I do on a web page that displays a 
single blog entry, like this one?

http://journals.aol.com/panzerjohn/abstractioneer/entries/1238

It's not unreasonable to link to the overall feed for the entire blog 
from this page, but it's a bit unreasonable to say that the feed is an 
'alternate' for the current page -- it's a superset of the current page, 
at best.  It's also not unreasonable to want to have a way to find an 
individual Atom entry associated with this page.  This would intuitively 
seem to be a reasonable 'alternate' since it contains the same 
information in a different format.

-- 
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer

Re: finishing autodiscovery, like now


On 1/19/06, John Panzer [EMAIL PROTECTED] wrote:

 What autodiscovery links should I do on a web page that displays a
 single blog entry, like this one?

 http://journals.aol.com/panzerjohn/abstractioneer/entries/1238

Actually on my blog each page has a feed associated with
it that is a feed of all the comments on that page.

Regardless, the current spec is unambiguous, it points to
feeds. If we want it to point to something besides a feed
it has to be changed.

If we were to change something, one way to disambiguate feeds
from entries would be to add a parameter to the mime-type:

  application/atom+xml; doc=entry

   -joe

--
Joe Gregoriohttp://bitworking.org

invention (was: finishing autodiscovery, like now)


On 1/19/06, John Panzer [EMAIL PROTECTED] wrote:

 It's not unreasonable to link to the overall feed for the entire blog
 from this page, but it's a bit unreasonable to say that the feed is an
 'alternate' for the current page -- it's a superset of the current page,
 at best.  It's also not unreasonable to want to have a way to find an
 individual Atom entry associated with this page.  This would intuitively
 seem to be a reasonable 'alternate' since it contains the same
 information in a different format.

I agree with you. But I don't want to change the document. There are
lots of other strings we could use to describe new capabilities, and
the advantages of continually re-using the string alternate are
pretty slim... are there any?

An alternate link with a feedish media type means associated feed,
and all of the running code on the planet agrees with me. We can
either innovate in the WG, or finish in a month or so. I know I prefer
the latter. HTML link relations don't require a standards group to add
new ones, so people who want to do something can publish them, and
they can go code it. There are lots of open source browsers.

But, I could be in the minority. Which WG members think we should work
on exciting new HTML link relations?

--

Robert Sayre

I would have written a shorter letter, but I did not have the time.

Re: finishing autodiscovery, like now


On 20/1/06 1:55 PM, Joe Gregorio [EMAIL PROTECTED] wrote:

 What autodiscovery links should I do on a web page that displays a
 single blog entry, like this one?
 
 http://journals.aol.com/panzerjohn/abstractioneer/entries/1238
 
 Actually on my blog each page has a feed associated with
 it that is a feed of all the comments on that page.

Are the comments on the same html page, or on another page? Some websites do
it the latter way. It often depends on the size of the article, especially
if the article is split into multiple pages (eg.
http://www.xml.com/pub/a/2005/12/07/catching-up-with-the-atom-publishing-pr
otocol.html ).

In the first use case, it would make sense to have @rel=alternate feed
replies (it's an alternate representation of the page, it's a feed of
updates of this page, and it's a resource containing replies to this page).

In the latter case however @rel=alternate feed replies would be broken.
The replies are not on that page, so how is a feed of replies an alternative
representation? It would make sense to have @rel=related feed replies
though.

 Regardless, the current spec is unambiguous, it points to
 feeds. If we want it to point to something besides a feed
 it has to be changed.

No, it does *not* point to feeds, it points to resources of a certain mime
type of which a subset are feeds. There's the ambiguity.

e.

RE: Autodiscovery

2005-05-16 Thread 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 paces

2005-05-10 Thread 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 head or the body
of the document.

I believe this is incorrect.  IIRC, link elements may only appear in
the head, and a elements may only appear in the body.

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 paces

2005-05-10 Thread 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
 http://annevankesteren.nl/

Re: Autodiscovery paces

2005-05-10 Thread 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

a href=... type=application/atom+xml.../a
?
That it can be used for *any* feed regardless its MIME type.
Another advantage is that I can say: 'Look, an a href=link 
type=application/atom+xmlAtom feed/a that is well-formed', without 
making feed readers discover it.

--
 Anne van Kesteren
 http://annevankesteren.nl/

Re: Autodiscovery paces

2005-05-10 Thread 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


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

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

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

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

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

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

e.

Re: I-D ACTION:draft-ietf-atompub-autodiscovery-01.txt

2005-05-10 Thread Phil Ringnalda


On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 A URL for this Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-ietf-atompub-autodiscovery-01.txt
 

And a more pleasant one is:

http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

or for your two words on every page? yay. pleasure:

http://philringnalda.com/rfc/diff-00-01.txt

Phil Ringnalda

Re: Autodiscovery paces

2005-05-10 Thread Thomas Broyer

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

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

--
Thomas Broyer

Re: Autodiscovery paces

2005-05-10 Thread Robert Sayre


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

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

Robert Sayre

Re: Autodiscovery paces


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

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

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

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

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

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

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

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

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

e.

Re: Autodiscovery paces


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

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

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

The purpose of Atom autodiscovery is for clients who know the
URI of a web page to find the location of that page's associated
Atom feed. 

There is also this in section 6

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

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

e.

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

Re: Autodiscovery paces


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

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

:-)

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

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

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

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

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

e.

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

Re: Autodiscovery - different cases should use different rel

2005-05-06 Thread Eric Scheid


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

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

finding every feed is not my concern either.

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

this won't work ... see below.

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

absolutely!

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

Just to throw more fuel on the fire:

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

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


e.

Re: Autodiscovery

2005-05-06 Thread Sjoerd Visscher

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

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

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

Re: Autodiscovery - different cases should use different rel

2005-05-06 Thread fantasai

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

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

Re: Autodiscovery - different cases should use different rel

2005-05-06 Thread Nikolas 'Atrus' Coukouma

Eric Scheid wrote:

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

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

finding every feed is not my concern either.

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

this won't work ... see below.

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

absolutely!

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

Just to throw more fuel on the fire:

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

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

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

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

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

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

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

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

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery discussion editorship

2005-05-06 Thread Mark Pilgrim


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

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

-- 
Cheers,
-Mark

Re: Autodiscovery

2005-05-06 Thread Sjoerd Visscher

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

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

RE: Autodiscovery

2005-05-06 Thread Bob Wyman


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

bob wyman

Re: Autodiscovery in a as well as link

2005-05-06 Thread Phil Ringnalda

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

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

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

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

Phil Ringnalda

Re: Autodiscovery in a as well as link

2005-05-06 Thread Roger B.


 Is there something wrong with the HTML parsers?

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

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

--
Roger Benningfield

Re: Autodiscovery, real-world examples

2005-05-05 Thread fantasai

Nikolas 'Atrus' Coukouma wrote:
 fantasai wrote:

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

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

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

Re: Autodiscovery, real-world examples

2005-05-05 Thread Antone Roundy

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

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

Re: Autodiscovery

2005-05-05 Thread Sjoerd Visscher

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

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

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

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

Re: Autodiscovery


Sjoerd Visscher wrote:


 Why not support hyperlinks too?

 So besides:

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

 also:

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

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

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

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

-Nikolas 'Atrus' Coukouma

-Nikolas 'Atrus' Coukouma

RE: Autodiscovery, real-world examples

2005-05-05 Thread Bob Wyman


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

bob wyman

Re: Autodiscovery

2005-05-05 Thread Sjoerd Visscher

Nikolas 'Atrus' Coukouma wrote:
Sjoerd Visscher wrote:

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

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

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

Re: Autodiscovery - different cases should use different rel


fantasai wrote:


 Nikolas 'Atrus' Coukouma wrote:

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

 That makes sense.

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

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

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



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

These other feeds are suggestion/blogroll cases.


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

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

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

I think this is a suggestion/blogroll case.


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


 ~fantasai

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

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

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

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

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

Re: Autodiscovery


Sjoerd Visscher wrote:

 Nikolas 'Atrus' Coukouma wrote:

 Sjoerd Visscher wrote:

 Why not support hyperlinks too?

 So besides:

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

 also:

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

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


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

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


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

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

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

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

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

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

-Nikolas 'Atrus' Coukouma

Re: Autodiscovery


Nikolas 'Atrus' Coukouma wrote:

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

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

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

-Nikolas 'Atrus' Coukouma

RE: Autodiscovery, real-world examples

2005-05-05 Thread James Tauber


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

+1

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

+0.5

James

Re: Autodiscovery

2005-05-05 Thread Sjoerd Visscher


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

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

Re: Autodiscovery - different cases should use different rel

2005-05-05 Thread Eric Scheid


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

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

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

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

e.

Re: Autodiscovery - different cases should use different rel

2005-05-05 Thread fantasai

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

Re: Autodiscovery

2005-05-05 Thread fantasai

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

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

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

Re: Autodiscovery - different cases should use different rel