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]
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
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
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
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
://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
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
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
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
James M Snell schrieb:
...
Now, to the WG as a whole: I really don't have any agenda for the
autodiscovery stuff other than to help foster it along. If y'all think
there is a need for a I-D defining autodiscovery for Atom and APP, I've
got a few spare cycles to help with the editing. If y'all
.
The details are still being worked out, but the plan is to indicate the
maturity level on a per-section basis. Sections like the Link Types,
which is relatively simple, isn't going to take long to become
interoperably implemented. In fact, Mozilla is already implementing the
new autodiscovery features
On 11/30/06, Lachlan Hunt [EMAIL PROTECTED] wrote:
The point to all this is that you shouldn't place too much weight on the
status of the specification as a whole. You need to consider the
stability and maturity level of each section individually. Thus, while
proceeding with Autodiscovery
The AD was kind enough to point out that this statement is likely a bit
too vague. The intended meaning was that I have no involvement in, or
awareness of, IPR that is in any way relevant to the atom work. And, as
far as I am aware, there's nothing I am required to disclose.
- James
James M
an orange button appear.
[snip]
Good grief.
What I said was that my volunteering to take over the editing of the
autodiscovery draft had nothing to do with my day job; that is, no one
at IBM asked me to work on autodiscovery nor am I aware of anything at
IBM that is dependent on its completion
originally suggested that the draft be resubmitted as a WG draft.
The Area Director and the WG chairs suggested that since autodiscovery
was not covered under the original charter it would be better to pursue
it as an individual submission. I decided to do so only on the
condition that the same open
* 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
I'm the chairman of the RSS Advisory Board, which has
published our first autodiscovery specification [1].
I'd like to participate in the drafting of Atom's
effort in this area with the goal of making it
possible for publishers to support autodiscovery in
the same manner regardless of syndication
http://www.intertwingly.net/wiki/pie/PaceRestrictRelValuesForAutodiscovery
http://www.intertwingly.net/wiki/pie/PaceRestrictTypeValuesForAutodiscovery
While I definitely understand the rationale behind this, it's unlikely
that the spec will actually lead to any change in behavior for the
various
Hi,
This feedback is related to the autodiscovery draft.
Before reading on, I suggest anyone writing a specification of any kind
actually learn a little about how to write good conformance criteria.
http://ln.hixie.ch/?start=1140242962count=1
I do not believe it is at all useful
All:
With Phil Rignalda's permission, I have taken over the role of editor
for the Autodiscovery draft and at Lisa and Paul's suggestion I have
resubmitted the draft as an **individual** submission (as opposed to a
Working Group Draft). Phil has requested that his name be removed from
the draft
: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]
All:
With Phil Rignalda's permission, I have taken over the role of editor for the
Autodiscovery draft and at Lisa and Paul's suggestion I have resubmitted the
draft as an **individual** submission (as opposed to a Working Group Draft
Because I resubmitted the draft with no changes from its previous
version. I intend to update references with the next iteration of the
draft.
- James
Tse Shing Chi (Franklin/Whale) wrote:
Why is one of the normative references in draft
draft-ietf-atompub-format-11 instead of RFC4287?
James M Snell wrote:
The process for moving forward on this spec will be the same as with
Atom and APP.
No, it won't. It's not a WG document.
Does the draft diverge from existing browser behavior? Do browsers
implement aspects of the document differently? What problems have you
seen that
Robert Sayre wrote:
James M Snell wrote:
The process for moving forward on this spec will be the same as with
Atom and APP.
No, it won't. It's not a WG document.
Ok, to be absolutely pedantic about it: the process will be as close as
possible to that used for Atom/APP with the obvious
James M Snell wrote:
Consensus calls will be posted
periodically;
That's not a process I can live with. Maybe this draft would be a better
fit for the WHAT-WG or the W3C.
Does the draft diverge from existing browser behavior? Do browsers
implement aspects of the document differently?
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:
foo:link xmlns:foo=http://www.w3.org/1999/xhtml; rel=alternate
type=application/atom+xml href
To clarify my +1 to Ship it: At AOL, we are using Atom internally as
a data exchange format (and just converted to 1.0 syntax). We are using
an early version of the introspection document as well, but only for
limited internal use as it's nonstandard and likely to change. When the
dust
-ietf-atompub-autodiscovery-01.html
and be done?
+1. Ship it. -Tim
--
Robert Sayre
I would have written a shorter letter, but I did not have the time.
: Tuesday, January 24, 2006 10:09 AM
To: Robert Sayre
Cc: Atom Syntax; Phil Ringnalda; Mark Pilgrim
Subject: Re: finishing autodiscovery, like now
On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote:
PaceAnchorSupport and PaceDifferentRelValue don't seem very useful,
and they weren't proposed
+1 to ship it.
--
John Panzer
Sr. Technical Manager
http://journals.aol.com/panzerjohn/abstractioneer
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
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/
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.
Quoting Eric Scheid [EMAIL PROTECTED]:
On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
But we already have a name for doing that: it¹s called ³linking
to something.² Now, it¹d be useful to encourage people to add
`type` attributes to their `a` links, so tools could find them
just by
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
The existing behaviour is based on the various incarnations of RSS where the
only document type involved are feeds. RFC 4287 introduces a new document
type, the Atom Entry Document, which autodiscovery-01 fails to take into
consideration
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
, 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
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
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
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
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
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
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
On 1/19/06, James M Snell [EMAIL PROTECTED] wrote:
Why wouldn't this work?
rel=alternate feed
rel=alternate entry
rel=alternate replies (see [1])
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
I.e. the values are all
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
PaceDifferentRelValue addresses this. It suggests using feed as an @rel
value to indicate the referenced resource is a feed (ie. is not an entry
doc) which can be subscribed to.
The spec already does this without a new rel value.
It doesn't
* Phil Ringnalda [EMAIL PROTECTED] [2006-01-19 22:30]:
I am trying to think of a scenario where I'd want to
autodiscover an entry document (as opposed to simply linking
to it) and the inability to distinguish between feed and entry
documents is causing a problem, but I can't come up with
* Eric Scheid [EMAIL PROTECTED] [2006-01-19 23:10]:
PaceDifferentRelValue addresses this. It suggests using feed
as an @rel value to indicate the referenced resource is a feed
(ie. is not an entry doc) which can be subscribed to. It doesn't
rule out continuing to use alternate for those cases
A. Pagaltzis wrote:
(Hm, what happened to James Snell’s profile extension?)
In progress. I decided to hold off in favor of a few other higher
priority items. Expect a draft on this either later this month or next.
- James
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
The purpose of Atom autodiscovery is for clients who know the URI of a
web page to find the location of that page's associated Atom feed.
Not an entry but a feed. The autodiscovery is unambiguous on what such
a link points
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.
, and this is what is driving my interest in
disambiguating feed autodiscovery.
e.
On 20/1/06 8:52 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
Why wouldn't this work?
rel=alternate feed
rel=alternate entry
rel=alternate replies (see [1])
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
I.e. the values
On 1/19/06, Joe Gregorio [EMAIL PROTECTED] wrote:
Because rel is a space separated list of link types:
http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel
https://mail.google.com/mail/
I.e. the values are all orthogonal.
Though at this point in this discussion, someone is always
On 20/1/06 8:31 AM, Robert Sayre [EMAIL PROTECTED] wrote:
First person to need the feature has to spec alternate entry instead
of making everyone change to alternate feed.
How is speccing alternate entry helpful?
That would *still* be considered an autodiscovery link to a feed,
according
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
That would *still* be considered an autodiscovery link to a feed,
according the current autodiscovery spec. That's the problem right there.
It's not a problem. It works now, and no one is going to run out and
change the running code. If someone
Eric Scheid wrote:
Yes, but that would mean that it *would* work, not that it *wouldn't*. Being
orthogonal means that those three links are equivalent to these six links
rel=alternate href=1
rel=alternate href=2
rel=alternate href=3
rel=feed href=1
rel=entry href=2
rel=replies
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
The purpose of Atom autodiscovery is for clients who know the URI of a
web page to find the location of that page's associated Atom feed.
Not an entry but a feed
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
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
Joe Gregorio wrote on 1/19/2006, 5:29 PM:
On 1/19/06, Eric Scheid [EMAIL PROTECTED] wrote:
On 20/1/06 8:08 AM, Joe Gregorio [EMAIL PROTECTED] wrote:
The purpose of Atom autodiscovery is for clients who know the URI
of a
web page to find the location of that page's
On 1/19/06, John Panzer [EMAIL PROTECTED] wrote:
What autodiscovery links should I do on a web page that displays a
single blog entry, like this one?
http://journals.aol.com/panzerjohn/abstractioneer/entries/1238
Actually on my blog each page has a feed associated with
it that is a feed
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
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
-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
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
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
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
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
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
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 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
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
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
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
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 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
.
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
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
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
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
(#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
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
(#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
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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
.
- 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
fantasai wrote:
Nikolas 'Atrus' Coukouma wrote:
fantasai wrote:
An excellent point. Perhaps these should use rel=home :)
link rel=home type=application/atom+xml href=/xml/feed.atom
...
The value of rel, if present, will vary based on relation
* the feed for *this* page -
Phil Ringnalda wrote:
Arve Bersvendsen wrote:
On Tue, 03 May 2005 18:52:59 +0200, Tim Bray [EMAIL PROTECTED] wrote:
http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt
1) Change the attribute value for the rel from alternate to feed,
Don't forget, since you would be doing
1 - 100 of 145 matches
Mail list logo
